The conversation about AI and the future of software engineering is often framed incorrectly. It usually oscillates between two extremes (total replacement or total irrelevance). Both are intellectually lazy.

A better framing is simpler (and more uncomfortable):

AI will not replace software engineers. It will replace inefficiency.

And paradoxically, when inefficiency is removed from a profession, the profession often expands. Work does not disappear. It migrates upward (toward harder problems, sharper constraints, and higher expectations). That is the shape of this shift.

---

1) AI will not replace all SWEs (it will replace expensive, inefficient ones)

There is a popular fear that AI reduces headcount. In practice, most technological revolutions do something subtler: they reduce the cost of production, then increase the scope of what becomes worth producing.

Software engineering has always had a hidden subsidy (high cost of experimentation and slow iteration). When it was expensive to try ideas, teams needed fewer attempts and tolerated slower loops. AI changes the economics. It makes iteration cheap, exploration cheap, and “first draft implementation” almost free. That does not eliminate the need for engineers. It changes what engineers are being paid for.

The engineer who cannot compound with automation becomes expensive. The engineer who can becomes a force multiplier.

This is not about juniors versus seniors. It is about efficiency per unit of cognitive effort. If someone needs a week to do what a peer does in a day with AI assistance, the market will treat that gap the same way it treats any other inefficiency (it will price it out). The future does not punish competence. It punishes non-compounding workflows.

Here is the paradox: AI increases the value of great engineers while decreasing the value of many tasks great engineers used to do. That is why people get confused. They look at tasks disappearing and assume roles disappear too. But roles are aggregates of problems, and problems expand when costs drop.

“There is nothing so useless as doing efficiently that which should not be done at all.” (Peter Drucker)

---

2) Productivity shocks usually increase the number of roles (because they make more things worth building)

A common mistake is to imagine a fixed amount of software demand, then assume that higher productivity implies fewer engineers. In reality, demand is elastic.

When the cost of building drops:

• More products become viable
• More experiments become rational
• More customization becomes affordable
• More internal tools get built instead of postponed
• More industries digitize workflows they previously avoided

This is why automation often expands the total surface area of work. AI does not just make current teams faster. It makes entirely new categories of work economically defensible (and it lowers the barrier for smaller teams to compete).

The shift is not “fewer engineers.” It is “more engineers working differently.”

And there is another paradox here: the easier it becomes to write software, the more software we will have, and the more we will depend on it. Dependence increases the value of reliability, clarity, and governance. So the profession grows (but expectations rise).

---

3) The small-team era inside companies

This is the part many people sense but do not articulate cleanly.

Big companies will still be big. Their products will still be huge. Their compliance surface will still be real. Their customer support load will still exist. Their infrastructure will still need boring reliability.

But the center of gravity of actual product execution will keep drifting toward smaller teams.

Why?

Because AI changes the shape of the bottleneck. When implementation becomes cheaper, coordination becomes the dominant cost. And coordination cost grows non-linearly with team size.

There is a basic truth that becomes obvious once you feel it in your bones:

A team can be large and fast (but then it bleeds alignment time). A team can be large and aligned (but then it bleeds velocity). A team can be small and aligned (and that is where speed becomes sustainable).

AI magnifies this effect by compressing the “output per engineer” curve. A small team with strong context can now produce what previously required a much larger group. That does not mean every team becomes tiny. It means the efficient frontier shifts.

So you get a new equilibrium in companies:

• Fewer large delivery teams whose primary job is coordination
• More small autonomous teams that own a slice end-to-end (product, code, reliability, observability, cost)
• More emphasis on interfaces, contracts, and clear boundaries (because small teams scale through boundaries, not through meetings)

This matters for careers, because “small team leverage” becomes one of the most obvious paths to long-run upside.

In plain terms:

• If you want high salaries with less crowded roles, you want to be the kind of engineer who makes a small team feel unfairly powerful.
• If you want exposure (to business outcomes, architecture, and decision-making), small teams give you more surface area per person.
• If you want to survive in a world where code is cheap, you need to be valuable at the level where code is not the main bottleneck (system design, correctness, trade-offs, and ownership).

A small team is not a smaller job. It is often a larger job distributed across fewer people. That is why the upside concentrates there (and why the bar rises there).

“Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.” (Alan Perlis)

---

4) Learning is not obsolete (learning velocity is now the baseline skill)

This is not an argument against traditional learning, depth, or rigor. Those still matter. The difference is tempo, aka, time.

AI compresses the learning curve. It makes it possible to:

• Explore a new stack without committing months upfront
• Prototype while learning (instead of learning before building)
• Translate concepts into working artifacts quickly
• Debug unfamiliar systems with guided exploration

As a result, the market increasingly rewards engineers for:

• How fast they can acquire new mental models
• How well they can generalize across domains
• How quickly they can update beliefs when reality disagrees

The future belongs to people who can learn, unlearn, and relearn without ego.

A subtle point: “fast learning” is not the same as “shallow learning.” Fast learning is the ability to form a usable model quickly, then deepen it selectively. It is learning with intent (and with feedback loops), not just accumulation.

This is why “learning how to learn” becomes a first-class skill for survival.

---

5) Hard skills are getting cheaper

AI makes many hard skills cheaper to acquire:

• Syntax
• Framework conventions
• Routine API integration
• Boilerplate and scaffolding
• Common patterns for infra and observability

This does not mean hard skills stop mattering. It means they become less defensible as a standalone advantage.

What does not scale at the same rate:

• Judgment under ambiguity
• Communication across technical and non-technical contexts
• Trade-off negotiation (cost, risk, speed, correctness)
• Building shared mental models inside teams
• Aligning architecture with business realities

In other words, the more the implementation layer is commoditized, the more value shifts to the coordination layer.

There is a paradox here that stings: many people enter engineering to escape social complexity, and the high-leverage version of engineering becomes increasingly social (because the hard part is aligning humans around correct decisions, not typing code).

This is also why small teams matter. Soft skills compound harder in small teams (because communication overhead becomes visible, and clarity becomes a survival trait).

---

6) Specialization survives (narrow specialization dies)

Depth is not the problem. Rigidity is.

Specialists remain valuable when their expertise is transferable (rooted in fundamentals, not just in tools). They understand the underlying invariants, not only the surface-level rituals.

Narrow specialization becomes fragile when it depends on:

• Memorized procedures instead of models
• Tool-specific instincts that do not translate
• A static environment where change is slow

AI can imitate tool fluency. It cannot replace foundational reasoning as easily. That is why deep specialists who can generalize will still thrive (and narrow specialists who cannot will feel the floor moving).

---

7) Overengineering has been normalized

When code is cheap, complexity becomes the dominant expense.

Over the last decade, we normalized complex defaults:

• Distributed systems for problems that are not distributed
• Kubernetes as a universal answer
• Event-driven architectures where a monolith would be simpler
• Tooling stacks that require an entire platform team to maintain

These choices have real benefits (availability, scalability, fault isolation). But they also introduce real costs:

• Operational overhead
• On-call complexity
• Debugging depth
• Systemic fragility
• Higher verification burden

AI accelerates shipping. But faster shipping into a complex system does not create velocity. It creates churn (more moving parts, more hidden coupling, more failure modes). AI does not remove the tax of complexity. It may even amplify it by making it easy to add components that feel “reasonable” but were never necessary.

“Simplicity is a prerequisite for reliability.” (Edsger W. Dijkstra)

---

8) Greenfield vs brownfield (why strategy differs, and why it matters now)

Two contexts matter:

• Greenfield (building from scratch, unconstrained by legacy systems).
• Brownfield (building within legacy constraints, technical debt, and organizational inertia).

In brownfield, complexity is often inherited. The work is about containment, migration, and risk reduction.

In greenfield, complexity is a choice.

In the AI era, greenfield success increasingly comes from:

• Clear macro-architecture
• Explicit domain boundaries
• Better specifications
• Strong invariants
• Delayed irreversible decisions
• Simplicity preserved intentionally

This is a shift in emphasis (less obsession with implementation detail, more investment in modeling and specification). If implementation is cheap, the competitive advantage becomes “building the right thing with the right constraints,” not “handcrafting every line.”

This is also where small teams shine. Greenfield work punishes bureaucracy. A small, high-context team can move from idea to validated system before a large org finishes aligning on terminology.

“A complex system that works is invariably found to have evolved from a simple system that worked.” (John Gall)

---

9) AI-generated code makes code review a first-order problem

One of the most underestimated issues in AI-assisted development is reviewing.

AI can generate code that is:

• Clean
• Idiomatic
• Coherent
• Plausible

But plausibility is not correctness.

Traditional code review works best with incremental changes and familiar intent. AI often produces larger chunks of code at once. The diff may be readable, but the mental model behind it is not always obvious.

This creates a paradox: as code becomes easier to produce, it can become harder to trust.

The bottleneck shifts from writing to verification.

---

10) Formal methods are not academic vanity (they are the missing verification layer)

This is where formal methods return as practical leverage, not as bureaucracy.

When you specify invariants formally, you reduce the review problem. You are no longer asking reviewers to rely on intuition (“does this look right?”). You are asking the system to enforce properties (“does this satisfy the specification?”).

Formal methods (proofs, contracts, invariants, strong type systems) do two things extremely well:

1. They constrain AI output (so the model produces code within a defined space of correctness).
2. They reduce the cost of verification (by turning correctness into a checkable obligation).

In a world with cheap code, verification becomes the scarce resource. Formal methods are a way to spend scarce attention efficiently.

And yes, this is also persuasive for the AI-agnostic crowd: you do not need to worship AI to benefit from it. You can treat it as a stochastic generator and still build a deterministic correctness pipeline around it. The point is not faith. The point is engineering.

---

11) Types and proofs are communication tools (between humans and machines)

Types and proofs are often treated as complexity. In practice, they are a language for clarity.

They provide:

• Unambiguous intent
• Explicit boundaries
• Machine-checkable constraints
• Better prompts than natural language

When intent is formalized, AI becomes more reliable because the output space is constrained. And when systems are constrained, complexity is reduced because fewer invalid states exist.

---

12) Why learning Coq and Lean is a rational bet

This is why I recommend learning Coq and Lean.

Not because every engineer should become a formal methods researcher, but because proof assistants train the exact skill set that becomes scarce:

• Precise reasoning
• Model-first thinking
• Separating specification from implementation
• Understanding invariants as primary artifacts

They teach you to build software with fewer hidden assumptions (and fewer invisible traps). In the long run, the engineers who can formally reason about systems will have disproportionate leverage (because they can verify what others can only hope is correct).

---

13) The real moat is reasoning under change (even if AI shifts, fails, or plateaus)

AI will evolve. Tooling will change. Some approaches will fail. Some hype will collapse. Some paradigms will persist.

That uncertainty is precisely why the moat is not a tool.

The moat is the ability to reason under change:

• To detect what is durable and what is noise
• To adapt without losing clarity
• To learn faster than the environment changes
• To pick architectures that minimize future regret
• To validate correctness when velocity is high

The paradox is that the future looks automated at the surface (faster code, faster shipping), but becomes more human at the core (judgment, clarity, coordination, and correctness).

AI will not end software engineering. It will raise the baseline and punish non-compounding workflows. It will expand the surface area of what engineers can build. And it will reward the engineers who can make small teams feel disproportionately powerful (because they can think clearly, specify precisely, and ship without drowning in their own complexity).

---

Conclusion

The AI era will not be defined by who can “write code faster” (code is becoming abundant). It will be defined by who can think clearly under change, convert ambiguous intent into explicit constraints, and ship systems that remain correct when the environment shifts.

Big companies will still be big, but the winners inside them will increasingly be small, high-context teams (teams that can move without drowning in coordination). That is also where individual careers concentrate upside (more ownership per person, more exposure to outcomes, higher leverage, and fewer seats for people who cannot compound with automation).

If you want long-run security, your moat is not a framework. It is a portfolio of meta-skills (learning velocity, judgment, communication, and formal reasoning) that makes you useful even when the tooling landscape changes (or even if some AI approaches plateau). Learn to learn fast. Keep your architecture simple until complexity is forced. Use AI aggressively, but verify rigorously. And when correctness matters, lean on proofs and strong types, not intuition.

---

---

Just a quick note

In 2026, I’m gonna be using this blog more recurrently, will talk less on X and other social medias, so, if you care, subscribe to the RSS feed.

opinionAI (Artificial Intelligence)swe (Software Engineering)careersformal proofingcode reviewarchitecture (tech)learning