The New Stem
I realized a few months ago that I no longer write code. Not a function. Not a fix. Not even a config tweak. I'm just now getting comfortable with it.
What changed wasn't the modelsâthough they keep getting better. What changed was me. I leaned into the discipline: strict quality gates, deterministic tools like Beads for long-horizon work, aggressive context management, LSP integration for semantic feedback, subagent delegation for parallel work. The pillars of software that survives. Once those were in place, I started getting the outcomes I wantedâand I stopped needing to touch the code to get them.
I'm still not 100% comfortable ceding control. But I see the writing on the wall.
I've had this debate with colleagues who haven't spent as much time here, or who come from higher-stakes production work where caution is warranted. The distrust of agent code runs deep. Most still advocate reviewing every line, if not writing it themselves. And I get itâif you haven't built the guardrails, you shouldn't trust the output.
But given the right constraints, agents write better code than I do. What I contribute now is disciplined application of architectural patternsâreminders to review, refactor, check for SRP violations before the file becomes a junk drawer. Agents are better at comprehensive testing and refactoring than I ever was, and they're ridiculously faster. They don't get daunted by challenging change sets. I do.
Here's the paradox that trips people up: agents know engineering best practices. Ask Claude about SOLID principles and it'll give you a better explanation than most senior engineers. But that knowledge doesn't translate to intuitive application. Left unsupervised, Claude will build a god object while explaining why god objects are bad. This mismatchâsuperficial omniscience, absent judgmentâmakes agents feel like charlatans rather than coworkers. It erodes trust.
The skill is knowing how to close that gap. Bringing the constraints. Learning to articulate exactly what you wantâand recognizing in advance where you've left too much to interpretation, unless ambiguity is what you need. Optimizing for agent ergonomics and quality outcomes at the same time. That's what differentiates an engineer using agents from anyone else creating software with them. Without the experience to impose strict discipline on the process, you get sloppier outcomes and form negative opinionsâespecially once you hit production and have to maintain the thing.
In The Kitchen Sink Engineer, I wrote about T-shaped skills getting widerâeveryone expected to do everything. But I'm starting to think the shape is changing entirely. The old stemâlanguage fluency, framework expertise, the ability to write code at allâis migrating to the top of the T. Broad experience that informs judgment. The new stem is agent orchestration itself. How to set up projects for success. How to build the guardrails that make trust possible. How to get quality without reading every line.
The sands are shifting daily. Workflows that worked last month need adjustment. The agentic dev environments keep improving, but they're still all over the mapâevery setup requires you to bring your own constraints. Developing and deploying that understanding is the difference between letting agents own the code with confidence and not trusting them at all.
Maybe in a year or two this all gets baked in and stable. Those of us running on the leading edge will wonder why we bothered. But for now, it's the skill that matters most. And it's becoming the deepest one I have.