Still Bad at Software Engineering, But Now With Better Tools
In my last post I talked about building a 120k-line cloud app with Claude in three weeksāand what it's teaching me about what I actually contribute now that I'm not writing code.
But I glossed over something important: how the hell do you even manage a project that size with an agent that forgets everything?
For a while, you couldn't. Not really.
The standard approach was markdown todo lists. You'd maintain a TODO.md or TASKS.md, update it manually, hope Claude remembered to check it, watch it drift out of sync with reality. Context windows would fill up, priorities would get lost, and you'd find yourself re-explaining decisions you'd already made. It worked for small stuff. It fell apart at scale.
Then I found Beads.
Beads is Steve Yegge's answer to the long-horizon project problem. It's a task tracking system designed for agentsānot adapted for them, designed for them. Claude can query it, update it, reason about dependencies, and maintain project state across sessions without me being the one holding everything in my head. Before Beads, both Claude and I together couldn't manage the complexity of discovery on an ambitious project. The fidelity loss over time was brutal. Now I have a system that actually persists.
This matters more than it sounds like it should.
The limiting factor on agent-driven development isn't model capability. Claude can write good code. The limiting factor is continuityākeeping the project coherent across hundreds of sessions, thousands of decisions, and a context window that resets every conversation. Beads solves that. Not perfectly, but well enough that I can think in weeks and months instead of hours.
And Beads is just the beginning. Claude's built-in task tracking is getting more robust. MCP servers are enabling tighter integrations with external tools. The SDLC is slowly becoming agent-nativeānot tools that agents can use awkwardly, but tools built assuming the primary user isn't human.
I think about where this is heading and I get a little dizzy.
Right now, the skill is knowing how to wrangle agents. How to set up guardrails, enforce quality, maintain architectural coherence, predict production problems before they happen. I bring thirty years of engineering experience to my conversations with Claude, and that experience shapes outcomes in ways that wouldn't happen if you just turned Claude loose.
But that's a temporary moat. The tooling is catching up. The agents are getting better at self-correction. The skills I'm using to direct Claude today will eventually be encoded into the systems themselvesācommoditized, baked in. Subbu Allamaraju writes about this as the industrialization of software: we may be the last generation with an emotional attachment to the shape of our code.
So what happens to software engineers when the engineering part gets automated?
I don't know. Maybe we're dinosaurs watching the asteroid. Maybe we're transforming into something newāarchitects of intent, curators of quality, the humans in the loop who decide what should get built rather than how. Maybe both, with some of us adapting and others getting left behind.
What I do know is that clinging to "I write the code" as an identity is a losing bet. The code is becoming a byproduct. The thinking that shapes it still mattersāfor now.
I'm trying to get good at the thinking part before the window closes.