Why Most Companies Are Not Building an AI-Native SDLC

Here is a good example.

From a local perspective, this is progress. Test automation becomes cheaper, more scenarios can be automated, and teams can generate tests much faster.

But from a system perspective, very little has changed.

We still wait until the feature exists before asking many important questions: What can go wrong? Which edge cases exist? Which business rules are ambiguous? What happens when a dependency fails? Which behavior should be tested at unit level? Which interaction needs an integration test? Which scenarios actually require E2E coverage?

AI enters the process late because the process itself was designed for a world where humans had to perform most of this work manually.

The most important input into software development is not code. It is intent.

What are we trying to build? How should it behave? What should happen in unusual situations? What should never happen? What assumptions are we making?

Traditionally, this information lives across requirements, acceptance criteria, product documents, architecture discussions and people's heads. And that input is often incomplete.

The result is familiar: missing details are discovered during implementation, contradictions during integration, edge cases during QA, and incorrect assumptions sometimes only in production.

AI gives us an opportunity to move this reasoning much earlier.

Before development starts, AI can review requirements for ambiguity, missing behavior, conflicting rules, boundary conditions, failure scenarios, permissions, dependencies and missing acceptance criteria. It can ask questions that otherwise might appear days or weeks later.

This is where AI-native delivery starts.

Not with generating more code. Not with generating more E2E tests. With defining what needs to be built much better.

If requirements become structured and detailed enough for AI to understand them, they stop being only documentation.

They can become an input into engineering.

This changes the role of requirements.

Instead of being a document that developers read and QA later interprets, the specification becomes a source from which parts of the implementation and verification strategy can be created.

And importantly, AI can help decide where each behavior should be verified.

A pricing calculation may belong in unit tests. An interaction between two services may need integration tests. API compatibility between teams may need contract tests. An external provider may be better covered using a fake or controlled integration. Only a critical user journey may actually need E2E coverage.

This is very different from generating 100 browser tests after development is complete.

The goal is not to maximize the number of automated tests. The goal is to verify each behavior at the fastest, cheapest and most reliable level.

This may be one of the most important changes.

Historically, software teams optimized heavily for engineering time.

Every additional test had a cost. Someone had to understand the scenario, write the test, create fixtures, build mocks, prepare test data, debug it and maintain it later.

This created practical limits.

Maybe 80% unit test coverage was good enough. Only important integration paths were automated. Some edge cases stayed manual. E2E automation focused on critical flows because E2E tests were expensive to build and maintain.

Those decisions were rational. They reflected the economics of engineering work.

But AI changes those economics.

The marginal cost of creating another unit test can become much lower. The cost of creating mocks, fakes, fixtures and datasets can become much lower. The cost of analyzing hundreds of scenarios can become much lower.

This does not mean every company should suddenly target 100% code coverage or generate thousands of tests. More tests are not automatically better.

But it does mean that some engineering practices were built around constraints that may no longer exist.

Which engineering limits are technically necessary, and which ones exist because overcoming them used to be too expensive?

If creating broad unit and integration coverage becomes significantly cheaper, then the balance of the testing pyramid can change.

We may be able to build much stronger lower layers and depend less on expensive downstream validation.

AI may also change what we measure.

Today, teams often use code coverage as a quality signal: "We have 82% unit test coverage."

But code coverage tells us which code was executed during tests. It does not tell us whether every important business behavior was verified.

An AI-native process could make another metric practical: specification coverage.

Imagine that a requirement contains 20 expected behaviors:

The conversation then becomes different.

Instead of asking "How many tests do we have?" or "What percentage of our code is covered?", we can ask:

Is every important behavior in the specification verified somewhere?

That is much closer to the actual purpose of testing.

AI-native does not mean putting an LLM into every stage of development.

It means reconsidering the process around capabilities that did not exist when the process was designed.

Some handoffs may become unnecessary. Some activities that were previously too expensive may become standard. Requirements may become structured inputs into automated engineering workflows. Testing may move much earlier. E2E suites may become smaller because lower levels become much stronger.

We have seen a similar pattern with other technology shifts. The biggest value rarely came from adding a new tool while keeping everything else exactly the same. It came when organizations changed the way software was designed and delivered.

AI is likely to follow the same path.

The first stage is augmentation: developers write code faster, QA engineers generate tests faster, product teams create requirements faster.

The next stage is redesign.

Most AI adoption conversations today focus on productivity.

How much faster can developers code? How much faster can QA create automation? How much faster can teams create documentation?

Those are useful questions, but they are optimization questions.

What would our software delivery process look like if we designed it today, knowing that AI exists?

Would requirements still look the same? Would QA discover ambiguity after implementation? Would we accept the same level of unit and integration coverage? Would we need the same number of E2E tests? Would engineers still manually create the same amount of test data, mocks and fixtures?

Many of the answers may be different.

And that is the larger opportunity.

The next stage of AI adoption is not about attaching better AI tools to every step of the existing SDLC.

It is about questioning whether the steps, boundaries and economic trade-offs of that SDLC should still exist in their current form.

Most companies today are using AI inside the old software development lifecycle.

The bigger opportunity is to build the software development lifecycle around AI.