15 May 2026

How a senior engineer works in 2026

These days the agent writes about 90% of the code. I pay Anthropic $200 a month for it. My job is to perfect what it produces and to write the parts that set the whole thing up: the config, the setup files, the scaffolding that tells the agent how this codebase works. My output is higher than any prior year I’ve worked.

Ten years of writing code by hand bought me the only skill the new workflow rewards: judging code, not producing it. The shape of the job changed inside three years. The daily ritual below is what the new job actually looks like, and at the end I’ll get to the part that matters most if you train developers: the pipeline that produces the next generation of seniors is closing.

Claude Code is not a chatbot

Every task I take on starts the same way. I open a terminal, type claude, and a session starts. Claude Code is an agentic harness built by Anthropic. It’s the difference between a chat window that answers questions and an agent that does the work. The agent reads my project files directly, edits them, runs tests against them, and reports back.

Then I spend about five minutes drafting a prompt. The prompt names the goal, the constraints, the parts of the codebase that are relevant, and the way I want the work checked. A weak prompt looks like “add login.” A strong one names the existing auth file, the password rules I want enforced, the test coverage I expect, and what the agent should do if it gets confused. Five minutes on the prompt saves an hour of corrections later. The best return I get on any block of time in my day.

Prompting is a skill and it took practice. The instinct is to type the request the way you’d type a message to a colleague. That produces weak results. The strong version came from a year of writing prompts, reading what the agent did wrong, and learning which kinds of detail the agent actually uses versus which kinds it ignores.

The setup that stops the hallucinations

A fresh agent dropped into a codebase will produce work that compiles and is wrong, because it has no context for the team’s decisions. Three pieces of structure fix this.

First, a CLAUDE.md file sits at the root of the project. It’s a plain English document that explains what the codebase is, the workflow rules the agent has to follow, and the conventions the team keeps. The most useful part is a section of “wrong vs right” code-pattern examples: the actual mistakes the agent made before, paired with the version I want instead. The agent reads it at the start of every session, so it doesn’t repeat the same mistake twice. This is the company handbook, written for the agent.

Second, skills. A skill is a small reusable instruction file the agent pulls in when a task matches. I have skills for reviewing my own work like a hostile critic, for verifying a change by driving the running app instead of trusting the tests, and for the deployment conventions of the platform I build on most. The agent recognises the task and picks the skill up automatically. Skills are how a single person teaches the agent the parts of their craft that don’t fit into a one-line prompt.

Take the hostile-critic skill. It’s a reviewer pass that hunts for the bugs I missed: logic errors, edge cases like empty arrays and null inputs, race conditions, and security gaps like auth bypasses and injection. The rule is that a finding only counts if I can describe a concrete trigger that makes it fail. That kind of judgment is exactly what doesn’t fit in a one-line prompt, which is why it lives in a reusable skill instead of getting retyped every time.

Third, deterministic checks. Whenever the agent edits a file, my setup runs four tools against it: a linter that catches mistakes in under a second (oxlint), a typechecker that catches whole categories of bugs (tsc), a dead-code detector (Knip), and a formatter (Prettier). The linter is the one that runs after every single edit. I keep a lint:quick command that finishes in under a second, so an error introduced on edit two gets caught before it cascades through edits three to ten. On top of that I run a hardened tsconfig with noUncheckedIndexedAccess turned on, which makes every array[i] return T | undefined and forces a guard at every spot an agent would otherwise assume an element exists. That one setting catches a class of bug agents produce constantly. What none of these tools can tell me is whether the code does what the business actually wants. The agent sees the failures, fixes them, and tries again, with no input from me. By the time the work reaches me, the structural mistakes are already gone and I can focus on whether the work was the right work.

What I actually do now

The job is reading and judging, not typing.

When the agent finishes, I read the diff. The diff is the set of changes the agent proposes to make to the codebase. I read it carefully. Did the agent understand the task? Did it pick the right pattern? Did it cut a corner that will cost us in six months? Did it touch files it shouldn’t have? Did the tests actually exercise the change, or did the agent write a test that passes regardless of whether the code works?

If something is wrong, I describe what’s wrong and the agent fixes it. If the architecture is wrong, I say so, and the agent rewrites the larger pattern. The cycle continues until the diff is acceptable, then I commit it.

I’m structurally a manager of one. The thing I manage is fast, doesn’t take time off, costs a tiny fraction of a salary, and will redo a piece of work six times in a row without complaint. It also confidently produces wrong code, misunderstands subtle parts of the problem, and writes tests that lie about whether the code works. It needs a serious reviewer on the other side.

Why the ten years are still load-bearing

The agent does the typing. I do the judging. The judging is what ten years of writing code by hand bought me.

I can read a diff in fifteen seconds and tell whether the agent has picked the right abstraction, because I’ve picked the wrong one enough times to recognise the shape of it. I can spot a security mistake because I’ve made one. I can tell when the agent’s confidence is misplaced, because I have been the engineer whose confidence was misplaced. The agent writes code I could have written ten years ago, but I would have written it badly, and I wouldn’t have known why it was bad until production told me.

The studies that claim AI tools don’t make people faster are usually right about the people they measured. A randomised trial published by METR in July 2025 found that experienced developers were 19 percent slower with AI tools than without, while reporting afterwards that they had been 20 percent faster. The 2024 DORA report from Google found a parallel pattern: individuals feel more productive, team throughput drops by 1.5 percent, team stability drops by 7.2 percent.

The studies aren’t capturing the speedup because most people using these tools haven’t learned how to use them. The speedup is real. It only shows up for the people who put the work in to get there.

The junior engineer is mostly gone

A senior engineer with the right setup does the work that used to need a team of five juniors. This isn’t a forward-looking prediction. It’s happening now.

Stanford’s Digital Economy Lab tracked employment for software developers aged 22 to 25 since the start of generative AI tools. That cohort is down about 20 percent from its late-2022 peak. Developers in their thirties and forties have continued to grow. Salesforce told investors in early 2025 that the company wouldn’t add any more software engineers. Shopify circulated an internal memo requiring managers to prove a job can’t be done by AI before approving new headcount.

“We are the last generation to manage only humans.”
Salesforce, February 2025

The displacement compresses from the bottom. The senior who orchestrates absorbs the work of the juniors who used to type. This is the part most decision-makers underestimate, and it’s storing up a real problem. The pipeline that produces tomorrow’s seniors is closing while most training still teaches the same syllabus it taught five years ago: writing functions by hand, memorising syntax, producing the boilerplate an agent now produces for free. The field still needs new people. It doesn’t need them to type the code any more.

What it needs is people who can do the new job from day one: prompt an agent precisely, read a diff and catch the corner it cut, set up the deterministic checks that stop the hallucinations, and articulate the difference between acceptable work and unacceptable work. None of that is on the old syllabus. The training that matters now teaches developers to orchestrate agents, and the programs that retool around that produce people the market actually wants to hire. The ones that keep drilling hand-written boilerplate are graduating people into a job that no longer exists.

The position

A senior who learns to orchestrate an agent does the work of five juniors. A senior who refuses to learn becomes the bottleneck of the team. A junior trained on the old terms walks into a hiring market that no longer needs what they were taught.

Two things decide whether a developer thrives in this shift. The first is deterministic checks: programming has compilers, type systems, test suites, and linters, so the agent can be wrong and a tool catches it before the human looks. The second is a clear vocabulary for what good work looks like. The developer who can articulate the difference between an acceptable output and an unacceptable one moves five times faster than the one who can recognise quality but can’t describe it. Tacit knowledge does not transmit to an agent. Articulated knowledge does. Both of those are teachable, and neither is on most curricula yet.

The next twelve months will sort the people who train developers into two groups: the ones retooling around agent orchestration, and the ones still graduating juniors into a job that closed. The teams that win this round won’t have the best agents. They’ll have the people who know exactly what to ask the agents for.