The operating model for AI-assisted delivery, and where it breaks
Every enterprise is now running some version of the same program. Buy the licenses, stand up a center of excellence, publish the guardrails, measure adoption, report a productivity number to the board. Most of these programs are being designed by people who have read about AI-assisted work rather than done it, and the designs show it. They optimize for the part that is easy to measure, which is how much code or copy gets generated, and they under-specify the part that determines whether the transformation holds, which is where human judgment sits.
I wanted a first-hand answer rather than a researched one. So in January 2026 I ran the experiment on the only organization I could fully control, which was myself, and I ran it end to end rather than as a pilot.
Over seven months I conceived, designed, built, priced, shipped, and now operate six production applications on the Apple App Store. There is no team. There are no contractors. The applications share a common engine that does adaptive item selection, spaced repetition, and Bayesian knowledge tracing, running locally on the user's device, with subscription entitlement and anonymous product telemetry behind it. They serve real paying users who file real support requests when something breaks.
This document is what the experiment taught. It is deliberately unflattering in places, because the parts that did not work are more useful than the parts that did.
A caveat before anything else, stated once and meant plainly. This is an organization of one. Nothing here proves what happens at ten thousand people. What it does establish is a set of failure modes that I now know the shape of from the inside rather than from a vendor deck, and failure modes tend to survive changes in scale even when the arithmetic around them does not.
I trained as an engineer and started my career as one, writing embedded software for a consumer hardware platform. Then I spent nineteen years not doing that. Twenty-plus years of enterprise delivery means twenty-plus years specifying, governing, and accepting software that other people built. I could reason about architecture and read a diff. I had not shipped production code since 2007, and I could not have shipped a production iOS application in 2023.
That gap is the point of the experiment, and it is a more interesting gap than the one usually discussed. The question is not whether a non-technical person can now produce software. It is what happens to someone who has the judgment but has lost the currency: who knows what good looks like, knows where systems fail, and has been nineteen years away from the tools. If AI-assisted development only compresses the work of people already at the keyboard, it is a productivity story and nothing more. If it restores production capability to people whose value was judgment rather than throughput, it changes who can do what inside an organization, and the governance implications are entirely different.
The honest answer is that it does both, unevenly, and the unevenness is where all the interesting problems live.
My engineering background helped in one specific way and not in others. It made me a competent reviewer of generated code, which turned out to be the scarce skill. It did not make me current on the platform, the language, or the ecosystem, and it did not shorten the learning curve on any of them.
Baseline. Before starting I wrote down what a conventional build of the first application would require: a product manager, an iOS engineer, a backend engineer, a designer, and part of a QA resource, running roughly four to six months to a first release. That is the counterfactual I have been measuring against. It is an estimate rather than a measurement, and I have tried not to lean on it too hard.
The naive expectation is that AI collapses the roles. What actually happened is that the roles did not disappear, they redistributed, and the distribution is lopsided in a way nobody warns you about.
The work that compressed dramatically. Scaffolding a new module. Boilerplate of every kind. Refactors across a codebase. Test generation. Translating a data model into persistence code. First drafts of anything with a known structure: a settings screen, a subscription paywall, an onboarding flow, an App Store description, a privacy policy skeleton. In this category the compression is not incremental. Work that would have justified a week of an engineer's time routinely landed in an afternoon, and the quality of the output was high enough that review was faster than authorship.
The work that did not compress at all. Deciding what to build. Deciding what not to build. Architecture choices with long tails. Data model tradeoffs, particularly anything touching how learning state is represented, because that decision propagates into every feature you add for the next year. Pricing. Positioning. Whether a feature should exist. The judgment that a thing is finished.
The work that got harder. This is the finding I did not expect. Review load increases, and it increases faster than generation speed does. When you can produce four times as much candidate work, you do not get four times the throughput. You get four times the review, and review is the constrained resource because it is the part that requires the judgment the tooling does not have. Left unmanaged, this quietly converts a productivity gain into a quality problem, because the reviewer starts skimming.
So the operating model that emerged is not "one person does the work of five." It is closer to: one person does the judgment work of one, and supervises the production work of five. The bottleneck moves from production to supervision, and the entire design problem is how you make supervision sustainable.
This is the single most transferable finding, and it is the one most enterprise programs get wrong.
The instinct is to put the review gate where it has always been: at the end, before release. Code review, QA, sign-off. That instinct is wrong for AI-assisted work, and expensively so. Reviewing generated work after it has been integrated is more expensive than writing it manually, because you are now reverse-engineering intent from an artifact rather than expressing intent directly. I learned this by doing it the wrong way for about six weeks and watching my own throughput fall.
What works is two gates, neither of them at the end.
Gate one sits before generation, at the point of intent. Before anything is produced, the specification has to be tight enough that the output is checkable. Not a long document. Often three or four sentences. But it has to name the constraint that matters, the shape of the expected output, and the thing that would make the result wrong. The discipline is exactly the discipline of writing a good acceptance criterion, and it turns out that twenty years of enterprise delivery is unexpectedly good preparation for it. If you cannot write the check before you generate, you will not be able to apply it afterward.
Gate two sits at the boundary where the work touches something a user depends on. Data persistence, subscription entitlement, anything that can corrupt saved state, anything that can charge someone money. At that boundary the review is line by line and slow and it does not get delegated to the tooling under any circumstances. Everything inside the boundary can be generated, revised, and regenerated freely. The boundary itself is hand-verified every time.
Everything in between those two gates is deliberately ungoverned. That is the trade. You buy speed in the middle by being rigid at the edges. A program that governs the middle as well will get the compliance without the productivity, which is the failure mode I expect most enterprise AI programs to land in.
Confident and wrong is the dominant failure mode. This is not a subtle point but it is chronically understated. Generated output is fluent, well-structured, and plausible whether or not it is correct. There is no signal in the artifact that distinguishes the two. Human work carries tells when the author is uncertain: hedging, inconsistency, an obvious shortcut. Generated work carries none. So the reviewer's calibration, built over a career reading human output, is actively misleading. I caught a Bayesian update that was mathematically wrong but beautifully written and commented, and I caught it three weeks late, because nothing about it looked wrong.
The organizational implication is significant. Anywhere your control environment depends on a reviewer noticing that something looks off, that control is weaker than it was, and nobody has told your risk function.
Small errors compound in one direction. When I accepted a slightly suboptimal architectural suggestion early, subsequent generated work built on it faithfully and enthusiastically. The tooling does not push back on a bad foundation, it accelerates on it. Two of the six products carry a data model decision I would not make again, and the cost of that decision is now larger than the time it originally saved. This is not an AI problem exactly. It is the same compounding that has always existed in software. But the speed of accumulation is materially higher, so the window in which a bad decision stays cheap to reverse is materially shorter.
Context loss between sessions is a real tax. Working across long-running efforts, the model does not carry the accumulated reasoning. I lost time repeatedly re-establishing decisions already made, and I lost quality when I did not bother. The mitigation was mechanical: a written decision log, maintained continuously, treated as a first-class artifact rather than documentation. At enterprise scale this is the same problem as institutional memory, and the same answer applies, which is that the memory has to live in an artifact rather than in people.
The last mile is where it stalls, not the build. By month four the build was not the constraint. Everything downstream was: App Store review, subscription configuration, pricing, support responses, the privacy and disclosure work, the decision about what the products actually claim. None of that compressed meaningfully. If I had reported a productivity number at month two, based on the build, it would have been dramatic and misleading. Measured end to end, from concept to a user paying money and receiving support, the compression is real but roughly half of what the build-only figure would have suggested.
That gap between the build number and the end-to-end number is, I suspect, the single largest source of disappointment in enterprise AI programs. The build number is the one that gets reported to the board.
Six applications, live, from a standing start with no engineering team.
They share one engine. Adaptive item selection, spaced repetition scheduling, and Bayesian knowledge tracing to estimate mastery, all executing on the user's device rather than on a server. That architecture was a deliberate choice with a governance rationale: local processing means the products collect no personally identifiable information at all, which removes an entire category of privacy obligation rather than managing it. Subscription entitlement runs through a third-party service against an anonymous identifier. Product telemetry is anonymous and used for diagnostics.
Two hundred-plus active users. Real support load. Real App Store review cycles, including rejections, which are a useful forcing function because they are an external quality gate you do not control.
One correction to a claim I could have made and did not: I did not learn to build iOS applications from nothing. I relearned a craft I had left, with assistance that made the relearning survivable. Those are different claims and the second one is the true one.
I am deliberately not publishing revenue. It is a small business and the number would invite the wrong conversation. The relevant output is not the revenue, it is that the products exist, run in production, are used by strangers, and have to keep working.
Transfers.
Move the gate to the front. Investment in specification quality pays more than investment in review capacity. If an AI program is measuring output volume and not measuring specification quality, it is measuring the wrong thing.
Define the boundary explicitly. Every organization needs a stated line between what may be generated freely and what is hand-verified without exception. That line should be drawn around irreversibility and user impact, not around technology or team. Left undefined, individual practitioners will draw it themselves, inconsistently, and the risk function will discover this during an audit.
Assume review capacity is the constraint and plan for it. The bottleneck moves from production to supervision. Programs that add generation capability without adding supervision capacity will convert a productivity gain into a quality problem, and the conversion is invisible until something fails.
Measure end to end or do not measure. Build-phase productivity numbers are real and materially overstate the enterprise effect, because the last mile does not compress. Reporting the build number to a board is how a program loses credibility in year two.
The control environment weakened and nobody logged it. Any control that relies on a human noticing that output looks wrong is degraded, because fluency and correctness have decoupled. This deserves an explicit conversation between whoever runs the AI program and whoever owns the control framework. In my experience it is not happening.
Does not transfer.
I had no coordination cost, no stakeholder alignment, no change resistance, no legacy estate, no approval chain, and no one to convince. Those are usually the hard parts, and I did not face any of them. My experience says nothing about how a thousand people adopt a new way of working, how you handle the practitioner who quietly ignores the guardrails, or how you sequence rollout across business units.
But those are transformation problems, and I have spent twenty years on transformation problems at that scale. What I did not have until this experiment was a first-hand read on the technology-specific failure modes underneath them. Now I have both.
Design the decision log from day one. I added it in month three after losing real time. It should have existed before the first line of code, and at enterprise scale it is not a nice-to-have, it is the institutional memory of the transformation.
Slow down on foundational decisions specifically. Everything else could go fast. The data model, the persistence approach, and the sync architecture deserved to be the slowest decisions I made, and two of them were not. The general rule I would give a program: identify the decisions whose cost of reversal grows over time, and deliberately exempt those from the speed the tooling offers you.
Build the measurement before the capability. I started measuring properly in month four, which means my most interesting period is reconstructed rather than recorded. An enterprise program has no excuse for this. Baseline first, then capability.
Take the last mile seriously from the start. I treated App Store review, pricing, support, and disclosure as afterthoughts because the build was the interesting part. They became the constraint. In an enterprise the equivalent is everything between "the model works" and "the business has changed how it operates," and it is where transformations go to die.
The reason I ran this is that I intend to lead enterprise AI transformation, and I did not want to do it having only read about the thing I would be asking an organization to adopt.
Six products at n equals one does not make me an expert in enterprise AI adoption. It makes me someone who has been through the full arc once, at the smallest possible scale, and who now knows from the inside where the work compresses, where it does not, where the gate belongs, what the dominant failure mode looks like, and why the productivity number that gets reported to the board is usually wrong.
That, combined with twenty years of running large regulated programs where the hard part was never the technology, is the position I am bringing to this work.
Bharath Subramanya is a transformation executive with 20+ years of enterprise delivery, nine of them in financial services. He holds an MBA from Duke University's Fuqua School of Business, an M.S. in Information Systems and Operations Management from the University of Florida, and the PMP. He holds the AWS Machine Learning Specialty (2020-2023). He founded Invictera LLC in January 2026. He is based in Princeton, New Jersey.
Contact: hello@invictera.com · linkedin.com/in/bharathsubramanya
← Back to Invictera