Claude Code changed what a great engineer looks like
At Every, two engineers used Claude Code to ship like a team of fifteen by making every task improve the next one.
I’ve been using Claude Code for months. I run multiple agents, use voice input, open more terminal windows than any reasonable person should, and occasionally convince myself I am operating some kind of miniature software empire.
I thought I had a decent handle on it.
Then I watched how the engineering team at Every worked. Two engineers were running six agents, turning spoken feature ideas into research, implementation plans, working code, tests, and documentation. Features seemed to materialise from voice commands while the humans moved between agents, reviewed decisions, and kept the whole thing pointed in roughly the right direction.
That was when I realised I had misunderstood the important part. I was using Claude Code as a faster pair of hands. Every was building an engineering system around it. Kieran Klaassen, a senior engineer at Every who works on its email product Cora, calls this approach compound engineering.
The phrase sounds like something an AI consultant would put on a slide immediately before charging you $40k, but the idea behind it is useful.
Each piece of work should make the next piece of work easier.
Most people use AI to complete a task. They ask for code, review the output, fix what is wrong, and move on. When the next task begins, the agent often starts with the same incomplete context and makes many of the same mistakes.
Compound engineering treats each correction as reusable knowledge. The feature gets built, but the lesson also gets recorded in the project instructions, tests, documentation, or review process.
The work does not merely get finished. The system gets slightly better at doing similar work again.
What compound engineering actually means
Imagine Claude builds a new login flow using the wrong authentication pattern.
You catch the mistake, explain the correct approach, and ask it to rebuild the feature. In a normal AI workflow, the problem is fixed and everyone moves on with their lives. The next agent session may make exactly the same mistake because it has no memory of what happened.
In a compound workflow, the correction becomes part of the engineering system. The team documents the correct authentication pattern, adds an automated check, updates the project instructions, or creates a reusable workflow that future agents can follow.
The bug gets fixed once. The entire category of mistake becomes harder to repeat.
That is where the compounding happens.
Every did not arrive at this system neatly. The team moved through Copilot, Cursor, Windsurf, and other tools, hitting limits as the technology evolved. Claude Code became important because it could take on a larger unit of work. It could inspect the codebase, edit files, run commands, work with Git, test the result, and keep going without waiting for someone to approve every line.
The visible breakthrough was the ability to run several agents at once. One could work on the front end while another handled the back end. A third could write tests and another could update documentation.
But opening six terminals is not the same as managing six productive agents. Without a good plan, you have simply created six confident interns with access to production code.
Why Claude Code feels different
The first generation of AI coding tools mostly helped developers complete the line in front of them. They suggested functions, found errors, and saved time on repetitive work.
Claude Code can be given responsibility for a much larger outcome. Instead of asking it to write a function, you can ask it to investigate a problem, understand how the existing system works, make changes across several files, run the tests, and prepare the work for review.
The unit of delegation has changed.
That creates real leverage, but it also creates a much larger blast radius. An autocomplete tool might suggest one bad line. An autonomous agent can make a bad architectural assumption, spread it across twenty files, update the tests to approve it, and then write a beautifully structured explanation of why everything went so well.
The output often looks convincing long before it is correct.
That is why the engineer’s role does not disappear. It moves towards the parts of engineering that were always hardest to automate. Understanding the real problem. Choosing the architecture. Spotting hidden risks. Knowing which compromises are acceptable. Recognising when something technically works but creates a terrible product.
Claude can handle more implementation. The engineer still decides whether the feature deserves to exist, what could break, and what good looks like.
The typing may shrink while the responsibility expands.
The stack is not the advantage
It is tempting to turn this into another tool list.
Buy Claude Code Max. Install a voice tool. Open six terminals. Connect GitHub. Download someone’s prompt library. Announce on LinkedIn that you are now a 100x engineer.
The actual setup is surprisingly ordinary.
Claude Code, isolated workspaces, strong project instructions, useful tests, and perhaps voice input if speaking is faster than typing for you.
The advantage comes from the operating discipline around those tools. The team has to define work clearly, separate tasks properly, review output carefully, and capture what it learns. Without that discipline, more agents create more noise. With it, a small number of capable engineers can produce an extraordinary amount of work.
This is what makes the Every example so interesting. The story is not simply that two engineers can produce the output of fifteen. The deeper point is that engineering output is beginning to separate from engineering headcount.
For decades, companies estimated capacity by counting people. Ten engineers could normally build more than two because ten people had more hands, more hours, and more total coding ability.
Agents weaken that relationship. Two engineers with strong judgment and a well designed AI system may now outperform a much larger team that still works in a traditional way.
Most companies have no idea how to plan around that.
Hiring has not caught up
Technical hiring still places enormous weight on how well someone writes code by hand. Candidates are asked to solve abstract problems on a whiteboard or produce clean code while several strangers silently watch them through a video call.
Those skills still tell you something. They no longer tell you enough.
An engineer working effectively with agents needs to know how to frame a problem, provide the right context, divide the work, evaluate competing approaches, and detect plausible nonsense. They also need the taste to reject output that passes every test but still makes the product worse.
A more useful interview would give the candidate a real but safe codebase and a small feature to build using whatever AI tools they normally use. Ask them to explain the plan before they begin. Watch what they delegate, what they keep for themselves, and what questions they ask.
Then ask them to show one piece of agent output they rejected and explain why. Finally, see whether they leave behind an instruction, test, or document that makes the next similar task easier.
The final code matters, but the process reveals far more.
Did they understand the problem before building?
Did they spot the dangerous assumptions?
Did they know when the agent was bluffing?
Did they leave the engineering system stronger than they found it?
That begins to look more like the job these people will actually be doing.
The junior engineer problem
There is an uncomfortable consequence hiding inside all this productivity.
Founders will inevitably look at a senior engineer supervising five agents and see labour arbitrage. If one experienced person can produce the work of an entire team, why keep hiring junior developers?
That may save money in the next budget cycle. It may also create a serious talent problem several years later.
Junior engineers were never only cheap people who completed routine tasks. Those tasks were how they learned. They developed judgment by writing code, breaking things, reviewing mistakes, debugging systems, and gradually understanding why senior engineers made certain decisions.
If agents take over most of that implementation work, companies need a new way to create experienced engineers. You cannot expect someone to review complex AI generated systems if they never had the opportunity to build and break simpler systems themselves.
“No junior developer required” sounds clever in a product demo.
It is a terrible workforce strategy.
The companies that solve this apprenticeship problem will have a major advantage. They will use agents to increase productivity while still giving less experienced engineers enough real responsibility to develop judgment.
The companies that stop hiring juniors altogether may eventually discover that they also stopped producing seniors.
This reaches beyond engineering
The same change is already moving through marketing, design, analysis, and operations.
A marketer can ask AI for 50 campaign ideas in a few minutes. That output used to feel valuable because producing 50 ideas took time. Now the ideas themselves are abundant, and most of them sound like they were written by an enthusiastic committee that has never met a customer.
The valuable marketer builds a system that understands the company’s voice, customer objections, competitive position, legal constraints, previous performance, and the difference between a bold idea and something that will get everyone invited to an emergency meeting.
The same is true in design. Generating screens becomes easier, while deciding which experience makes sense remains difficult. Analysts can produce reports faster, but someone still has to question the data, examine the assumptions, and recognise when a beautiful chart is confidently explaining something that never happened.
First drafts are becoming abundant.
Coherence is still expensive.
The people who benefit most from AI will not simply be those who generate the highest volume of work. They will be the ones who build systems that produce consistent work, learn from mistakes, and remain aligned with what the company is actually trying to do.
What a great engineer looks like now
The argument about whether AI will replace engineers is already too simplistic.
It will replace parts of engineering work. Routine implementation, boilerplate code, documentation, testing, and basic debugging are becoming easier to delegate. Some roles will shrink and some teams will get smaller.
At the same time, good judgment becomes more valuable because one person’s decisions can now be executed across several agents at once. An engineer who understands architecture, product, risk, and context can direct far more work than before.
That is the real lesson from Every.
Two engineers producing the work of fifteen is not only a productivity story. It is a warning that the way companies hire, manage, and evaluate engineers is falling behind the way software is now being built.
I started using Claude Code as a coding tool. I now see it as something closer to a management layer for software creation. The strongest engineers will know how to create clear systems, teach agents how the company works, review output ruthlessly, and recognise when speed is making the wrong problem worse.
The best engineer in the room may soon write the least code.
They will still carry the most responsibility.
See you out there.
Martin
p.s. this is a must-watch