integrity constraint ▁

We got our A-move

2026-09-28

Yesterday I listened to the Weekly Dev's Brew episode with Dillon Mulroy, and a lot resonated with me. Even though I was never — or at least only very briefly — in camp "no ai", I do miss the time and satisfaction of working through what he calls the Micro layer. Thinking about classes, functions and type definitions, hacking on my keyboard to churn out unit tests and then some more to see them become green. Matt Pocock calls it Tactical versus Strategic programming, but the Micro/Macro phrasing speaks to the Starcraft player in me.

About ten to fifteen years ago, I really enjoyed commanding my Zerg forces on an intergalactic battlefield. Improving my build orders, trying new strategies and watching professional players do this on a level I would never get even close to. Starcraft is a very challenging and complex real-time strategy game that forces a player to treat their own attention as a resource. There is base management and expansion, claiming resources, information gathering and fine-grained unit management (who shoots whom), all happening in parallel. And the first thing a novice player has to learn is that they can't do everything at once, but have to focus on the most important thing first. And that's Macro — gathering resources, expanding the base and growing one's army as fast as possible. The player with the stronger economy has access to vastly more resources and can just blindly send their troops to the enemy base with an attack order (called the "A-Move"). They will always overwhelm an opponent that sacrifices attention on the basics for looking at what an individual unit does. Only when the economic part is completely optimized and both players execute it on the same level does the tactical or micro control start to matter.

So much for outing myself as an even bigger nerd. But there is a point I want to make.

The macro parts of our little game we call software engineering were never locked away. Domain-Driven Design is from 2003, mutation testing is older than I am and QuickCheck happened in 1999. All of that was written down, published and practiced by people who still had to type every single line themselves. The A-Move existed too. Handing the micro layer to a coworker, a junior, a framework or a code generator has always been an option — it was just expensive enough that most projects and most individual contributors never really got to make that call. The practices were available. The capacity to get good at them was not.

I recently re-read Kent Beck's Tidy First?, which frames refactoring as an investment: you tidy when the cost of tidying is paid back by the cheaper behavior change that comes after it. Reading it now, the interesting part isn't the formula. It's that we suddenly have a decision to make where there wasn't one.

Because before agents, writing good code was not meaningfully slower than writing bad code. Martin Fowler goes further and calls the cost of internal quality outright negative — cruft starts slowing you down within weeks, so there is barely any runway on which the trade-off even exists. And there is a simple reason for that: I could not produce code I had not understood. Every line I shipped had passed through exactly one human brain, mine. Comprehension came bundled with the typing, free of charge.

Agents unbundle it. Generating is close to free now, understanding what was generated is not, and it does not get cheaper the more tokens I throw at it. So the code I'm responsible for splits into two piles: code that an agent understood once and no human ever will, and code I actually reviewed. The new cost is not comprehension itself. It's deciding, for every piece of work, which pile it goes on. Which puts us right back at the very first thing Starcraft teaches you — attention is the resource, and now I have to spend it on purpose.

That decision is the macro game, and it's where I've been spending my time since. Trying different testing strategies like mutation and property-based testing, really leaning into Domain Driven Design. And since agents also produce far more test coverage than I ever managed by hand, a good idea is no longer limited to the file I happen to have open. When I find a better way to handle form validation, applying it to all forms used to be time I didn't have. Now it's mostly a matter of paying tokens to raise the whole codebase.

And here is the controversial take: I came to believe that AI made me a better engineer. The common wisdom right now is the exact opposite — that agents make us weak, that we're outsourcing the very thing that made us good at this, and that we'd be lost the day the models go away. I don't buy it. In the last two years I improved my macro-game significantly, and I know that if tokens became extremely expensive tomorrow, I would produce better output than before the agentic revolution. Not necessarily more — none of this made me type faster. But just like test-driven development made me produce higher quality at a faster pace long before any of this, the practices I picked up in the last two years transfer straight into a manual workflow.

That doesn't mean I'm happy about all of it. I do enjoy manual coding. Given the choice I would work at the slow, detailed pace of the micro layer, and if somebody offered me the same wage for just doing that, I would sign without a second thought. I also secretly hope tokens get expensive enough to make that a real option again[1]. But I understand that it's not economically viable, and — this is the part that genuinely surprised me — I do enjoy the wider view. There is real excitement in how much is suddenly achievable. Both of these are true at the same time. Yes, some of it is cope. Feelings are rarely black and white.

In the podcast, Dillon says that he does see a light at the end of the tunnel. Some way to get enjoyment out of this new way of developing software. I found mine. It just looks different than I expected.

I don't believe that the "coding muscle" atrophies — but that comes with a condition attached. The muscle is the structured thinking, not the typing. And there is a world of difference between picking apart something new the agent came up with, and just vibe-slopping it into the repository. The first one taught me concepts I would not have gotten around to otherwise; both the solution and my own knowledge came out better. The second one teaches nothing at all. Both have their place — I have written CRUD forms in React for fifteen years and I'm perfectly happy to never do it again — but telling the two situations apart takes discipline. Without that discipline, the atrophy story is absolutely correct.

Which is also my answer to the question of how the next generation is supposed to learn any of this. When Matt Pocock interviewed Uncle Bob about software fundamentals, Bob suggested that "a fresh programmer that joined a company should be treated as an agent". Matt pushed back on economic grounds — paying a junior for work that has dropped below minimum wage is a waste of money — but I think the framing is right and just stops one step too early. The junior and the agent really do sit in the same seat. The difference is that only one of them is supposed to get up from it knowing more.

So: same discipline, just on more levels. They haven't built CRUD forms for fifteen years, so a lot more of the agent's output needs the detailed-review treatment and a lot less can be handed off. For them there is simply more new. They can learn exactly the way I do now, by criticising and poking at a solution until they understand why it looks the way it does. And production outages have always been memorable teachers.

And just like the Starcraft muscle memory came back after just 15 minutes of playing following a ten-year hiatus, I am confident that I can go back to manual programming if I have to. Maybe I should play a match right now.