What I Actually Do Now That Claude Writes the Code
After 12 months and 75K lines of AI-generated code, my job looks nothing like it used to. It's harder in different ways.
David's been writing about PairCoder from the product and philosophy side. This is the view from inside the codebase.
I write a lot less code lately.
I'm a full stack engineer. Flask backends, Azure cloud services, DBs, SharePoint integrations, React frontends. I've written tens of thousands of lines of production code with my own hands. That was the job. You think through a problem, you open your editor, you write the solution, you debug it, you ship it.
That's not what I do now.
Now I spend my day defining what needs to be built, setting up the context so Claude builds it correctly, reviewing what comes back, and making architectural decisions about systems that get constructed in minutes instead of weeks. The output is 10x what it used to be. The job isn't easier. The difficulty moved.
If you're a developer watching AI tools evolve and quietly wondering what your role becomes, this is what I've found so far.
When the AI writes code fast, the bottleneck becomes what to build and how it should fit together.
Decisions that used to emerge gradually over days of coding now need to be made upfront. Module boundaries, file structure, separation of concerns, API contracts. All of it matters more, not less, because the agent will build whatever you describe. Including the wrong thing. Instantly. With tests.
I used to be able to feel my way into an architecture. Start writing, let the structure reveal itself, refactor as patterns emerged. You can't do that when the AI generates 500 lines of code in three minutes. If the architectural direction is wrong, you've now got 500 lines of confidently wrong code with passing tests to untangle.
So I spend significantly more time on decomposition. Breaking features into tasks that are the right size. Defining boundaries before any code gets written. Writing acceptance criteria that are specific enough to actually verify. This is engineering work, arguably the most important engineering work, but it doesn't look like coding.
The review problem is where things get genuinely hard.
AI-generated code looks right. It compiles. Tests pass. It does what you asked. The variable names are sensible, the structure is clean, the comments are helpful. It's better-looking code than most humans write on a first pass.
But reviewing code you didn't write, at the volume an AI produces, is a fundamentally different cognitive task than reviewing a colleague's pull request. With a human PR, you're checking logic, style, and edge cases against your understanding of the problem. With AI output, you're doing all of that plus verifying that the code solves the right problem, not just the problem as the AI understood it.
That gap between "correct code" and "code that correctly implements the intent" is where bugs hide in AI-augmented development. Claude will build you a beautifully structured module that handles edge cases you didn't think of and quietly misinterprets the core requirement. It's not wrong. It's precisely right about the wrong thing.
PairCoder's enforcement gates help reduce the surface area. If the architecture check passes, I don't need to worry about file bloat. If acceptance criteria are verified, the agent at least addressed every checklist item. If tests pass, the basics are covered. The gates handle mechanical verification so I can focus on the judgment calls: does this design make sense? Will this approach hold up as the system grows? Is this the right abstraction?
I now spend a meaningful chunk of my working time writing English. Task definitions. Acceptance criteria. Architectural constraints. Skill files that describe our preferred workflows. Context documents that explain how different parts of the system interact.
The quality of Claude's output is directly, almost linearly, proportional to the quality of the context I provide.
This isn't prompt engineering in the "magic words" sense. It's closer to writing a really good technical specification, except the reader is an AI that will immediately act on every sentence. Ambiguity that would be fine in a spec for a human developer becomes a source of silent misinterpretation with an agent. The agent doesn't ask. It infers. And its inferences are plausible enough that you might not catch the drift for hours.
Context engineering requires the same systems thinking that good architecture does: understanding what information is essential, what can be inferred, what will be misunderstood if left implicit. The craftsmanship shifted from the code to the specification.
I want to push back on a narrative I see a lot: that AI coding tools represent some sudden, binary shift. Developer one day, prompt engineer the next.
Long before Claude Code existed, long before PairCoder, I was pair-coding with ChatGPT in a browser window. No IDE integration. No codebase access. Just me, a chat interface, and a lot of careful copy-pasting.
That workflow already required serious context engineering. I'd think through a problem, reason about the approach, then figure out how to describe enough context for the model to produce useful code. I'd paste the relevant file, explain the constraints, describe the interfaces, and iterate on the output. It was slow, manual, and required as much engineering judgment as writing the code myself. Maybe more, because I had to be explicit about things I'd normally just know.
PairCoder didn't create my workflow. It formalized it. The skills, the context files, the enforcement gates are the productized version of what I was already doing by hand. The tool caught up to the practice.
David came to software development through AI. His background isn't in writing code. It's in building things, and AI gave him the tools to build with code. He has a natural ability to articulate context, to describe systems and constraints and intent in language that translates directly into strong output from AI models. He built real, production features of PairCoder this way.
My role was different. I'd review what he built, give architectural feedback, catch the structural issues that only show up when you've built enough systems to recognize the patterns. Where a module needed decomposing, where an abstraction was leaking, where a design decision would cause problems at scale.
That dynamic, someone building production software primarily through AI and an experienced developer guiding the architecture and quality, isn't just how PairCoder was built. It's what PairCoder is for. The enforcement gates, the acceptance criteria verification, the architecture checks encode engineering judgment into the system so it applies consistently, whether the person at the keyboard is a senior developer or someone whose primary skill is context engineering.
David needed guardrails that would catch the things he didn't know to look for. I needed a way to scale my review capacity beyond what manual inspection could handle. PairCoder is the intersection.
The raw coding muscle has atrophied. I'll be honest about that. I don't write as much code by hand as I used to, and the fluency fades when you don't exercise it daily.
But that shift started long before PairCoder. It started when I began pair-coding with ChatGPT in a browser. It started when I realized that my engineering value wasn't in typing syntax but in understanding systems well enough to direct their construction.
The old dopamine, the satisfaction of hand-crafting an elegant function, getting the logic just right, that moment when a clean piece of code clicks into place? Largely gone.
It was replaced by something I didn't expect. There's a different satisfaction in watching an entire system, one that embodies your standards for clean code, your architectural principles, your dedication to quality, get scaffolded and built in days instead of weeks. When bpsai-pair arch check blocks a task because a file hit 400 lines, that's my standard being applied. When acceptance criteria verification catches an incomplete task, that's my review instinct, automated.
The craft is still there. It just scales now.
My title says Technical Director. What I actually do is make sure the AI builds the right thing, the right way, and build the systems that enforce that consistently.
Architecture. Review. Context engineering. Defining quality standards and encoding them into gates. Thinking about software at a higher level of abstraction than I used to, while staying close enough to the implementation to catch the things that only experience reveals.
I still build software every day. I just build it differently now.