engineering notes
What AI-native engineering is and why it's not "coding with ChatGPT"
What AI-native engineering means: runtime thinking, architecture around models and cost control — and why it's not code generation in a chat.
In brief for executives. AI-native engineering is not “we generate code fast in a chat” and not “we bolted on a chatbot”. It is an engineering discipline: the system is designed around models as a runtime — with contracts, state, observability and cost control. The difference matters for the business because it determines project risk: one-off generation without architecture gives a fast start and an expensive, unstable result; the AI-native approach lowers risk and cost of ownership.
“We do it with AI” today means anything — from generating code in a chat to a glued-on chatbot. Because of this blur the category is substituted, and with it the expectations for risk and cost. Let’s go through what AI-native engineering is in essence.
AI-native is runtime engineering, not code-generation speed.
Hypothesis: AI-native is about runtime, not generation
The difference is not whether you use a model while developing but whether the model is part of the running system as a managed component. AI-native is designing a system where the model is called at runtime by a contract, with state, observability and a cost budget. “Coding with ChatGPT” is about the speed of writing code; AI-native is about the architecture of what runs in production.
Problem: the substitution “we do it with ChatGPT”
When AI-native is reduced to “we generate code faster” or “we added a bot”, the main thing is skipped — the runtime architecture. The result is a fast start and a system without contracts, state and cost control: impressive in a demo, expensive and fragile in operation.
2024 is the first year more duplication is introduced than refactoring. Generation speed without architecture turns into technical debt — «hidden hardcode» at scale.
Generation speed without architecture is already visible in the data as technical debt: refactoring falls, duplication grows. Fast doesn’t mean cheap to own.
Why the usual approaches don’t work
“Generated and launched” doesn’t work: one-off generation without architecture has no contracts and observability, and any process change requires a rewrite.
“Added a chatbot to the product” doesn’t work as AI-native: a bot without state and control is an interface, not a system.
“Take a more modern tool” doesn’t work: a tool speeds up writing but doesn’t set the runtime architecture; the chaos is just created faster.
Engineering model: what goes into AI-native
Runtime thinking. The model is a step of the running system behind a contract, not a one-off generator. Production behaviour is designed, not the prompt text.
Contracts and state. Typed inputs and outputs, an explicit “unsure”, process state. That is what makes the system debuggable and changeable piece by piece.
The model as a swappable primitive. The model is picked per step and replaced without rewriting the system; value is in the orchestration around it, not in a specific model.
Cost-aware by default. Cost is a metric alongside latency and reliability: per-step routing, context budget, steps without a model.
Observability. It is visible what the system did, why and what it cost. Without it there is neither debugging nor cost management.
A human in the loop. Expensive decisions pass through a human along a designed boundary, not “the model will decide everything”.
Practical takeaway for business
AI-native lowers project risk, not just speeds up the start. Ask the team or contractor: where are contracts and state; how is the model swapped; how is cost visible; where is the human in the loop. If the answer is “we generated everything fast” — that is about start speed, not a managed result.
Adoption is near-universal, but measurable business impact is rare. The gap is not access to AI — it is whether AI was taken to a managed process.
The gap between “adopted” and “got an effect” is largely the gap between AI-native engineering and “coding with ChatGPT”. The first reaches a stable result; the second more often stays an impressive pilot.
Assess the cost of ownership and of change, not the demo speed. The category a contractor works in is your risk profile.
Apply this to your processes — .
Open questions
How to hire and assess AI-native teams has no mature industry criteria; we look at runtime architecture, not generation speed. Where the limit of reasonable system autonomy lies is set by the error cost in the process. How fast the set of AI-native practices changes — fast, and that is part of the profession, not a one-off knowledge.
If you’re offered “do it fast with AI” — it is worth understanding whether that is about start speed or runtime architecture. — we’ll work out what actually runs in production and what risk profile it is.