AI-first delivery, without the hand-waving

What does AI-first delivery actually mean?

AI-first delivery means engineers use AI assistance inside the normal delivery loop — reading unfamiliar code, drafting scaffolding, generating tests, performing mechanical migrations — while review, ownership and accountability stay exactly where they were. It is a change to how a specific category of slow work gets done. It is not a change to who is answerable for what ships.

The honest measure is throughput per engineer on particular kinds of task. It is not a headcount reduction, and it is not a quality multiplier.

This is also where the phrase forward deployed engineer becomes concrete rather than decorative. An engineer reading your unfamiliar code with AI assistance is doing it against your repository, your schema and your production behaviour, not against a specification written in a supplier's office. The assistance is only worth anything when it is pointed at the real system, which is an argument for working inside your environment rather than a claim about the model.

It is worth separating two claims that suppliers routinely blur. One is that a firm builds AI features — retrieval, evaluation, guardrails, the parts that make a model safe to put in front of a customer. The other is that its engineers use AI in their own work. We do both, and they are different capabilities held by different people. Every person we place is trained in the second, including the SAP and Oracle consultants, the BI developers and the testers; the first is a specialist group.

Where it genuinely helps

• Understanding legacy code. The most valuable use we have found. Undocumented systems that used to take a fortnight to map can be understood in days. What you get is a starting hypothesis, not a finding — every part of it has to be checked against the running system — but it replaces a week of reading with a day of checking, and it makes modernisation work tractable that otherwise stalls on nobody being willing to start.
• Test coverage. Generating the unglamorous cases nobody writes by hand — boundary conditions, error paths, fixtures. With one caution that matters: tests generated from an implementation assert what the code does, not what it should do, so they lock in bugs as faithfully as behaviour. Use them as a proposed list to prune.
• Migration and refactoring. Mechanical, repetitive, well-specified transformations across many files, where the result is checkable in bulk because the diff is repetitive and the existing tests still have to pass.
• Scaffolding. The first eighty per cent of a component, endpoint or migration that follows an established pattern the codebase has already set eleven times.
• Tooling nobody had time to build. The auditors, comparison scripts and one-off extractors that catch regressions. These used to be skipped because they were not the deliverable; they are now cheap enough to be worth writing, and they pay for themselves the first time one fails a build.
• Parallel work on separate files. Several strands of mechanical work can run at once — provided the shared scaffolding is written first, by a person, so the strands cannot collide on the same route or module.

Where it does not help

Architecture. Domain modelling. Deciding what the business actually needs as opposed to what it asked for. Anything where a confident wrong answer is expensive.

Generated output is fluent, which is precisely the problem — it reads as correct. We treat it with more suspicion than hand-written work, not less. Four failure modes from our own log, because they are more useful than a general warning:

• Inference presented as fact. A client list was assembled from an accounting export, and two large names went onto a slide because they appeared in it. A ledger records suppliers as well as customers, and one of the two was the accounting software the export came from. Presence in a dataset is not evidence of the relationship you assumed it meant.
• Plausible filler is worse than obvious filler. A bulk pass replacing placeholder text on a website was applied by field type rather than by section. It filled four invented testimonials with credible-sounding product copy, turning something obviously fake into something that read as a real customer endorsement. That is a materially worse outcome than the placeholder it removed. The fix was to delete the widget: there is no honest version of a testimonial nobody gave.
• A tool that measures the wrong thing, confidently. A site auditor reported every page as missing a meta description. It was auditing a different project's dev server that happened to hold the port it assumed. It now refuses to run until the page under test proves it is the right site.
• A check that fails for its own reasons. A verification script nearly reported a working pricing calculator as broken, because the script searched the markup for an attribute the inputs do not carry. On its first full run the same auditor produced 217 findings, of which 134 were noise from one bad selector — enough to bury the real signal completely.

The pattern in all four is the same, and it is the thing to design against: the output was fluent, internally consistent, and wrong. Speed makes that more dangerous, not less, because it lets a wrong assumption be applied across a hundred files before anyone reads the second one.

How do you stop generated work being wrong in a way that looks right?

By making verification a separate act from production, and by preferring a check that can fail over a report that says it passed.

• Check the claim, not the summary. When work is reported as complete, the evidence is the running system — the URL that returns 200, the number the page renders, the row in the table — not the description of what was done.
• Compute the expected answer independently. When two pricing calculators were ported between codebases, the formulas were compared line by line against the source, the default outputs were computed by hand, and those numbers were matched against the rendered page.
• Capture before and after. A remote API's success message is not proof the state changed. Read it back.
• Prove the check before trusting it. A test you have not seen fail is not a test.
• Keep a person accountable by name. Every change is signed off by someone who can be asked why.

Does AI-first mean fewer people or a lower rate?

No, and a supplier who says it does is either discounting on someone else's margin or has not measured it. What changes is the ratio of mechanical work to judgement work in an engineer's week. Reading, deciding and reviewing do not compress; they take a larger share of the week than they did, which is the right direction, but the week is the same length.

What does not change

Review discipline, ownership and accountability. A person signs off every change and is answerable for it. If a provider tells you AI lets them skip review, they are describing a risk, not a capability.

Nor does the standard for what may leave your environment. Which tools and which model providers are acceptable is agreed at the start and written down, because for some clients the answer is none. An engineer working under that constraint loses a speed-up, not a standard.

Where you can see it working

The applications in Sazinga Sarva are built this way. Four of the seven are in production with operators, one is in customer trials, one is in build and one is pre-launch. That is the useful evidence: not a claim about methodology, but systems we run ourselves and are still answerable for, maintained by the same engineers you would be hiring.

Teams are built for companies in the United States and the Gulf — the UAE, Saudi Arabia, Qatar, Kuwait, Bahrain and Oman. The engineers are in Pune, which matters mostly for the clock. Dubai is ninety minutes behind us and Riyadh two and a half hours, so a Gulf team shares almost the whole working day. New York is nine and a half hours behind, so American engagements run on a written handover and one fixed overlap window rather than on a standing call — a real constraint, and better stated than discovered.