AI-native coding is an engineering system

AI-native coding usually gets demonstrated the same way. Describe a feature, watch the files appear, fix whatever breaks, move on.

The demo is genuinely impressive. It is also the easy part.

At SAI Technology we have come to treat AI-native coding as an engineering-system problem rather than a model problem. The model matters. What surrounds it matters more: what the agent knows before it starts, which rules it cannot bend, what counts as proof that it worked, and where our own authority begins.

We are not trying to generate the most code. We are trying to shorten the distance between a well-understood problem and a dependable production outcome, without giving up security, product judgment, or operational control on the way.

AI-native does not mean engineering-light

AI has made implementation cheap. It has done nothing to make ambiguity, weak architecture, unsafe migrations, missing tests, or unclear ownership cheap. If anything, it prices them higher.

A model will reproduce an inconsistent pattern across twenty files in the time it takes a person to get it wrong in three. It will take a vague ticket and return a large, confident pull request that misses the business rule entirely. Left running in a review thread, it will keep accommodating comments until a focused change has quietly doubled in size.

So our first principle is the boring one. AI works inside the engineering system, not alongside it.

Nothing about production has changed. Tenant boundaries are still tenant boundaries. Money still requires exact arithmetic. Durable events still need idempotency and a recovery path. Anything a user touches still needs its loading, empty, error, restricted and mobile states. And a green build still tells you nothing about whether the right thing was built.

What AI-native engineering asks for is not less discipline. It is discipline written down clearly enough that a person and an agent can both follow it.

Context became infrastructure

An agent is only as good as the world it can see.

So every repository gets a canonical orientation layer. Before an agent edits anything, it should be able to answer the basic questions without guessing: which source owns the schema, where authorization is actually enforced, how background work gets queued, which of these arguments were already had and settled.

We layer that deliberately:

• repository guidance for the product and its non-negotiable rules
• a short current-state document that separates what is shipped from what is merely planned
• architecture decision records explaining why the important boundaries exist
• active specifications for larger changes
• runbooks for local verification, release, recovery, and day-to-day operations

None of this is the same as pouring a repository into a context window. More text is not more context. Context earns its place when it is current, scoped, ordered, and traceable back to something that can be checked.

The same rule holds outside the repository. Plane carries delivery intent and acceptance criteria. GitHub carries the branch, the review, and the check state as they actually are. Logs and monitoring carry what happened at runtime. Slack threads, meeting notes and documents can explain why a thing was wanted, but they never outrank current code or a verified production state.

Durable memory is worth keeping — decisions, recurring lessons, the reasoning behind a rule. Live systems still have to be re-read every time. An agent remembering that a pull request was clean yesterday says nothing about the commit sitting at its head today.

We have argued before that context is the real AI advantage. In delivery, context sits closer to a control plane than to background reading.

Standards are judgment, written down

Experienced engineers carry an enormous amount of judgment they never articulate. They know which migration will become a problem at 2am, when a service has quietly crossed a module boundary, and that the small change to the money code is not small.

Agents get useful in proportion to how much of that becomes explicit.

Our shared standards cover the ground you would expect — architecture and API design, framework patterns, migrations, tenancy, auth and secrets, testing, observability, Git and release workflow, design-system usage. Repository instructions then add the domain rules that never generalise.

Precedence is the part that actually matters. Company standards set the floor. Repository guidance specialises them. An approved architecture decision can carve out a deliberate exception. A ticket can narrow scope, but it cannot quietly weaken a security or data boundary on its way past.

We also grade work by risk, because treating a copy change like an authentication change is a reliable way to make everyone stop reading the rules. A read-only report is not a ledger. CI configuration, migrations, external write integrations, infrastructure and permissions need more evidence and stronger approval. Payments, irreversible production data changes, and recovery execution stay human-led.

Speed aimed in the wrong direction is just faster rework. The grading is what keeps the aim honest.

A ticket is a contract the agent takes literally

An agent is very good at completing the task it believes it was given. The believing is where things go wrong.

So we write implementation tickets as contracts: the problem and enough business context to make sense of it, the repository and module, expected behaviour, acceptance criteria, explicit non-goals, risk, a test plan, and whatever the rollout needs.

Acceptance criteria have to be observable. “Make it secure”, “handle edge cases” and “improve the UX” are wishes, not done conditions. A criterion that works names a starting state, an action, a result, and the evidence that will show it — for the failure paths, the permission checks and the tenant boundary, not only the happy one.

Size matters as much as wording. The default unit of delivery is one bounded ticket, one branch cut fresh from the current default branch, one pull request that can be reviewed on its own. When the work turns up a second problem — and it usually does — that becomes a follow-up rather than a quiet extension of the first PR.

That small-batch habit has produced more of our AI efficiency gain than any improvement in prompting. Large diffs drift from their context, collide on merge, exhaust reviewers and complicate rollback. Worse, they tend to get approved because nobody can hold the whole change in their head any more.

The loop matters more than the model

The interesting question is less about which coding model is best this month, and more about how much of a delivery loop that model can complete without a person shuttling artefacts between systems.

Our agents work with the repository and the terminal, and with everything around them: Plane for the live ticket, GitHub for pull requests and review threads, a browser for the actual rendered interface, Figma for design intent, Vercel for preview state, Grafana and service logs for runtime behaviour. Document, communication and scheduling tools come into scope when a task genuinely depends on them.

The payoff is continuity. An agent can trace a requirement into the code, implement it, run the focused tests, look at the resulting page, open the PR, and write the ticket update from evidence it gathered rather than from its own intentions.

Access is not authority, though. Tools are scoped, sensitive writes are approval-gated, and production credentials do not go into model context. An agent should see enough to reason and act inside its task, and nowhere near enough to behave like an administrator.

We also keep the process off any single model or provider. Models will keep changing, and quickly. The durable investment is the context, standards, tools and workflows that let whichever model we are using contribute safely.

Skills make the good version repeatable

A prompt is a good way to get something right once. A skill is how you get it right the fiftieth time.

We package the workflows that have proven themselves: taking a Plane ticket to a review-ready pull request, auditing a PR at its exact head, working through unresolved review comments, producing and visually verifying a document, turning approved design context into code.

What makes a skill more than a long prompt is that it fixes the order of operations: which evidence gets gathered first, where execution stops, what completion actually requires, and when the agent should stop and ask.

Our ticket-to-PR skill is a fair example. The agent has to resolve live ticket intent, read the repository guidance, isolate a ticket-sized change, run validation proportionate to the risk, review its own final diff, publish a complete PR, then go back and re-fetch the exact head, the checks, mergeability and ticket linkage. A commit is not completion. A pushed branch is not completion. A PR URL is not completion either, if nobody knows what CI did with it.

Skills are also where lessons go to survive. When the same review failure appears twice, the answer is never “be more careful next time”. It is a better test, a clearer standard, a sharper ticket template, or a change to the skill itself.

Guardrails keep speed from turning into bloat

AI is extremely good at producing valid change. Not all of that change should exist, so we watch both correctness and shape.

Alongside the usual lint, type, test, build and migration checks, our guardrails target the failure modes that come specifically from generated code:

• type-aware lint rules that catch floating promises and unsafe async behaviour
• TypeScript strictness raised through measured, ratcheted baselines
• every API route required to declare an explicit authentication mode
• PR-size and changed-line budgets, so oversized work is visible before review
• already-large files that cannot grow further without a named waiver or an extraction plan
• detection of new dependency cycles and prohibited module crossings
• flags on explicit any growth and raw form controls used outside the design system
• builds that must leave the source tree clean instead of committing generated output

Ratcheted is the load-bearing word there. The failure we are avoiding is switching on every strict rule at once, discovering hundreds of historical violations, and teaching the team that CI is something you work around. Instead we measure where we are, stop new debt, and lower the ceiling on purpose. New rules usually land in advisory mode first, so false positives surface before anyone is blocked.

Waivers exist, but they are visible and they expire. A waiver names the rule, the measured value, the reason, the owner, the plan to decompose the problem, and the date it runs out. That turns an exception into a decision somebody made and signed.

Evidence has to attach to this exact commit

Generated code needs the same testing pyramid as handwritten code, with extra suspicion around false confidence. We start narrow, with the unit or contract test that proves the changed behaviour, then expand by risk: integration tests against a real database, end-to-end browser flows, migration rehearsals, production builds, role-specific smoke tests.

A reporting endpoint we worked on recently shows why. It returned totals that looked entirely plausible. It also stopped after 200 records without saying so, ran exact monetary values through floating-point arithmetic, and allocated fractional container costs with no guarantee that the parts added back up to the whole. Making the test green would have taken a few minutes. The actual fix was complete bounded pagination, decimal arithmetic maintained all the way to the response boundary, deterministic allocation of residual cents, and regression fixtures sitting above the old limit.

That is exactly the kind of defect AI will happily produce and, given the right questions, help eliminate. Which one you get depends on whether the delivery system asks them.

Review runs on the same footing: the exact current head, the ticket, the surrounding code, the changed files, the tests, CI, mergeability, and any unresolved threads. High-risk changes get independent review lenses — security, tenancy, data, frontend contracts, operations, rollback — and those findings are consolidated afterwards, because more reviewers otherwise just means more noise.

Every new commit invalidates the evidence it touched. An approval on an earlier SHA is not an approval of this code. “CI was green” and “CI is green on this head” are different statements.

Merging is not the finish line

We are standardising on structured, searchable logs: request IDs, safe user and tenant context, status, duration, consistent levels. A dashboard should let you separate healthy traffic from real errors, follow an application failure back to the request that caused it, and compare services without learning a different log dialect for each one.

Queues need failure visibility, retry limits, idempotency and reconciliation. Releases need immutable identity, a migration plan, smoke checks, a monitoring window and a way back. A job that generated the PDF but lost the notification is not done. A deployment that succeeded and then failed its production smoke test is not done either.

So we stay precise about delivery state: local, committed, pushed, reviewed, approved, merged, deployed, verified. Agents are very good at reaching local completion. Operational closure is still engineering’s job.

Where human authority begins

The point was never to keep a person in every keystroke, only to spend people where authority actually sits.

An agent can inspect, plan, implement bounded work, run tests, prepare a review, draft release evidence, and reconcile routine state. We keep product ambiguity, architecture exceptions, risk approval, merges, production migrations, deployments, client communication, and anything destructive or financially consequential.

Drawing that line clearly makes things faster, not slower. The agent stops asking permission for safe, reversible steps. It also never gets to infer permission to touch production or approve its own work.

Nexus, our internal operating layer, runs on the same principle: intelligence can prepare the work, but authority stays explicit, attributable and auditable.

Measure outcomes, then fix the system

The wrong metrics produce the wrong behaviour quickly. Lines of code, prompts sent, tokens consumed, agents named — none of it says anything about whether delivery improved.

The signals we watch are duller and more honest: time from a ready ticket to a merged change, PR size, first-attempt CI success, rework after review, escaped regressions, rollback frequency, and whether repeated feedback ever becomes a durable improvement.

Then the loop is simple enough to actually run:

1. notice where delivery slowed down or failed
2. work out whether the cause was context, scope, architecture, implementation, tooling, or review
3. fix the ticket, test, standard, skill or guardrail responsible
4. check whether that class of failure gets rarer

That is where the compounding comes from. The model does not remember last month’s mistake. The system does.

AI-native coding is going to keep getting faster. The teams that get the most out of it will not be the ones generating the most code. They will be the ones who built the clearest environment for intelligence to do accountable work.

That is the system we are building at SAI Technology.