The way I code now, or rather “code”, is completely different than it was in 2025. With that progress, I thought it would be fun to document my current process. In reality, who knows how I’ll be doing it, even 4 months down the road.

I remember the days when I would spend hours rooting around for the right place to modify, thinking through every single keystroke. The reactions to this shift range from outright disgust to unbridled excitement, but either way the reality is that the industry has largely moved on. Or at least, it’s going to.

TLDR #

  • I haven’t really integrated using my voice yet. But I’m interested in it!
  • I don’t hand write code. I have agents write it, and I chat with it.
    • When the agent writes code, I have it make one mega-PR, then split it as needed.
  • Agents help me review code, but I still review them myself.
    • I use a skill to help me manage the now massive review queue.
  • On any given day I have up to 4 worktrees active doing work. I occasionally have a need to go beyond that number (5, maybe 6, to do investigative work, or if my other agents are waiting on CI, tests, or some long command).

Agents write the code #

These days, I do not hand-modify code. Maybe I will touch a constant or two, but almost any operation is easier to just type a few words and have the agent do it instead:

  • refactoring a name requires touching multiple files.
  • modifying some behavioral function requires fixing unit tests.

Whenever I think about going and opening a file in an IDE, I just realize it’s faster to tell my agent to go do it.

What I do modify by hand #

There are things I touch a handful of the time:

  • small docstrings with poor grammar.
  • pr descriptions.

But again, my mindset comes down to whether it’s easier to type a few lines in my editor, or just tell the agent.

I read the code #

I still read the code my agent produces. Honestly, it’s a good mental exercise for me to be able to understand how these pieces fit.

I often ask follow-up questions in the agent session. This is how I ramp myself up on the architecture of the system, ask about tradeoffs, etc.

Stack up a mega-PR, then break it down #

Often the work I’m trying to do is to lead to a particular outcome, and it’s much easier to let an agent loose (safely), see what it can find, then correct it all later.

So I typically have an agent work on a pretty massive change, refactoring and modifying whatever files it needs. After that, I look at the changes, adjust the results, and once I think it’s ready, cut it down into several pieces into a stack (we use Graphite at GM).

Agents help review the code #

Some people just let agents review everything, with very little human oversight. The options I’ve heard of are:

  1. full auto: have agents review everything. If it LGTM to them, merge.
  2. agents, then review yourself: have an agent review the code first, and identify the risk and problem areas. Review those yourself.
  3. manual (of course): review it all yourself.

I go with 2, or if the LOC is small enough, I just review it myself (3):

  • Agents catch a good number of issues I don’t.
  • Despite the fact that I see agents give correct answers a vast majority of the time, they still make mistakes. And I want to make sure I am still a trustworthy producer of features, rather than someone who pushes responsibility on others to keep me and my agents in check.

Using agents to help prioritize reviews #

I am in a few groups on our GitHub repository, and the number of reviews is growing. As a result, I have 100+ reviews in my queue at any moment.

I wrote a skill to help organize them, so I can make sure to unblock small, safe changes, and also raise up the big changes that might require more thorough review. I categorize mine into:

  • safe: constant / enum / value changes. Easy LGTM.
  • mostly safe: a few refactors. Requires a little reading but not bad.
  • complex: this is the category where a lot of review and time is needed.
    • I’ll probably have my review agent look at it first and give me some ideas on what to look at.
  • reviewed: these are ones I’ve already reviewed.

For small pet projects, I yolo #

The above is all for production, critical code bases: these are the things where degrading code quality can increase complexity and make things slower for agents, and likely completely incomprehensible for humans. I want to steer very safely for those.

But for small projects that only run locally, single-page-apps and utilities, I can just work directly from the spec:

  • I define what I want.
  • I review, and give feedback on the high-level approach.
  • The agent modifies accordingly.

The models (I usually use a mix of ChatGPT Sol, Opus 5.5, Gemini flash 3.8) are already great at producing small-scoped projects. I think we’re past the point of needing to steer agents because they’re not giving us at least something usable. And it’s great being able to quickly iterate on something you need.

Final thoughts #

It’s amazing to me how in a few months, I went from some hand writing of PRs to effectively zero. A lot of people feel like this is a sign that our whole profession might become obsolete, and admittedly there’s some truth to that.

However, it still feels like human, expert judgment is critical here. At least if you care about code quality and keeping the codebase functional, having expert reviewers who can steer changes toward re-use, eliminate abstractions, and make sure core use cases are satisfied is essential.