Claude Code and the other agentic coding tools have changed what an engineering team looks like. The senior engineer writes the prompt, sets the architecture, reviews the output. The junior engineer runs the code, fixes the obvious bugs, ships the change. The middle engineer, the engineer who was paid to translate the senior’s intent into the junior’s work, sits in the middle of a process that no longer needs a middle. The team that was 1 senior, 2 middle, 4 junior becomes 1 senior, 0 middle, 4 junior, with the middle tier compressed. The transition is not over. The transition is roughly 18 months in. Here is what the engineering org actually looks like in 2026, and what the implications are for hiring, compensation, and org design.
What changed in the engineering org
Three categories, in roughly that order of magnitude.
1. The senior engineer. The senior dev used to spend 40 percent of the time writing code, 40 percent reviewing code, 20 percent in meetings. The senior dev now spends 10 percent writing code (the prompt, the architecture, the test cases), 50 percent reviewing code (the AI generated code, the AI generated tests, the AI generated documentation), 40 percent in meetings. The senior engineer’s output has gone up dramatically. The senior engineer now covers the work of 3 to 5 engineers at the previous seniority level.
2. The middle engineer. The middle dev used to spend 60 percent of the time translating (the design into the implementation, the implementation into the test, the test into the deployment). The middle dev now spends 20 percent of the time translating (the prompt into the AI, the AI output into the review), 40 percent of the time on tasks the AI cannot do (the complex debugging, the cross system integration, the stakeholder communication), 40 percent looking for the next role. The middle engineer’s output has gone up modestly. The middle dev is doing the work the AI cannot do, but the middle engineer runs as the tier the AI is going to keep compressing.
3. The junior engineer. The junior dev used to spend 80 percent of the time writing the boilerplate (the test cases, the documentation, the simple features, the bug fixes). The junior dev now spends 20 percent of the time on the same work (the AI is doing the 60 percent the AI is good at), 40 percent of the time on the work the AI cannot do (the production debugging, the production deployment, the production on call), 40 percent of the time on the learning that used to be the side effect of the boilerplate. The junior engineer’s output has gone up dramatically. The junior engineer is also missing the on the job training the boilerplate used to provide, and the missing training sits as the part the engineering manager has to compensate for.
What the implications are for hiring
The demand for middle engineers has dropped. The supply of middle engineers has not (yet). The gap between the demand and the supply serves as the gap that is going to make the middle engineer the harder tier to hire for in 2026 and 2027. The engineering team that is hiring middle engineers amounts to the engineering team that is going to have to be the engineering team that pays the premium, and the engineering team that pays the premium stands as the engineering team that is going to wonder why the engineering team is paying the premium for the work the AI can do.
The demand for senior engineers has gone up. The supply of senior engineers has not kept pace. The gap runs as the gap that is going to make the senior engineer the harder tier to hire for in 2026 and 2027. The senior dev counts as the engineer who can do the work the AI cannot do, the senior engineer becomes the engineer who can review the AI generated output, and the senior engineer counts as the engineer the engineering team is going to have to compete for.
The demand for junior engineers has gone up modestly. The junior dev sits as the engineer who can do the work the AI cannot do (the production debugging, the production on call, the production deployment), the junior engineer becomes the engineer who can learn the work the engineering team needs done, and the junior engineer sits as the engineer the engineering team is going to have to invest in for the first 18 to 24 months before the junior engineer is productive.
What the implications are for compensation
The compensation for the senior engineer is going up. The senior dev stands as the engineer the engineering team is competing for, and the engineering team is competing for the senior engineer with the equity, the autonomy, the interesting work, and the cash. The senior dev sits as the engineer the engineering team cannot afford to lose, and the senior engineer runs as the engineer the engineering team is going to have to pay the premium to keep.
The compensation for the middle engineer is going down in real terms. The middle dev sits as the engineer the engineering team is compressing, and the engineering team is compressing the middle engineer by hiring fewer middle engineers, by giving the middle engineer less scope, and by paying the middle engineer less. The middle dev sits as the engineer the engineering team is going to have to make peace with, and the middle engineer amounts to the engineer the engineering team is going to have to compensate for the compression with the retention package, the severance, or the outplacement.
The compensation for the junior engineer is going up modestly. The junior dev sits as the engineer the engineering team is investing in, and the engineering team is investing in the junior engineer with the training, the mentorship, the interesting work, and the cash. The junior dev runs as the engineer the engineering team needs the most over the long term, and the junior engineer counts as the engineer the engineering team is going to have to pay the premium to keep.
What the implications are for org design
The org design is going to flatten. The middle layer of the engineering org is going to compress, and the engineering org is going to flatten around the senior engineer. The senior dev serves as the engineer who owns the architecture, the senior engineer stands as the engineer who reviews the work, and the senior engineer serves as the engineer who the engineering org is going to organise around.
The team size is going to grow. The senior dev serves as the engineer who can review the work of more engineers than the senior engineer used to be able to review, and the senior engineer becomes the engineer the engineering team is going to organise around. The team of 5 is going to become the team of 10, and the team of 10 is going to become the team of 20. The team size growth is going to require the senior engineer to invest in the management skills, the senior engineer is going to have to learn, and the management skills are going to be the senior engineer’s bottleneck.
The bottom line
The patterns the post covers have been showing up in production for long enough that the patterns have names, the failures, the mitigations, the gaps. The work the security team and the engineering team and the operations team are quietly doing today sits as the work that decides whether the practice the post names sits as a tool the team uses or a liability the team is paying for.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
