Shai Sachs

Software printing press: first blog post

2026-08-01T18:00:00+00:00

I didn’t write this post. My software printing press did!

Here’s what happened. I handed the press a folder of my last several blog posts and asked it to distill my voice and point of view into a style guide. Then I asked it to read that guide and draft a new post. This blog post is the result of that pipeline.

This little adventure demonstrates that the press can now operate inside a workspace. It can read the files in a directory and write new ones, rather than just emitting text into the void. That sounds small, but it’s the difference between a party trick and a colleague.

For the time being, I’ve orchestrated those steps by hand, but there’s no reason the press couldn’t orchestrate them itself. That’s what excites me most. Reading and writing within a workspace is fundamental to creating realistic codebases - the press has to inspect what’s already there and modify it, not just generate text. So in addition to a machine that writes blog posts with my voice, I’m well on my way to using that same machine to write code.

My next step is to mount git credentials into the press so it can operate directly within my repos. Not very difficult in terms of mechanics, but quite exciting in terms of reducing friction - it’s what turns a demo into a real coding workflow.

The one caveat: self-hosting these models has been a royal pain. Hetzner VPS is expensive for models that are actually useful, and Runpod is full of papercuts, even for turnkey serverless installs. So for now I’m just using the DeepSeek API. In principle I could self-host, but I don’t want to sink much time into it.

I did wind up giving this post some touch-ups, but for the most part you’re listening to DeepSeek and OpenCode (… and some of my old blog posts.) I hope you like them!

Lovable

2026-07-31T06:00:00+00:00

I’ve had an idea kicking around the back of my head for a few months now, and last night I finally fired up Lovable and fed in a prompt. Holy geez it is so much fun!

I know I’m not the first person to discover it, but it is really something else to see a loose idea materialize on screen. In my case I started out with a pretty basic “turn my spreadsheet into an app” prompt, and out came a fully-formed app: Google SSO, mobile-friendliness, a ferreals database, pop-up calendar widgets. Not too shabby, Lovable gang!

Probably the most compelling feature in Lovable is the “Publish” button: after a tiny bit of prompting and playing around, is this thing really ready for prime time? That can’t be right, can it?

In my case I’ve decided “not yet,” and I figured out how to export my Lovable-generated code into Github* so I can edit it directly. (Took a minute to find this feature! If you’re looking for it, just append “/settings/git” to the URL for your project’s home screen, so your final URL is something like https://lovable.dev/projects/{your-project-uuid}/settings/git) The sync experience is quite nice: changes from Github appear in your Lovable preview environment within minutes.

My plan is to fool around with this project a bit over the next few weeks. The lens I apply to side-projects is “what more can I learn?” That itself is an interesting question!

There are all sorts of feature tweaks and data model changes I can make - either by hand, or by Lovable credits, or perhaps even by my software printing press. No doubt I could learn a thing or two that way.

I’m also interested to learn all the other stuff that goes into launching a successful product, beyond the boundaries of the code: marketing, pricing, and so on. That’s decidedly outside my comfort zone, and I confess to feeling quite daunted by it. That’s a pretty good signal that I should dive into it!

Enable, don't scale

2026-07-21T18:00:00+00:00

Paul Graham famously said that startups should do things that don’t scale if they want to grow. The same applies to AI enablement.

Of course, Graham’s philosophy is meant to be counter-intuitive in order to grab attention. It’s meant to direct the aspiring founder away from the long-term prize (unicorn status, millions of users, etc.) and toward the immediate steps that must be taken, today, to drive impact. And not all unscalable things are created equal: founders should do things that enable them to learn about the market. You do things that don’t scale now, so that you can learn how to scale later.

AI enablement follows a similar trajectory, even if success is measured in DORA metrics like lead time to change, rather business metrics like sales.

It’s not enough to wire up a fancy coding harness, though that is certainly important. You have to get it into the hands of engineers, and you have to drive usage day-to-day.

At the outset, that includes a lot of careful guidance: walking an engineer through Codex installation bit-by-bit, debugging config files, and the like. It also means taking careful note of pain points along the way, and bringing that feedback to bear on improving the harness for the future. That is where I’m focused now.

These are unscalable activities: if I were to do them for every single engineer at Chewy, I would be doing nothing else for months and months. But what they do is give me a very valuable look into the pain points in the harness: permissions gotchas, blind spots in the specs, that kind of thing. The more I learn, the more I can improve the harness.

Over time, that harness will hopefully grow robust enough that we can expand usage more broadly, and establish “golden paths” that make headless coding adoption really easy: setup scripts, readily-available skills, templates, and so forth. One of the “unscalable” things that I did early on was to create an evaluation framework that allows me to track lead time to change against token spend. That will give us crucial insight into the success of our expansion endeavors, and allow us to pivot in real time.

The similarity between these efforts makes perfect sense if you think about it: we’re asking people to make a big change! Headless coding is not easy, and it takes quite a bit of work to see it come to life. But I think the reward will be worth it!

Software printing press: tool calls

2026-07-15T18:00:00+00:00

My software printing press project reached a nice milestone this week: it’s now capable of tool calls using local models on my laptop - entirely dockerized, entirely without Internet. It can write code and blog posts for me now!

There’s a catch, which is that my laptop is not that powerful. Most of the trouble I had getting everything to work was finding a tool-calling model that my Ollama could actually bring into memory on my laptop. After quite a bit of trial-and-error I settled on Qwen 2.5 / 0.5B.

That’s fine for a demonstration, but it won’t actually get useful work done. My favorite toy prompt is “write something about penguins to penguins.txt”, or something along those lines, and the other night my software press did just that… but barely! It was a line of text, sort-of cohesive, and that was about it. My software press wrote some Python code to add two numbers but really choked on Fibonacci numbers.

The next step is to rent out some more substantial hardware, probably a Hetzner VPS, and load a more interesting model - Gemma 4, Kimi, something like that. Hopefully that yields more interesting results. I have an idea for a fun little Python script I’d like to “print”: input a markdown file with a list of song titles and artists, mount a Spotify API key, and generate a Spotify playlist. That would be a nice milestone!

Assuming all goes well, I hope to improve the affordances of the thing - right now it’s accepting jobs via curl API calls, which is fine, but I’d love to hook it up to Linear and start to treat the press as my own little engineering team.

In the meantime, you are welcome to play with my software printing press, and even more welcome to improve it! The code is MIT-licensed and PRs are warmly encouraged.

Headless devex

2026-07-14T18:00:00+00:00

Lately I’ve been wrestling with the developer experience for headless coding. This paradigm offers a lot of advantages to IDE-based coding - but it’s not easy to adopt!

Engineers love their IDEs. IDEs have been shaped through decades of practice to offer all kinds of goodies: auto-complete, color schemes, and so on. Asking engineers to give up IDEs is a big ask.

Some companies have tried the nuclear option: leadership gives a mandate that henceforth, all code must be agentic. There’s certainly something to be said for that kind of “ripping off the band-aid” moment, and there are some visible success stories that you’ll find online. However I suspect there’s a fair amount of survivor bias: we probably don’t hear about numerous cases where this approach failed miserably.

My approach is more “grassroots” in nature. The idea is to gradually spread the paradigm, as follows:

Get the basic mechanics of headless coding working in a small, isolated context. Install Codex, spin up a greenfield project, crank out some commits.
Create some readily-shared artifacts. In my case that includes a suite of skills to support headless coding, which will be delivered on a plugin marketplace.
Provide training materials. Blog posts, video tutorials, office hours - all of the above and more. I’ve found that repeating yourself, across many different formats and venues, is crucial. It never hurts to repeat yourself. Did I mention that repetition is important?
Hands-on SME program. Identify a small number of early adopters who can adopt headless coding and get their feet wet with the tools. It’s crucial that these early adopters should be working on normal feature work, roadmap projects that they would be doing anyway - it’s time to graduate beyond toy projects and deliver real value! It’s also ok to provide a lot of hand-holding, pair-programming, check-ins, and other support. The goal is not just to get some headless coding done, but also to learn what’s not working in the headless coding framework, and to go and fix those problems before you scale out.
Evaluate. Once you’ve got the SMEs pushing some headless code into production, you want to see how well you did. I’m measuring lead time to change against token spend to get a picture of ROI.
Rinse and repeat! There are probably several iterations of this process necessary before the practice can really take hold. Of course the idea is that, Amway-style, your SMEs bring their teammates and other engineers into the process, so that you get organic growth over time.

The above process is hardly original, I am stealing bits and pieces of it from projects I’ve seen take off well in the past - and I have to admit I got a lot of great ideas from my experience in the Developer Platforms group at Wayfair.

What it is, though, is necessary. All the best tooling in the world is useless if no one’s using it!

Search and repeat

2026-07-08T18:00:00+00:00

You could (greatly) simplify software engineering into two acts: search for a deterministic artifact; and repeatedly execute that artifact, over and over. Agentic coders are great at the first act, terrible at the second, and it’s important to remember what you’re trying to do when you leverage them. That is a crucial insight for developing efficient skills.

One of the key breakthroughs in separating “search” and “repeat” for agentic coders was the Cloudflare Code Mode blog post from September. In that post, Cloudflare suggested that agents should not consume MCP tools directly, but rather write code to consume the tools, then execute that code.

The idea was specific to MCP tool calls but the insight generalizes nicely. Agents are good at searching for deterministic artifacts, not repeatedly executing a deterministic step. On reflection, the reasons are obvious: LLMs are non-deterministic by nature, and sensitive to their input. You can use them for guided search with a reward function, in principle quite similar to the classical AI strategies like A* search.

The latest incarnation of this idea is agentic skills. The key to building a good skill is finding the proper line between determinism and non-determinism; what text goes into SKILL.md, and what should go into a bash script alongside it?

It’s quite easy to get the balance wrong, and the cost of doing so is token spend and wall-clock time. For example, you could write “commit to git” in SKILL.md, and the agent would figure out the proper command to use… after spending some time and tokens in the process. Or you can create a “git-commit.sh” script which contains exactly the parameters you want, and just tell the agent to execute that script. Such an approach is much faster and token-efficient, as the agent doesn’t have to look up the git reference material buried deep in the LLM’s neural network.

Even so, it’s reasonable to draft such a skill! It’s a easy way to get started and it can be a good proof of concept within a larger workflow. The key point is to improve the skill, and the larger workflow over time: shift the repeatable stuff into a deterministic artifact, and enhance the reward function so that search becomes sharper over time.

Ultimately, it’s important to evaluate skills as software products unto themselves. They require testing, monitoring, bug fixes, and all the rest. This degree of maturity for skills development is thin on the ground. But as we endeavor to formalize agentic coding workflows, it will only become more important.

I’ve got a few ideas in the works for maturing my own skills practice, and as they prove (or disprove!) themselves I’ll try to update accordingly. In the meantime I’d love to hear what you’re doing and finding useful!

Software no one cares about

2026-06-30T18:00:00+00:00

In any conversation about agentic coding, this phrase eventually crops up: “software no one cares about.” This category is meant to include little convenience scripts that are meant for the sole use of the author, maybe some internal utilities to be shared with coworkers… certainly not mission-critical services. Usually the conversation pivots as follows: Agentic coding can implement such marginal software easily, but of course Serious Software is much more tricky. It’s a conclusion that might’ve come straight out of the Innovator’s Dilemma.

The Innovator’s Dilemma is a 1997 book by Clayton Christensen which argues that, even though disruptive technologies often look unimpressive at first, they can still wind up taking over the market, by moving quickly and transforming customer expectations.

In this context, the disruptive technology isn’t agentic coding. It’s the software no one cares about.

In other words: “marginal” software could be capable of threatening the market position of the biggest giants of our day. Bespoke search engines could some day unseat Google, that kind of thing. We’re in the Age of the Software Printing Press, and there’s a lot of change on the horizon!

I’m not the first person to arrive at this conclusion, and I’m sure that incumbents are well aware of the threat. There are plenty of people heralding the death of SaaS as a business model: customers can just vibe-code their own CRM, why pay for Salesforce? Salesforce will probably remain healthy for many reasons. But we still need to care about the software no one cares about.

First, because such software can metastasize into something quite serious, either by design or because it becomes the duct tape that holds an enterprise together when nothing else is available.

Moreover, the experience of quickly whipping up a custom-tailored app upends our expectation of the software process. Every time a software “outsider” uses Lovable to create something that looks substantial and useful, that changes the outsider’s understanding of what’s possible.

Finally, the economics are on the side of throwaway software. It’s cheap to produce and not that hard to modify, especially if you have a limited user base. It’s easy to imagine a world where the software no one cares about becomes a substantial share of the software market, even if the incumbents remain healthy.

The next question to ask is, how should incumbents rise to the challenge? I’m not really sure!

In a former life I would’ve said that “jagged edges” - APIs, plugins, and other extension points - can transform disruptors into enhancers. I’ve seen it happen and I still think that’s true, but I also think many of today’s disruptors are not even thinking about the incumbents they might eventually unseat, and certainly not extending them.

I’d be curious to hear from you - are you thinking through this challenge? What’s your game plan?

Alienation

2026-06-17T20:00:00+00:00

The next crisis in software will be alienation. It’s a hallmark of climbing up a layer of abstraction, and we’ve seen it before, but this layer of abstraction is a particularly big one.

Alienation is a weird, weird feeling: you create something, it’s your idea, your name’s on it… but it doesn’t feel like yours. Try out a Wiggums loop: Commits roll in, your avatar is next to them, but the code is alien!

Mo Bitar’s video on being useless brought this problem into focus for me. He says there’s no learning in agentic coding: you put a coin in the slot machine, pull the lever, and out comes an app! But there’s no artistic achievement in the process. What’s so great about this brave new world?

People who aren’t software developers won’t understand this problem well. We talk about software as an engineering process, but it’s also an artistic process. There’s a great deal of joy to be found in writing elegant and effective code. It’s not art for its own sake, either: elegant abstractions have economic ramifications. Great art in software means fewer bugs, less liability, and more agility in responding to market conditions.

To step outside the world of software, consider the Andon cord in the Toyota Production System. The Andon cord, which allows any frontline worker to halt an assembly line if they spot a defect which can’t be fixed quickly, is a key anti-alienation tactic. It’s widely considered the key to Toyota’s rise to global dominance.

Agentic coding is a vector of alienation. We need to be aware of the risk and work to counteract it - but how? I think the answer lies, in part, in response to the closing question in Mo’s video. What’s so great about agentic coding?

My answer: agentic coding can be an enormous enabler; it is not just about doing the same things you were doing before, but faster. It’s about doing new things that you didn’t realize were possible. Laura Tacho’s research, which shows that AI can cut “time to 10th PR” in half, is illuminating. Agentic coding makes it easier for engineers to ramp up in a new code base. That’s incredibly exciting: we explore new languages, frameworks, and paradigms by writing code and shipping it. The doors for exploration are now open wide!

There is a great deal more to learn, but it’s of a different quality than before. I used to enjoy writing API clients - it’s fun to see a 200 OK response! - but that is becoming a thing of the past. Now I’m learning to re-examine my notion of what’s possible, in a way that is both fun and bewildering. Simon Willison’s guidance that we should be scaling up ambitions is telling.

Artistic achievement in agentic coding is still possible, but it requires a different mindset and greater ownership of the process. Beyond “shifting left” into writing specs, software engineers need to be empowered to explore and own the problem space they inhabit.

Agentic code review framework

2026-06-09T18:00:00+00:00

A couple of weeks ago I took a stab at creating an agentic code review framework at Chewy. Since then I’ve been fiddling around with it for a couple of projects. Turns out, review is much more difficult than implementation!

The framework I’ve built out is inspired in large part by Ankit Jain’s piece on How to Kill the Code Review. It has three components:

Make the build green
Adversarial QA
Review case files

Each of the above steps is its own agentic skill, and none of them are particularly clever. The first skill, for instance, provides the agents with some bare bones access to Jenkins, and then provides steps to check the build status, identify the cause of failure, fix it, and then rinse-repeat until the build is green.

Review case files are somewhat interesting in that they spin up sub-agents to independently examine a pull request from multiple angles: API design, database logic, resiliency characteristics, etc. At the end an orchestrator agent compiles all of the findings into a programmatic “case file.” This case file can kick off a new coding loop to fix the review findings, provided they are reasonably simple. But again, this idea can be found elsewhere: indeed I believe it’s the “hello world” example Codex provides for orchestrating sub-agents.

Some of the value that this framework provides, I hope, is real experience inside the confines of Chewy’s ecosystem. Indeed I’ve accumulated quite a few learnings as far as that goes, and I’m working to incorporate them into the framework as I go. For example, I’ve discovered the need for a skill to manage feature toggles in our config service, so that we can test feature-on and feature-off variants of a pull request inside a single agentic session.

The most important learning, though, is that agentic code review is really, really difficult - much more so than agentic code generation!

On reflection the reason is obvious: there are a lot of ways to screw things up, comparatively fewer ways to succeed. A good framework can handle all sorts of contingencies along the way and react to them nimbly. That means reasoning about everything from linting failures to foreign key violations in seed data, and who knows what else.

For the time being I’m exercising this framework manually - triggering the skills and then inspecting outputs before I move to the next step. That’s a useful feedback loop into the improvement of the framework itself, but eventually the training wheels will come off. The goal is to be able to spin a coding loop and a review loop, one after the other until the whole thing has stabilized into satisfactory, working code - while I’m entirely hands-off-keyboard. It’s somewhat ambitious, but the early progress is promising.

If all goes well, this framework will be something that can dramatically reduce our PR review cycles. Hopefully, this framework will improve the quality of code that enters the PR review cycle - meaning that human reviewers have a lot less to worry about before they sign off.

All this AI stuff

2026-05-26T18:00:00+00:00

I get this question with some frequency: does all this AI stuff affect me at work?

Ahem, yes. Yes it does.

In software, we are well past the point of “should we use AI?” Engineers are expected to use AI heavily - all the time, for everything. More than that, senior software engineers are expected to have an AI strategy, a program for how agentic tools plug into every activity: coding of course, but also research, debugging, learning, and on and on. It is much more than a default, but a very strong norm.

It’s clear that agentic coding has the potential to dramatically accelerate software development. But we are absolutely still in the “figuring it out” phase. A lot of my attention these days goes into questions like: how do you structure work for agents, how do you review what they produce, how do you keep systems understandable, how do you avoid subtle failures, and how do you stay oriented while multiple semi-autonomous processes are operating at once?

One of the most notable changes is the modality of programming itself. Programming used to be intensely interactive: type a little, run a little, inspect a little. Increasingly, the work is batch-oriented. You hand larger chunks of work to agents, wait an hour or three, review, redirect, repeat. And you have many batches running at once. That workflow creates a lot more context switching, and honestly I find the experience kind of stressful and cognitively slippery compared to the older style of programming.

At the same time, my ambitions for what I think I can personally build have expanded dramatically. I now have a whole backlog of ideas that feel genuinely achievable if I can maintain enough focus to effectively “babysit” the agents. In some ways, focus and attention have become the main bottleneck.

I also have substantial concerns about the environmental costs and broader societal effects of all this technology. I cringe at the thought of the climate impact of my token usage! I’m also very concerned with the problem of alienation: code appears under my name, but is it really mine? Have I actually put in the hard work to create a theory of the program, as Peter Naur put it? Unfortunately, the current situation feels like Moloch come alive: the incentives pushing companies and engineers toward AI adoption are incredibly strong at almost every level.

I’m aware that many of these observations may be very specific to software right now. My impression is that many other professions are using AI much less intensely than we are. In these industries the tools are causing a little heartburn, not wholesale changes to the entire food chain. These changes are pretty uncomfortable, but in some ways it’s what I signed up for: software goes through major paradigm shifts every 7 years or so, this one just happens to be very, very big.

I don’t know that I have a choice exactly, but I’m cautiously optimistic about the whole endeavor. In part because it’s easier to ship code out the door, and that’s inherently fun for me. More so, because there are a lot of people who feel like me, that the horizons of what’s possible are expanding. That means more ideas are seeing daylight, and more people have a chance to make a positive change. I suppose you could say I’m a technological optimist, though I know that technological changes are always double edged swords. I know all of that rainbow talk has a lot of thorny exceptions, but I hope we all benefit in the end.