A few months ago I walked into what would once have been a routine presales workshop. The client had a business problem, a rough vision of the product, and far more questions than answers. We worked through workflows, integrations, compliance requirements, architecture, timelines, and technology choices. By the end of the meeting we had a first solution architecture, an implementation strategy, an infrastructure outline, an initial estimate, and enough confidence to discuss realistic delivery scenarios.

None of that felt unusual. What struck me was how it happened.

Ten years ago almost every one of those topics would have required its own meeting. Infrastructure questions went to an infrastructure specialist. Security waited for someone with the right background. Architecture was reviewed by senior engineers, product assumptions were validated separately, and no one committed to an estimate until several technical leads had weighed in. This time, most of those conversations happened in the same room, with the same handful of people.

No one there held the combined expertise of an architect, a cloud engineer, a product manager, and a security specialist — and the answers weren't final. They didn't need to be. Crossing disciplines had simply become dramatically cheaper.

Over the past year I've watched engineers move comfortably between conversations that used to belong to different specialists. One moment they're discussing business trade-offs with a client; the next they're sketching an event-driven architecture, validating infrastructure assumptions, or generating a working prototype. They are rarely the leading expert in any of those disciplines, and increasingly they don't need to be.

That observation stayed with me, because I don't think it's primarily a story about artificial intelligence. I think it's a story about economics.

Software engineering has always organized itself around whatever was hardest to obtain.

In the early decades, that resource was predictability. Projects were expensive, slow, and difficult to change, so requirements had to be captured up front — changing direction later was prohibitively costly. Waterfall wasn't born because engineers disliked iteration; it emerged because, given the constraints of the time, predictability was the most valuable thing an organization could buy.

As software became interactive and markets grew more dynamic, a different scarcity emerged: learning. Organizations could no longer afford to spend two years building a product before discovering whether anyone wanted it. Agile answered that. Short iterations, continuous feedback, and incremental delivery lowered the cost of learning. The lasting argument about Scrum and story points and stand-ups misses what made Agile work — it was never about ceremonies. It was an organizational response to an economic constraint. When learning became expensive, organizations optimized around learning.

Today another constraint is beginning to dominate, not because Agile failed but because the economics have shifted again.

For most of my career, learning a new technology meant a serious investment. If your team adopted Kubernetes, someone spent months on networking, deployment models, observability, and operations before they could contribute with any confidence. Moving from backend into mobile or cloud wasn't a weekend project. As the field expanded, specialization became inevitable: mobile became its own discipline, data engineering separated from backend, security became a specialization of its own, and modern software grew too broad for any individual to master.

Organizations adapted rationally. Rather than expecting individuals to know everything, they assembled teams of specialists — and in doing so traded one problem for another. Every specialist brought real expertise and also introduced another dependency, another handoff, another review, another synchronization point. Large software organizations became extraordinarily good at coordinating expertise, because that was exactly what they were designed to do.

Most conversations about today's transformation start with artificial intelligence. That's the symptom, not the cause. The deeper change is that knowledge has become dramatically cheaper to acquire — and that claim needs a careful definition, because knowledge is not the same as expertise.

Knowledge answers how. How does this framework work? How is this cloud service configured? How do I implement this authentication flow?

Expertise answers why. Why does this architecture fail under load? Why is this elegant-looking solution impossible to operate in production? Why have experienced teams made the same trade-off for a decade?

Judgment answers something else entirely: whether. Whether a thing should be built at all. It weighs technical decisions against business outcomes, recognizes uncertainty, and knows when experience matters more than confidence.

Artificial intelligence compresses the cost of acquiring knowledge. It does not compress years of operational experience, and it certainly does not replace judgment. That distinction is becoming one of the most important in modern software engineering.

A capable engineer can now become productive in an unfamiliar domain remarkably quickly: enough infrastructure to deploy a service, enough frontend to build an interface, enough database design to model a solution, enough machine learning to stand up a prototype. That doesn't make them an expert; it makes them useful far earlier than was previously possible. The cost of reaching usefulness has collapsed. The cost of reaching mastery has not.

That single change reaches well beyond developer tooling. It changes how organizations can be structured, how products get discovered, what clients expect, and ultimately what makes an engineer valuable.

At this point most experienced engineers get skeptical, and I've had the same reaction myself. If everyone can suddenly work across disciplines, won't we just produce more bad software?

The concern is legitimate — in fact it names the biggest risk of this transition. Cheap knowledge produces a new class of mistakes, and they aren't the obvious kind. They're convincing. Code that looks correct. Architectures that read as reasonable. Infrastructure decisions that work beautifully until real traffic arrives six months later. The failure mode is no longer ignorance; it's false confidence.

That is precisely why expertise becomes more valuable, not less. The organizations that benefit most from cheap knowledge won't be the ones that eliminate specialists; they'll be the ones that change how specialists are used. Historically, expertise had to be embedded into delivery because knowledge itself was scarce. As knowledge becomes abundant, expertise stops being a permanent dependency and becomes strategic leverage. Cheap knowledge doesn't dilute expertise — it concentrates it.

The shift shows up most clearly in how teams coordinate.

Every coordination mechanism is a trade. Stand-ups, planning, backlog refinement, cross-functional alignment, architecture reviews — none of these are wasteful, and on large teams they're essential. The mistake is assuming that because a practice solves one problem, it solves every problem.

Picture two organizations building the same product. The first relies on eight specialists spread across frontend, backend, infrastructure, security, QA, design, product, and delivery. The second relies on two highly capable engineers who move comfortably across most of those disciplines and pull in specialist expertise only when complexity genuinely demands it. Both still need communication, but not the same kind.

The first team depends on standing coordination. It's permanent, because expertise is permanently distributed: every feature crosses several ownership boundaries, so synchronization becomes part of everyday work. The second depends on deliberate coordination. Expertise is still there, but it's pulled into the process on purpose rather than wired into every step. A security expert reviews the design when security gets hard. A database specialist joins when scaling assumptions turn uncertain. A compliance expert validates regulatory decisions before release. The organization still benefits from deep expertise; it simply stops paying for it continuously.

That's one of the most important organizational shifts now emerging. The future probably won't eliminate specialists. It's far more likely to eliminate unnecessary handoffs.

The clearest signal of this change isn't inside engineering teams. It's in conversations with clients.

Ten years ago, technical discussions tended to open with technology. .NET or Java? React or Angular? AWS or Azure? Monolith or microservices? Those questions still come up, but they're no longer the first ones. Clients now arrive with a different kind of uncertainty: where AI genuinely creates value, which ideas deserve investment, how to validate assumptions before spending millions building the wrong thing, how to move quickly without taking on reckless risk. Technology is only one piece of that.

So I've come to think clients aren't really buying software anymore. They're buying confidence: that someone understands both the business problem and its technical consequences, that hard trade-offs are being made deliberately rather than by accident, that somebody owns the outcome instead of merely delivering a backlog. That's a fundamentally different relationship.

It also changes what makes an engineer valuable. When implementation was expensive, implementation expertise was the industry's most prized asset. Implementation is now increasingly assisted; decision-making isn't. The engineer who creates the most value isn't necessarily the one writing the most sophisticated code; it's the one asking better questions. Should this feature exist? Does this architecture solve tomorrow's problem or yesterday's? Is this complexity essential or merely interesting? What assumption are we making that nobody has validated? Those aren't product questions or engineering questions. They're ownership questions, and ownership has always been hard to scale.

It's tempting to call this the return of the full-stack engineer, but that misses something. The early full-stack engineer spanned the stack because the stack was small. Today's generalist spans disciplines because crossing them has become cheap. This kind of generalist doesn't replace deep specialists — they connect them: enough product to shape discovery, enough engineering to weigh trade-offs, enough infrastructure to make sound architectural calls, enough business to see where value is actually created. Most importantly, they know where their own understanding ends. Cheap knowledge manufactures confidence; good judgment knows where confidence becomes dangerous. That may turn out to be the defining trait of the next generation of engineering leaders.

If I were starting my career today, I would still invest deeply in technical fundamentals; nothing here argues otherwise. Strong engineering remains the foundation of everything. But I would spend at least as much time on the things engineering careers have often treated as secondary: how businesses make decisions, how products fail, how customers describe problems, how organizations create incentives, how trust gets built, how uncertainty gets reduced. Languages, frameworks, and models will keep changing. Those skills will stay valuable precisely because they sit outside technology. They're human.

Every era of software engineering has been organized around its scarcest resource. Waterfall optimized for predictability when change was expensive. Agile optimized for learning when finding the right product was expensive. For two decades, organizations optimized around knowledge, because knowledge itself was expensive. That assumption is now weakening, and AI didn't create the shift so much as accelerate it.

The consequence isn't that software engineers become obsolete. It's that the bottleneck moves toward judgment, ownership, and the reduction of uncertainty. When I started thinking about this essay, I thought I was writing about artificial intelligence. Somewhere along the way I realized I wasn't. AI is just the catalyst that made a deeper, economic shift impossible to ignore. We're not living through another tooling revolution; we're at the start of an organizational one. And in an age where knowledge is abundant, the most valuable engineers of the next decade won't simply be the ones who write the best software. They'll be the ones who help organizations understand what's worth building, why it matters, and how to move from ambiguity to outcome with confidence.

LinkedIn ↗