What Is AI-Native Engineering? Rethinking the Tech Stack

If AI is expanding what we can build, shouldn’t it change how we decide to build it?

AI is changing the relationship between having an idea and being able to build it.

I can start with an idea, explore tools and technologies I’m not yet familiar with, and work with AI to turn that idea into something real. Things that once required me to first learn a new technology can now begin with curiosity, experimentation, and a willingness to learn along the way.

It got me thinking. If AI is expanding what we can build, shouldn’t it also change how we approach building it?

If I were starting a new software project today, would I choose the same tech stack if AI agents were going to build much of it?

What does AI-native engineering mean?

IBM’s analysis of AI-native systems draws a clear line between AI-augmented tools and AI-native architecture. AI-augmented systems use AI as an add-on or supporting feature, like a code autocomplete plugin in an editor. AI-native systems are designed from the ground up with AI as a foundational component shaping architecture and execution.

In much the same way that the industry shifted from desktop to mobile-native development (where apps were rebuilt around touchscreens and mobile networks rather than shrinking desktop interfaces), engineering practices are approaching a similar transition.

AI-native engineering means choosing our technologies, architecture, and workflows with AI capabilities in mind, so that AI agents can build and improve software effectively while humans remain accountable for the results.

This is my working definition, not a universal industry standard.

Using AI to write code faster is helpful. Rethinking how we choose languages, design interfaces, and structure verification harnesses because agents are doing the building is a much bigger shift.

Would I choose the same tech stack today?

Imagine starting a new project from scratch.

Most of us have our preferences. We know certain programming languages, frameworks, and databases well. There are good reasons to stick with what we know, especially when reliability and maintainability matter.

But suppose AI could work effectively with several languages. Should I automatically choose the one I know best? What if another ecosystem made it easier for agents to understand the codebase, implement features, diagnose failures, and test their changes?

I would want to explore that possibility.

This does not mean choosing the newest technology or abandoning proven tools. A mature ecosystem with reliable libraries, good documentation, and predictable conventions might be exactly what an AI agent needs.

We should choose technologies based on what the project needs and how effectively AI can work with them, not just on what we have always used.

Even the creator of Ruby on Rails makes us rethink the stack

While researching AI-native engineering, I came across an interesting example from David Heinemeier Hansson, better known as DHH, the creator of Ruby on Rails.

At Rails World 2026, he spoke about rebuilding parts of his company’s HEY email product with AI agents. His plans included native applications and a Rust backend.

What caught my attention was his take on Rust. He openly described how much he disliked reading and writing the language himself, yet he was enthusiastic about what agents could produce with it.

His memorable conclusion was:

I love Rust! Rust is amazing if you never, ever, EVER have to look at it yourself.

It is a provocative way to describe a changing relationship between engineers and their tools.

DHH also estimated that the planned HEY architecture could dramatically reduce CPU and memory requirements. Those estimates apply to the broader architectural change, including moving to native applications, rather than proving that Rust is inherently better than Ruby.

For me, the interesting part is not whether Rust wins against Ruby. It is the shift in how we might make the decision.

Traditionally, we consider how easy a language is for engineers to write, read, debug, and maintain. Those things still matter. But if an agent can implement and test a language that I would not have chosen for myself, should my personal comfort remain the deciding factor?

Perhaps the more useful question is whether the resulting software meets our requirements and whether we can reliably verify, operate, and maintain it.

That is a different way of thinking about technology selection.

Should we let AI choose everything?

Not blindly. But I do think we should give AI more room to explore solutions we might not have considered.

The key is distinguishing between constraints and preferences.

Constraints are things the solution genuinely needs to satisfy, such as latency, security, data residency, operating costs, and compatibility with existing systems.

Preferences are choices we tend to make because they are familiar. A particular language or framework might still be the right choice, but we should be willing to question it.

I would start by giving AI the problem, the expected outcomes, and the constraints. Then I would ask it to propose viable approaches, explain the trade-offs, and challenge my assumptions.

After that, I would test its recommendations rather than simply accepting the first answer.

Be opinionated about the outcomes we need, but open-minded about how AI helps us achieve them.

How I would approach a new project

I would start with four steps.

1. Define the problem, not the stack.

Describe what we are building and what success looks like. Establish the functional requirements, performance targets, security needs, budget, and operational expectations.

2. Ask AI to explore alternatives.

Have it propose a few viable stacks, including options I might not normally consider. Ask why each option makes sense, what the trade-offs are, and how well agents can work with it.

3. Test the options on real work.

Build a representative feature. Let agents implement it, run tests, investigate failures, and make corrections. This tells us much more than debating technologies in the abstract.

4. Choose based on evidence.

Compare software quality, implementation effort, debugging, human intervention, performance, security, and cost. Choose what works best for the actual project.

The aim is not to find one universally perfect stack for AI. It is to have a repeatable way to find the right stack for each project.

The stack is bigger than the framework

There is one more thing I would change about how we think about a software stack.

We usually mean programming languages, frameworks, databases, and infrastructure. In AI-native engineering, we also need to consider the models and agents, the context they receive, the tools they can use, and how they verify their work.

Thoughtworks explores this broader view in its five building blocks of AI-native engineering. OpenAI’s harness engineering article provides another practical example of why repository context, tools, and automated feedback matter.

A technology might be powerful but difficult for an agent to navigate. Another might offer predictable conventions, reliable documentation, and strong automated testing, making it easier to use effectively.

We need to evaluate the whole development environment, not just the framework at its centre.

Start with a different question

I don’t think AI makes engineering judgment less important. It gives us an opportunity to apply it differently.

We can spend more time defining problems, exploring alternatives, evaluating trade-offs, and creating environments where AI can do reliable work. We can also explore technologies beyond our usual comfort zone and learn as we build.

AI-native engineering does not mean giving AI unlimited freedom. It means understanding which constraints are necessary, which preferences are worth reconsidering, and where AI can help us find a better approach.

If I were starting a project today, I wouldn’t begin by asking which tech stack I prefer. I would ask: given what AI can do today, what is the best way to build this software?

I don’t have a universal answer. The answer will evolve as models, tools, and engineering practices improve.

What matters is being willing to explore those possibilities instead of assuming the way we have always built software is necessarily the best way forward.

For me, that is where AI-native engineering begins, before the first line of code.

---

This is the first in a series exploring AI-native engineering.