In mid-2026, the Great AI Job Replacement thesis remains unsettled. Many companies have laid off all types of employees, including those on whom they used to depend the most. "AI can do their job" is the claim heard so loudly. At best, I think those making that claim for software engineering are naive, and it probably indicates a misunderstanding of what makes software engineering valuable in the first place.

Writing code is a means to an end

The end is software that does something valuable for the people using it — something that solves a problem they actually have, within the constraints of their specific situation. Those constraints are always real and always particular: the budget available, the timeline that makes the outcome meaningful, the existing systems that have to be integrated rather than replaced, the regulatory environment that can't be ignored, or the technical debt that accumulated before you arrived.

Every software engagement is an exercise in navigating a specific set of constraints toward a specific outcome. The code is what makes the solution real. But the judgment about what problem to solve, what trade-offs to make, what's worth building and in what order — that was always where the value lived.

What's happening now is that AI has made code generation increasingly automated — and that's what's getting all the news coverage. Developers whose primary contribution was executing someone else's specification are facing a real reckoning with that shift. But the developers whose work was always about judgment — what to build, how to scope it, what trade-offs to make — aren't threatened by the same thing, because that isn't what AI does.

Problem identification is underrated

One of the most consistent patterns in software projects that go wrong is that the stated problem wasn't the actual problem. A client arrives wanting a specific feature. The feature isn't wrong exactly, but it's addressing a symptom rather than the underlying issue, and building it can make the real problem more expensive to solve later.

Identifying the correct problem, often in the face of a client who is confident they already know what it is, can be genuinely hard. It requires understanding the business well enough to distinguish between what someone is asking for and what they actually need. It requires a willingness to push back on the brief when the brief is wrong. That may be really difficult to do without some relational trust.

AI doesn't do this. It executes the specification it's given. If the specification is wrong, the output is wrong, efficiently.

The constraint environment is where expertise shows

Solving a problem under realistic constraints is a different exercise from solving it with no constraints.

An early-stage company with limited runway and a six-month window to prove product-market fit needs a different solution than an established company with a large budget of time and money. A team already committed to a specific platform needs a solution that integrates with what exists, not one that requires rebuilding everything from scratch. A company in a regulated industry needs to know which technical choices foreclose options they'll need later.

This is where software engineering expertise actually lives — in the ability to look at a specific situation with specific constraints and find the approach that produces the best outcome given all of them. It's a judgment problem. Judgment is hard to automate because the inputs are always specific and the right answer depends on understanding the context.

None of this is novel to the people who actually deliver software for businesses. Whether they're running product development, service delivery, or internal line-of-business applications, experienced practitioners have long organized their work around these realities — that getting the problem right matters more than writing the code, that constraints shape the solution as much as the requirements do, that judgment about what to build is the most consequential and expensive thing on any project. The AI job replacement thesis tends to sound the most alarming to observers of software development rather than participants in it. To the people doing the work, what's changing is what AI makes routine. What's not changing is the judgment that determines the value the work creates.

What this means for clients

If you're evaluating a development partner, "can they write good code, cheaply and quickly?" is increasingly the wrong first question. The better question is whether they understand the problem you're actually trying to solve, and whether they have the judgment to navigate your specific constraints toward the outcome that matters.

At Launch Supply, this is how we've always worked. We prioritize understanding the business problem first, asking whether the stated problem is the actual problem, and building solutions scoped to what the situation actually calls for. The emergence of better AI tools hasn't changed that approach. If anything, it's made clearer that this was always the work that brought value.

Clint Miller is a Partner at Launch Supply, a boutique software agency that builds custom software for founders and operators who need technical partners, not just coders.