Chapter 10 · Part II — Sector applications
The cost case
What machine-authored software actually costs, where the money goes, and a model you can run on your own numbers rather than ours.
There is no measured cost figure for building software in Kasuri. No compiler exists, so no delivery has ever been priced. Any table claiming "$X in Kasuri versus $Y in TypeScript" would be invented, and we will not publish one.
What follows instead is a cost model: the lines that make up the real cost of delivery, the published evidence on each, the structural property of each stack that drives it, and what Kasuri's design targets — marked as a target every time. The arithmetic is exposed so you can run it on your own numbers. A model you can check is worth more than a number you would have to take on trust, and this readership knows the difference.
Section 01Where the money actually goes
Software cost conversations usually reduce to developer salaries divided by features shipped. That was defensible when writing was the bottleneck. It is not the shape of the cost any more, and the mis-framing is expensive because it sends investment at the line that is already shrinking.
Six lines carry the real cost in an organisation delivering machine-authored software:
- Authoring — producing the code. The line everyone measures, and the only one AI has unambiguously reduced.
- Review and rework — getting produced code to acceptable. Rising with volume.
- Assurance — scanning, testing, penetration testing, audit, accreditation, questionnaires. Largely fixed per release, and serial with delivery.
- Dependency maintenance — upgrades, advisories, breaking changes, deprecations. A function of surface area, not of features.
- Incident and remediation — the low-probability, high-cost line, which is where the asymmetry lives for the sectors in this part.
- Inference — tokens. New, growing, and now a genuine per-build variable cost.
AI reduces line 1. Lines 2 to 6 are where it sends the money — and four of the six scale with how much code exists, not with how much value it delivers.
Section 02What the evidence says about each line
Every figure in this table is external and sourced. None of them is ours, and none of them is about Kasuri.
| Line | What the measurements show | Cost direction |
|---|---|---|
| Authoring | In a randomised controlled trial with 16 experienced maintainers across 246 tasks in their own repositories, allowing AI tooling made developers 19% slower — while they believed it had made them 20% faster, a 39-point perception gap. A 2026 follow-up shows the effect shrinking for newly recruited developers with newer tools, and the perception gap persisting.[21] | Down on greenfield; unproven on mature codebases, and organisations systematically over-estimate the gain |
| Review and rework | Machine output outruns review capacity. The automated substitute has a measured ceiling: catching 80% of sabotage attempts required a 20–40% false-positive rate.[10] | Up, proportional to output |
| Assurance | Largely fixed per release and serial with delivery. Faster authoring raises release frequency, so annualised assurance cost rises with it — or the cadence of assurance quietly falls behind the cadence of change. | Up with release frequency |
| Dependency maintenance | The mean production application in an eleven-application corpus we measured carries roughly 135 direct runtime dependencies; the transitive closure is an order of magnitude larger.[14] | Flat per dependency, up with surface area |
| Incident and remediation | Roughly half of functionally correct AI-written backends were exploitable in a benchmark with executable exploits;[1] generated code carried 2.74× the vulnerabilities of human-written code, with no improvement on re-run.[2] | Up, proportional to code volume |
| Inference | A new per-build variable cost. Verbosity, retry loops and failed attempts are billed. Cost per solved task — not per token — is the figure that matters, and few organisations measure it. | Up; largely unmeasured |
Section 03The structural drivers, by stack
Each of the six lines above is driven by a property of the platform rather than by how carefully a team works: whether authority is ambient, how large the dependency surface is, whether the build executes code a package supplied, whether the tier boundary is hand-maintained, and whether a component's reach can be enumerated at all.
That comparison is Chapter 11, which sets Kasuri against TypeScript, Python, Java/C#, Go and Rust across sixteen properties — including the three rows where Kasuri loses outright. It is a separate chapter because it answers a separate question, and because the rows where the incumbents win deserve more room than a cost chapter would give them.
The one row worth carrying into the model below is model familiarity. It is the principal cost of adopting anything clean-slate: a model writing an unfamiliar language performs materially worse than the same model writing a familiar one, and that tax is paid on every build until a corpus exists. Any cost case that omitted it would be dishonest, which is why it appears as an adverse line in the table that follows.
Section 04The model, with the arithmetic exposed
Rather than assert a saving, here is the model. Substitute your own figures; every input is one your finance function already holds.
| Line | Your input | What drives it today | What Kasuri targets | Status of that target |
|---|---|---|---|---|
| Authoring | Engineers × fully-loaded cost × share of time writing | Model capability and familiarity | No claim. Unfamiliarity makes this worse until a corpus exists | Adverse, and gated |
| Review and rework | Reviewer hours × loaded rate | Volume of output; defects reaching review | Whole defect classes never reach a reviewer; compiler-guided repair measured at 22→54 of 56 tasks in an unfamiliar language[12] | Mechanism designed; unmeasured on Kasuri |
| Assurance | Pen test + audit + questionnaire effort per year | Release frequency; inspection-based controls | Properties established at build time, so evidence is generated per change rather than per engagement | Mechanism designed; unmeasured |
| Dependency maintenance | Direct dependencies × upgrade/advisory hours | Surface area | The category of dependency that exists to make tiers agree has nothing to do | Structural; magnitude unmeasured |
| Incident and remediation | Expected incidents × cost, incl. notification | Exploitable-defect rate in shipped code | Classes made unrepresentable rather than detectable; target rate approaching zero by construction | The central claim. Unproven. |
| Inference | Spend ÷ tasks actually solved | Retries, failed attempts, verbosity | Fewer failed attempts per solved task; cost-per-solved-task is a pre-registered benchmark measure | Pre-registered; not yet run |
Two honest observations about running this model. First, the line Kasuri makes worse is the one most organisations measure, and the lines it targets are the ones most organisations do not track separately — which is a real adoption problem and not a rhetorical one. Second, line 5 dominates the arithmetic in every sector in Part II: a single notifiable incident typically exceeds a year of the other five combined, which is why variance reduction rather than mean improvement is the argument being made.
Section 05Three questions that price this for you
- What is one cross-boundary data incident worth to you? Notification, investigation, regulatory response, remediation, and the contracts that do not renew. That single figure, multiplied by a probability you already estimate, is most of the case.
- What do you spend annually on assurance activity that produces a statement rather than a property? Questionnaires, evidence packs, audit preparation, re-accreditation. Ask how much of it would still be needed if the property were established by the build.
- What is your cost per solved task, not per token? Very few organisations measure this, and it is the line that grows fastest.
Section 06What would settle this
The programme does not intend to argue the cost case. It intends to measure it. Cost per solved task is one of three pre-registered secondary measures in the benchmark, and the kill criterion attached to it is explicit: if the best Kasuri arm wins on the primary measure but loses two of the three secondaries — cost per solved task among them — the programme documents that and stops.
The benchmark capable of settling it costs on the order of $25,000–27,000 for the minimal kill-capable version. That is the one dollar figure in this chapter that is ours, it is an estimate from the programme's own design records, and spending it has not yet been authorised.
It is not a business case, a quotation, or a total-cost-of-ownership study. It contains no claimed saving, no payback period, and no customer reference, because none of those exists.
It is a model, with its inputs named and its uncertain terms marked. If you want a number from us, the honest answer is that the number arrives with the benchmark — and the criteria that would make that number bad enough to end the programme were fixed before the measurement was designed (Chapter 17).