These days it feels like the bulk of my “coding” happens while I’m making coffee. The agent spins up, reads the context, and by the time I’m back at my desk there’s a diff waiting for review. It’s not perfect, but it’s good enough that the bottleneck has shifted. And that shift is worth talking about.

If the machine is now handling the syntax, the scaffolding, and the boilerplate — what should we, the humans, be doing with the time we just got back?

The New Bottleneck: Understanding, Not Typing

I spend most of my working hours on Aperture, a pricing intelligence data platform written in Go and React/TypeScript. The code itself isn’t the hard part anymore. The hard part is knowing what the pricing model should surface, why a particular data visualization feels off to a user making a multi-million dollar sourcing decision, and how a feature fits into the broader domain of procurement and market intelligence.

In other words: the LLM gave us time on our hands, and we should be spending it on understanding the product and the domain — because that’s what lets us prompt a better product.

Every Engineer Is a Mini-PM Now

There’s an old joke that every engineer secretly wants to be a PM. I think the reality is more nuanced: every engineer should be a mini-PM for the slice of the product they touch.

When the agent writes the implementation, my job becomes asking the right questions before the prompt ever goes out:

  • Who is this feature for, and what’s their mental model when they look at pricing data?
  • What does success look like from the user’s perspective — a faster quote, a more confident negotiation, a discovered arbitrage — not just the test suite’s?
  • Where does this break in the real world, outside our happy-path fixtures? What happens when a supplier changes their pricing tier mid-quarter?

One concrete output of all this thinking: acceptance criteria matter more than ever. When the agent does the building, the criteria become the validation goal — the spec the LLM grinds against until it stops arguing back. Vague criteria get you code that confidently matches a vague spec; sharp, testable criteria get you something you’d actually merge. Writing them used to be the boring paperwork before the fun part. Now a lot of the real engineering judgment lives right there.

If you’re not spending at least as much time in product discussions as you are in code review, you’re leaving leverage on the table. The LLM can generate the solution; it can’t generate the conviction that the solution is worth building.

Let It Grind, Then Go Talk to People

The workflow that works for me splits into two modes:

  • Async (solo): The agent experiments, refactors, writes tests, and explores implementation paths while I do something else. This is where brute-force iteration happens — the LLM trying variations until something sticks.
  • Sync (collaborative): I take what the agent produced and stress-test it against reality. We’re 100% remote, so that means pinging a colleague, jumping on a quick call, or simply writing down what I think I learned and letting someone who knows the domain better tear it apart.

The agent will happily hallucinate a clean architecture for a problem it doesn’t fully understand. Only a human, armed with context from the people who actually live in the domain — the procurement officers, the category managers, the people who read pricing sheets for a living — can catch that early. The meetings and conversations aren’t overhead — they’re the actual work now.

The Collaboration Loop

So instead of inventing a new ritual, I’ve started extending the ones we already have. Standups and refinements tend to be all about the how — status, blockers, technical approach. Flip them toward the product outcome instead: here’s what I think is true about the domain, here’s what the agent has been churning out, and here’s where I’m still uncertain.

The output of those conversations isn’t documentation. It’s conviction. And conviction is what you bring to the agent’s context window the next time you prompt it.

That’s the actual loop: the agent does the grinding, the standups and refinements turn its output into understanding, and the understanding makes the next prompt sharper. Every cycle, the machine gets better context — and I get better questions.

The Bottom Line

The LLM didn’t just make us faster. It handed us time — and time is only valuable if you spend it on the right thing. Typing speed and syntax knowledge are now table stakes. The engineers who thrive are the ones who take the freed-up hours and go deep on the domain: the users, the data, the edge cases, the “why” behind the feature.

Because here’s the loop that matters: the deeper your domain understanding, the better your prompts — and the better your prompts, the better the product. The agent amplifies whatever you bring to the context window. Bring shallow understanding, get shallow code. Bring conviction, get something worth shipping.

So let the machine do the typing. Spend the hours it hands you on the product, the people, and the domain. Become the mini-PM your team didn’t know it needed. The code will write itself :)

If you’ve found good ways to spend the time your agent gave back, I’d love to hear them. Drop me a line or find me on the about page.