The Cloud Group logo
Contact
logo

A junior with AI skills doesn't automatically become an architect

October 14, 2026

Artificial intelligence assistance removes the barrier of writing code, but not the barrier of knowing what code should be written. A junior developer with a good AI assistant produces significantly more volume than before, yet still cannot assess whether the structure they are creating will hold up for three years, whether the data model can handle the scenario that will arise next quarter, or whether that integration will break when the other system changes.

That's not a flaw. It's the definition of experience: having seen enough consequences to anticipate them.

McKinsey measured this precisely in its 2025 global survey: the factor most strongly correlated with EBIT impact is having fundamentally redesigned workflows, and only 211% of organizations that adopted generative AI had done so. High-performing companies are about three times more likely to have undertaken this.

It is, by far, the most actionable conclusion of the entire cycle.

What you learn by doing and what you don't

Technical expertise isn't acquired through reading, but by observing the results of one's own decisions over time. One learns that premature abstraction complicates more than it saves because one has built it and suffered the consequences. One learns where to draw a boundary between modules because it was once placed incorrectly and cost six months to fix.

Herein lies the real risk of this moment: If the assistant makes those decisions, the learning cycle is interrupted.. The professional obtains the result without having done the reasoning, and the reasoning was the learning.

The 2025 METR study points to a related phenomenon. In a trial with experienced developers on real-world tasks, participants took 19% longer using AI, while believing they were 20% faster. METR itself later reviewed that design for potential bias, and a larger cohort showed a smaller difference, so the magnitude is under discussion. What remains consistent is the decoupling between perception and reality: if experienced professionals are wrong in judging their own performance, those without prior experience are even less able to detect it.

What does change, and it's a lot, is

It would be a mistake to read this as if nothing has changed. Quite a lot has changed:

The entry curve is shorter. A junior employee is productive sooner, because syntax and mechanical tasks cease to be the obstacle.

Access to new domains is faster. Exploring an unfamiliar technology takes hours instead of weeks.

Tedious work disappears. Less time spent on setup, templates, and repetitive transformations; more time available for thinking.

The question is cheaper. Asking how something works no longer involves interrupting a colleague, which reduces the friction of self-directed learning.

The potential is real. What's needed is a structure that transforms that potential into criteria rather than volume.

The real obstacle: What truly distinguishes a senior profile from a technical one?

Ability

Junior with assistance

Senior profile

Produce code

High

High

Choose between alternatives

Limited: accepts the first one that works

Compare future switching costs

Anticipate consequences

Low score: lack of accumulated experience

Recognizes lived patterns

To say that something should not be built

Infrequent

It's part of the job

Deciding on boundaries between systems

No

Yeah

The fourth row is the most valuable and the least visible in any metric. A discerning professional dedicates a significant portion of their time to avoiding work: discarding features that add unnecessary complexity, pointing out that a rule already exists, proposing a solution one-tenth the size.

That work does not appear in any productivity indicator, and it is where much of the value of the experience is concentrated.

How to form opinions in this context

Four practices that work and require no additional structure:

Demand the explanation, not the result. Before merging, have the person explain why they feel that way and what alternative they ruled out. This is the rule we developed in The code that nobody understands is debt. [internal link].

Make the consequences visible. When something goes wrong in production, review what decision caused it and when it was made. The loop between decision and consequence is where judgment is formed, and it's often broken because the person who makes the decision isn't around when the consequences are felt.

Review decisions, not guidelines. A session on why this structure was chosen is worth more than twenty comments on style.

Rotate for maintenance. Those who maintain what others have built learn in weeks what would otherwise take years to see.

The consequence for companies

There's a clear budgetary temptation: if junior staff are more productive, the proportion of senior staff can be reduced. In the short term, the volume delivered confirms this; in the medium term, the familiar symptoms appear—changes that take increasingly longer, modules that no one wants to touch, and unreliable estimates.

The practical consequence is the opposite: As the volume of code grows, criteria become scarcer.. The proportion of review and design should increase, not decrease.

For many mid-sized companies, that doesn't mean hiring a full senior staff. It means ensuring continued sound judgment on the decisions that matter, which is the role of a External CTO or technical advisory committee [internal link]: someone who reviews architecture, supports the team, and participates in difficult decisions without needing to be full-time.

The question for the next committee

If the organization is delivering more than ever, it's worth doing a simple check: How many architectural decisions have been explicitly made this quarter, and who made them?

If the answer is that many decisions have been made and no one remembers them, then they aren't being made: they're being accepted. And accepting architectural decisions is exactly what you pay for three years later.

Frequently Asked Questions

Does AI turn a junior developer into a senior one?

No. It removes the barrier of writing code, not the barrier of knowing what code should be written. Technical expertise consists of anticipating consequences based on one's own decisions observed over time, and that isn't acquired by simply obtaining the result without having reasoned through it.

The ability to compare alternatives based on their future switching costs, to anticipate consequences based on past experiences, to define boundaries between systems, and, above all, to argue why something should not be built. Producing code is no longer a differentiating factor.

The learning cycle is interrupted: if the assistant makes the design decisions, the professional obtains the result without having engaged in the reasoning that constituted the learning process. The loop between decision and consequence is where judgment is formed.

With four practices: demanding an explanation of why the code is the way it is and what alternative was discarded, reviewing what decision caused each failure in production, dedicating review sessions to decisions rather than style, and rotating people through the maintenance of what others built.

No. As the volume of code grows, judgment becomes scarcer, not less so: the proportion of review and design work should increase. In the short term, the volume delivered suggests the opposite, but in the medium term, increasingly slow changes appear, along with modules that no one wants to touch.

Ensure consistent criteria on important decisions through an external CTO or technical advisory committee: architecture review, team support, and participation in difficult decisions, without requiring full-time dedication.

Who makes the architectural decisions on your team? Our external CTO provides senior expertise one or two days a week: architecture review, team supervision, and decisions that shouldn't be improvised. Let's talk →

Data sovereignty and control of business information
Software engineering as a competitive advantage for companies
Discover how to apply FinOps to Artificial Intelligence to control tokens, infrastructure, models and agents, measure return on investment and avoid difficult-to-sustain technology costs.