AI Is Teaching Me How Bad I Am at Software Engineering
Three weeks ago I started a cloud app with Claude. It's now 100k lines of Go, 20k lines of TypeScript and React, extensive test coverage across unit, integration, e2e, concurrency, and load. By my math, that's easily more than a year of solo work compressed into less than a month.
Here's the uncomfortable part: I'm pretty sure the code is better than what I'd have written alone. Cleaner architecture. Less tech debt. More thorough tests. The version of this project where I white-knuckle every line would be worse.
So what exactly am I contributing?
Mostly I'm a disorganized human with a lust for immediate gratification, and agent-driven dev amplifies that beautifully. The whole thing is one giant stream of commits. No issue tracker. No sprint planning. No agile ceremonies. Just vibes and velocity.
I like it this way. I'm also pretty sure it's "wrong."
And yet—turns out I'm contributing quite a bit. Just not code. I bring engineering judgment. The stuff that's easy to skip when you're racing toward "it works": quality gates, strict compiler rules, linter configs that enforce complexity limits and prevent god objects, test coverage that isn't optional, architectural principles that get documented in skills so they're not forgotten. Left to its own devices, Claude will happily GSD without any of that. So would I, honestly. The difference is I know we'll regret it.
There's an interesting synergy here. I'm bad at disciplined, methodical, structured engineering and organization—always have been, it's limited me. Claude is great at structuring chaos, but only in small scopes. Ask it to write a well-organized function (or write a blog post from raw notes) and it nails it. Let it build a system over time without supervision and it drifts toward monoliths, reactive hacks, stovepipes. Context windows fill up. Architectural decisions made last week become suggestions from a past life.
So I end up being the one who insists on refactoring, who checks that the abstractions still make sense, who enforces the quality bar either manually or through automation. Claude provides the structure I lack at the micro level. I provide the structure Claude lacks at the macro level. Neither of us could do this alone.
Steve Yegge talks about building massive projects now without ever looking at the code. I'm feeling that. It makes me nervous, but once the guardrails are in place—once Claude is producing at the quality level I need—the code becomes almost immaterial. I feel like I've always imagined architects and product owners feel when working with engineering teams: shaping outcomes without sweating implementation details.
Except I'm not just waving my hands. I know enough about production architecture that I can predict problems and ask Claude to solve for them before they hit production. That's the skill now. Not writing the code. Knowing what the code needs to do, how it'll break, and when "good enough" actually is.
I'm still figuring out what that makes me. But I'm pretty sure it's not "software engineer" in the way I used to understand the term.
There's more here—about the tooling that makes long-horizon projects possible, about what "software engineer" even means when the engineering part gets automated. But that's a longer conversation.
Continued in Still Bad at Software Engineering, But Now With Better Tools.