The senior computer engineer's job changed shape completely. But it is not the usual eh. Not "AI helps me code faster." Not "I use Copilot for boilerplate." It is something more fundamental.
The people who actually build software — staff engineers at FAANG, solo SaaS founders, open-source maintainers — are converging on a new model of how their work works. They did not coordinate. They did not read the same memo. They all just arrived at the same place independently, and they are remarkably honest about what it feels like.
NOTE
These are rough notes. The notes would continue to evolve. By the time you read the end of this sentence, a new interesting piece on AI will emerge. It is simply hard to keep up with the pace. There is not pause. Will this post ever be finished? I don’t have answers.
Change in Work
Before June 2025, the bottleneck for converting an idea in your subconscious into virtual world was writing code. You had an idea, you sat down, and worked on code throughout the day. You typed until it worked, you fixed bugs, you shipped. The rate you could produce working software was bounded by typing speed, debugging time, and how much complexity your working memory could hold.
Now that bottleneck is gone. Not “reduced.” Gone.
- Kunal Ganglani calls this replacement “plan-and-review software engineering.”
- Qudrat Ullah calls it “Delegate-Review-Own.”
- Addy Osmani calls the engineer the “reviewer-in-chief.” Different names, same observation.
Richard Porter, six months into Claude Code, wrote the most honest version:
“I am not doing less thinking. I am doing different thinking, earlier, and writing less of it down in code.”
Porter’s piece has a subtitle that includes “the loneliness of not writing code.”
What is the new work that these people are doing? It is, according to me, the following:
- deciding what should exist,
- specifying it precisely enough that an AI agent can build it,
- reviewing the output,
- catching what the agent missed, and owning the result.
Weirdly enough, the code itself is increasingly a byproduct.
The stack that won
The Pragmatic Engineer survey (900+ respondents, mostly senior engineers) produced a surprising result: Claude Code rocketed to #1 in eight months, overtaking GitHub Copilot entirely. 75% of the smallest companies use it. Staff+ engineers are the heaviest agent users at 63.5%.
But almost nobody uses one tool. The DX Heroes field report captured the consensus:
“Most of our senior people do exactly that — Cursor for the inner loop, Claude Code for the agent loop.”
- Cursor handles the quick stuff: autocomplete, inline edits, visual workflow.
- Claude Code in the terminal handles deep autonomous work: refactors, bug hunts, multi-file changes, test suites.
This does elucidates the following: They are not competitors, but acting like the two sides of the same new workflow. Sixteen months ago Claude Code did not exist. Today it is the most-used AI coding tool among staff engineers.
Things that got easier, and Things that got harder
The easy parts are gone.
Boilerplate, CRUD configs, standard tests, middleware wiring, and all the usual software patterns, can be done by AI in seconds.
What is left is the stuff that was never easy in the first place. This includes
- architecture decisions,
- tradeoff analysis,
- debugging the genuinely weird edge case,
- figuring out what to build at all. (trivial, I know, but important)
Will Indie put it more poetically:
“AI made every idea look possible. The hard part is not creating options anymore. The hard part is killing them.”
However, there are the dark patterns too.
A Google Staff Engineer went viral for quitting because the work had become, in his telling, “rushed and less meaningful.” He was getting paged at 2 AM by complexity that AI-accelerated development had created faster than anyone could understand.
Adam Wespiser names the phenomenon: the AI Productivity Trap. “Engineers do not feel obsolete,” he writes. “They feel overloaded.” Every hour saved on execution goes straight back into harder thinking.
The Era of AI Assisted Coding
Boris Cherny is the head of Claude Code at Anthropic. In a Digg interview, he said something that kept showing up across every Reddit thread, every blog post, every discussion:
“I don’t prompt Claude anymore. I have loops running that prompt Claude. My job is to write loops.”
This is the end state. The engineer who writes prompts by hand is the equivalent of the engineer who compiles by hand. The next stage is building autonomous systems that do the prompting for you, that check their own output, that retry with different strategies when they fail. The engineer’s job becomes designing the loop, not executing it.
Iain MacKenzie ships with what he calls “a council, a sword, and a fleet of agents”. This fleet includes 40+ specialized agents running in parallel across git worktrees, coordinated by a dashboard. Around 95% of his code is AI-written.
The Software Practises of Today
Every source with actual numbers converges on the same finding: spec-first development is the single highest-leverage practice.
-
The CODERCOPS team ran the numbers across their customer base: 15-20 minutes of specification writing before generating code yields 80% first-attempt correctness. Without the spec, 30-40%. The gap is not subtle.
-
Sean Goedecke, a staff engineer writing honestly about his process: “I start every single change by asking an agent to solve the problem.”
-
Michael Bolin, OpenAI Codex Tech Lead, keeps it embarrassingly simple: write the spec in Notion, paste the URL into Codex, say “I want to build this.” That is the entire process (I kid you not, that was his exact quote).
-
Fareed Khan goes further: an Architect sub-agent produces a design spec, a Tech Lead breaks it into tasks, and a Reviewer audits the plan. No code before human approval. The pipeline itself is AI-run. The human only approves.
The new core skill: Context Management
Christina Lin wrote the clearest articulation of the constraint:
“Making any single change requires loading as little of the system as possible. Context rot is the constraint, locality of reasoning is the answer.”
In practice this means:
- A CLAUDE.md (or AGENT.md) file at every repo root, encoding architecture decisions, non-obvious gotchas, testing conventions, and what NOT to touch
- Git worktrees for parallel sessions (each with its own isolated file system)
- Checkpoints — auto git snapshots before risky operations
- Sub-agents for isolated research, keeping the main session context clean
The present engineers who do this well treat context budget the way the classical engineers used to treat memory budget.
Where AI is still bad
The consensus on what NOT to use AI for is sharper than the consensus on what to use it for.
-
Architecture decisions. TechVinta measured this: -10% to 0% productivity lift. AI is a good sounding board and a bad decision-maker.
-
Security-critical paths without a tight spec. Mijndert Stuij found “mistakes that even a junior engineer wouldn’t make” in AI-generated code: bypassable auth, no content-type checks, no rate limits. The AI does not think about rate limits unless you tell it to, and if you need to tell it to, you already had to know rate limits were a concern.
-
Naming things, API design, what to abstract. These require taste. The agent will produce something that works but is almost always a notch worse than what a senior engineer would write.
-
Writing messages that ought to be hand-written. PR descriptions, team communication, anything where the voice matters.
-
Learning foundational understanding. Stuij again: “If you lean on the model from day one you get your answers without ever doing the hard work, and the hard work is exactly how you learn to tell a good answer apart from a confident, well-formatted wrong one.”
The compounding skill
The researchers and practitioners are unanimous on something counterintuitive: senior engineers got more valuable, not less. But which skills compound has shifted.
-
Specification writing. The ability to articulate a system in precise, unambiguous natural language is now the primary engineering output, not code. Michael Bolin: “Write the spec, simple prompt, review the code.” Addy Osmani: “All our hard-earned practices — design before coding, write tests, use version control, maintain standards — not only still apply, but are even more important when an AI is writing half your code.”
-
Deep code review. Not “does this compile” review. Review that catches subtle logic errors, security holes, and architectural drift. AI-generated code looks confident even when catastrophically wrong. This skill is more scarce than ever because the volume of review work exploded.
-
Knowing when NOT to use AI. The developers who get the most from these tools are not the ones who use them the most. They are the ones who use them the most strategically. Rajamani warns about comprehension debt: “I once let AI generate an entire data-fetching layer. It looked clean, it passed my quick review. Three weeks later I hit a caching bug I could not debug — because I had never actually understood how the layer worked.”
-
Architecture and system design. This is the highest-leverage skill in a plan-and-review world. If you can design the system correctly, AI can build it. Ganglani: “If you can’t articulate what needs to be built at an architectural level, you can’t direct an AI to build it well.”
The Delegate-Review-Own model
Qudrat Ullah articulates the model teams are converging on with the clearest framework.
-
Delegate. Be intentional about what you hand off. Good candidates: first-draft implementations of well-scoped tickets, test case generation, documentation, boilerplate, refactoring passes for isolated modules. Bad candidates: anything touching security-critical paths without a tight spec, cross-system integration design, or anything where requirements are genuinely ambiguous.
-
Review. Not a rubber stamp. Effective review in an agentic workflow asks two questions: “What assumptions did the agent make that I never specified?” and “What failure modes exist that the agent was not asked to consider?”
-
Read agent output with more skepticism, not less, precisely because the code often looks clean and confident. Christina Lin calls out the specific failure mode: “If you let a boundary-violating PR pass, you have just rewritten the rules of engagement for the AI. Next week it will pull your Redis client and telemetry tracers directly into the core order pipeline.”
-
Own. The engineer, not the agent, is accountable for what ships. The role shift from creator to orchestrator does not change who carries responsibility. If anything, it sharpens: you are now accountable for the quality of your instructions, the rigor of your review, and the integrity of your approval.
How I feels about this
I should be honest: reading 30+ sources on this topic leaves an uncomfortable feeling. The tone is not triumphant. It is not scared either.
It is tired.
Every source I read describes the same dynamic: the easy work disappeared, the hard work got harder, and nobody got paid more.
The hours did not shrink. The cognitive load increased. The number of decisions per day went up, not down.
Will Indie summarized it better than anyone else I read:
“The things senior developers have always done — choosing the right problem, understanding users, defining requirements, managing complexity, making tradeoffs, saying no, taking responsibility — AI is good at the code, not at any of that. The industry spent twenty years optimizing code production. Then AI arrived and accidentally optimized it almost to infinity. Now we are rediscovering that software was never primarily a coding problem. It was a decision-making problem wearing a coding costume.”
This is what the transition feels like from inside. The costume got removed. The decision-making problem underneath was always there.
What (I think) it means
The engineers who will do best in this era are not the ones who learn to prompt best. They are the ones who learn to specify best — to write the thing that tells the agent what to build, to review what the agent built, to catch what the agent missed, and to own the result either way.
Boris Cherny’s loop is the end state. The engineer who writes prompts by hand is the equivalent of the engineer who compiles by hand. The next stage is building autonomous systems that do the prompting, that check their own output, that retry with different strategies when they fail. The engineer’s job becomes designing the loop, not executing it.
But the loop still needs a designer. The review still needs a reviewer. The ownership still needs an owner. Those are not jobs AI can do yet, and the people who know how to do them well are more valuable than ever — not despite the change, but because of it.
The industry spent twenty years optimizing code production. AI optimized it to infinity in eighteen months. We are now rediscovering that code was never the hard part.
Key takeaways from this
If you are a software engineer keeping up with this, the following are the few actionable steps you may consider in your journey.
-
Spec before code — 15 minutes of specification writing saves 1-2 hours of debugging iteration. The CODERCOPS data shows 80% vs 30-40% first-attempt correctness.
-
Two-tool stack — Cursor for the inner loop, Claude Code for agentic work. These are complementary, not competing. The Pragmatic Engineer survey confirms this is the dominant pattern among staff+ engineers.
-
Context hygiene — CLAUDE.md files, git worktrees, checkpoints, sub-agents, /compact. Context is the constraint; manage it deliberately. Christina Lin: “Context rot is the constraint, locality of reasoning is the answer.”
-
Review with skepticism — AI output looks confident even when wrong. Review boundaries, not implementations. Look for assumptions the agent made that you never specified.
-
Small PRs, fast CI feedback — Keep diffs reviewable. Right-size PRs so a human can still review them properly. Michael Bolin explicitly asks Codex: “Where does it make sense to split this change into smaller PRs?”