For most of the history of making software, writing code was the work. You spent your days typing out functions, fighting errors, debugging migrations, and reading through other people’s code to figure out why a function did what it did. Another day in the code factory.
That’s mostly over. With a good brainstorm and a well-structured plan, today’s models will write code, run tests, fix failures, and hand you back a clean pull request with code changes ready for review. I’ll open my laptop in the morning to a stack of green pull requests that agents shipped overnight, with features ready to merge before my first meeting. The factory has been automated. (View Highlight)
What I’m left to do is sit with the result and decide whether it’s any good—and then push it further than the agent could take it itself. A model doesn’t know what I would call good, sitting in front of this feature in this product I’m building for these users. Without that final human judgment, everything the agent produces is functional, but forgettable. A few weeks ago I clicked on an email card in Cora and knew instantly the animation was wrong—it slid in from the top of the screen instead of opening from where I’d clicked mid-screen. I told the agent, it fixed it, and I clicked again—better. (View Highlight)
Polish is the final step in compound engineering—the discipline I’ve been developing over the past year for building software in a way that gets smarter with every iteration. As more of the middle parts of the process gets automated, polish matters more now, because it’s the part of the work that’s still yours. Instead of the assembly line worker putting the code together, you’re the person at the end of the line who decides whether it’s good enough to put your name on. (View Highlight)
Polish in practice
The card animation that looked wrong is a good example of how polish works, because animation is something that agents still struggle with (although it will improve over time).
The pull request had passed every automated check. The review agents had nothing left to flag for me. I ran /ce-polish—part of the compound engineering plugin—which does three things and then gets out of my way. It checks out the branch I want to polish, starts the development server in the background, and opens the running app inside my editor, right next to the agent. From there, I clicked on an email card to open it and started my assessment. (View Highlight)
Once the new design was open beside the agent, I could see that it still felt too loose. There was too much whitespace, and the cards needed to be more compact. I said so out loud via Monologue. The agent tightened the layout; the app hot-reloaded; I looked again—better. A plan could tell the agent to make the Brief feel like a magazine. It couldn’t tell the agent when the page had the right density. I had to see it and decide for myself. (View Highlight)
This is what polish looks like: a conversation between me, the running app, and the agent. The whole setup—/ce-polish, the side-by-side layout, the hot-reloading dev server—exists to keep that conversation fast enough that I never lose the thread of what I was looking at, like the exact pixel I was squinting at or the subtle difference I was trying to name. Adding steps like finding the file, switching windows, or pasting context for the agent would break the rhythm. Polish is the kind of work that only happens when you can stay in the flow.
It’s also what makes polish strange compared to the other steps in compound engineering. Plan dispatches subagents to draft a structured specification. Review fans out parallel reviewers, each looking for a different class of issue. Ideate runs a divergent brainstorm and scores the survivors against confidence and complexity. Every other step is built around orchestration and structure—agents on top of agents, with templates and rubrics holding the work in place. Polish is the opposite. There are no agents because agents can’t decide whether the thing on screen matches the thing I meant to build. (View Highlight)
What polish changed about the rest of the loop
I knew polish would change the end of the loop. What I didn’t expect was that it would change the rest of it, too.
Planning got sharper because I started writing plans that anticipated what I’d want to feel during polish, not just what I’d want the code to do. Reviewing got less anxious because I no longer had to catch every issue at the diff stage—I knew there was a later step that would catch the things only a person using the app could see.
The constraint on my workflow used to be how fast I could ship. Now, with agents, it’s how good I can make it. Spend the extra time on polish, and the software gets better.
Perhaps the biggest upgrade is to compound, the step where lessons from the loop get written down for the agent to pick up next time. Most of those lessons used to come from failures of correctness, like whether code uses the right conventions. After polish, the lessons started carrying taste. In the case of Cora, it’s things like animations that resolve toward the click, or scroll bars that hide unless invoked. Each one started as something I muttered at the browser and turned into a rule the system applied the next time, without me asking again.
This is how polish compounds. The first time I caught the wrong-direction animation, I had to say so. On the next feature with a card in it, the agent formatted the right animation by default. (View Highlight)
The work that used to define a great engineer is mostly done by agents now. What I now have to do is decide whether the work is good enough—then push past good enough to something that feels like it was made by a person who cared. The bar of what’s possible to ship in a day has gone up, so the bar of what’s worth shipping has gone up too.
Because agents did the building, the cost of saying “this isn’t it—replan the whole thing” has all but disappeared. All it needs is an afternoon of agent time and a few dollars of compute. Your job changes from protecting your time to protecting the quality of what you’ve built.
If you want to try it, here’s a headstart: Pick a feature you’ve shipped recently—ideally one with a user interface, where the gap between whether it works and is good shows, like an onboarding flow, a landing page, an animation, or a settings screen. Skip infrastructure for now. Start where your users will feel it. (View Highlight)
