What AI can do when experience sets the standard

Over twenty-two days in July — nights, weekends, and one week of vacation — I built and shipped roughly 88,000 lines of first-party software: 102 database migrations, 45 pages, 25 API routes, nearly 200 components, a tested deterministic computation core, and end-to-end subscription billing with server-enforced entitlements. One founder. 297 commits. Part-time.

This is not an article about how AI can write 88,000 lines of code.

Anyone can generate 88,000 lines of code. That’s the problem. AI-productivity claims are the cheapest currency in the industry right now — every company is “AI-native,” every team is “10x,” and almost none of it survives contact with a skeptical reviewer. Line counts prove nothing. Velocity proves nothing. The only question that matters is the one a buyer, an investor, or your own future self will eventually ask:

Is the work coherent, secure, documented, testable, and consistent with a governing philosophy — or is it just a very large pile of plausible text?

So I did something most AI-productivity stories don’t do. I had the work audited. Twice. I subjected the repository to two separate adversarial AI diligence reviews, each instructed to challenge the claims rather than validate them.

What the numbers prove, and what they don’t

The numbers prove speed and scale. They do not prove quality. Quality has to be established the way it always has been: by evidence.

Here is what the audits found when they went looking.

The core of the product — a deterministic emotional-computation engine, the one thing the entire platform depends on — is fully unit-tested, and every test passes. Billing is not a demo: Stripe checkout flows through a signature-verified webhook into a reconciled subscriptions table, and every entitlement is enforced in SQL on the server, not hidden in a client-side if statement. Row-level security is enabled on every one of the ~74 tables in the database — the auditors ran a census expecting gaps and didn’t find one. Alongside the code sit about forty verification suites: browser automation with real assertions, SQL test brackets that prove access rules by attempting to violate them.

And here is the part I’m proudest of, which is also the part that sounds strangest: the audits found real problems, and the documentation had already admitted most of them.

The project keeps drift logs — running records of where implemented reality diverged from the approved design. They don’t just describe successes. One entry reads, in effect, “we predicted no amendments would be needed; that prediction was wrong.” Another discloses a data limitation that is permanently unrecoverable, and says so plainly instead of burying it. The reviewers also found genuinely unfinished work: legal pages still awaiting real copy, a continuous-integration pipeline that wasn’t yet guarding the working branch, an onboarding flow that existed in concept art but not in code. None of that was hidden, because the process was built to surface its own weaknesses.

That’s what a receipt is. Not a highlight reel — an accounting.

The thesis: AI doesn’t replace experience. It compounds disciplined judgment.

Why did this work? Not because the models are magic, and not because I found a secret prompt.

It worked because the AI was never operating freely. It was operating inside a system — one that took me twenty-five years to be able to design, and about a week to write down.

Every piece of work in this codebase moves through four gated stages: design, plan, execute, close. AI does enormous amounts of the labor at every stage. But the system enforces things no model would enforce on itself:

• Design authority. A small set of governing documents defines what the product is — its principles, its domain model, its non-negotiables. AI can implement within that authority. It cannot silently redefine it. The founding philosophy document cannot be edited by any automated process, period. When an implementation collides with the authority, the standing instruction is: stop. Never launder the conflict into the code.
• Decision ownership. Models propose; a human ratifies. Every consequential decision is written down, dated, and attributed. Proposed amendments to the governing documents queue up for explicit human approval — and the audit could see exactly which ones were still pending, because pending is a recorded state, not a vague one.
• An evidence bar. In this system, “I implemented it” is not evidence of anything. Done means a test suite ran, a browser proved the behavior, a SQL bracket demonstrated the access rule — or the gap is explicitly recorded as unverified. Commit messages document what was proven, not what was attempted.
• Bounded roles. Different agents design, implement, inspect, and challenge. No single agent is the final authority on its own work. The audits themselves were adversarial agents instructed to refute claims, not confirm them.
• Drift documentation. Divergence between intent and reality is recorded, not smoothed over.
• Deterministic cores. The product’s central truths are computed predictably and tested exhaustively. AI supplies language and interpretation around the deterministic core — it is never allowed to become the source of truth.
• Escalation boundaries. Legal, privacy, security, rights, and business judgments are human judgments. The system knows where its authority ends.

Most conversations about “AI guardrails” are about content filters. This is a more useful definition: guardrails are the structures that let AI move at machine speed without quietly becoming the authority.

Why experience matters more now, not less

I’ve spent twenty-five years earning the judgment this system encodes — from a help desk, to building enterprise systems, to running the mobile platform for a bank whose alerting infrastructure pushed twenty million messages a month, to enterprise architecture, to leading one of the larger core-banking modernization programs in the country: a mainframe-to-cloud transformation touching more than a hundred integrated systems, in one of the most regulated industries there is.

None of that became obsolete when AI arrived. It became leveraged.

Because here is the uncomfortable truth about AI-assisted work: AI cannot consistently elevate work beyond the quality its operator can recognize, demand, and defend. A novice with a frontier model can produce something impressive-looking in an afternoon. What they cannot do is recognize the weak data model, the unsafe security boundary, the brittle abstraction, the licensing exposure, the privacy violation, the metric that measures the wrong thing, or the perfectly plausible implementation that quietly contradicts the product’s intent. The model will hand them all of these, fluently, with confidence.

The operator’s job — the job that experience trains — is to constantly distinguish output from progress, complexity from capability, plausibility from correctness, documentation from evidence, speed from velocity, and automation from the delegation of accountability. Those distinctions were the hard part of engineering leadership before AI. They are the entire part now.

AI amplifies the values already present

Which leads to the idea I most want to leave with you:

AI does not bring values into an organization. It amplifies the values already there.

An organization that prizes speed over truth will use AI to produce mistakes faster than any team in its history. An organization that tolerates weak architecture will generate technical debt at a scale no human team could achieve. A leader who cannot recognize quality cannot prompt for it, review for it, or govern it. A culture that hides failures will discover that AI is extraordinarily good at manufacturing plausible explanations.

But invert every one of those values — evidence over assertion, auditability over vibes, restraint over scope creep, documented authority over tribal knowledge, explicit decisions over drift — and the same technology becomes the most powerful force multiplier an experienced builder has ever held.

Same models. Same tools. Opposite outcomes. The variable is not the AI. The variable is you.

Honesty is a speed strategy

There is one more source for this system, and it is the least comfortable to name.

I spent years in engineering leadership inside a large enterprise — running mobile development, then transformation engineering. In both roles I learned how easily transparency about delivery problems can be read as a lack of execution. Name the assumption that isn’t holding, make an unresolved risk visible, challenge a plan that already has executive momentum, and you can look adversarial to people who measure progress through confidence and activity. I understand that tension better now than I did then: large organizations need momentum, and there is a real difference between constructive evidence and habitual resistance. But there is a more dangerous difference between executing and preserving the appearance of execution.

The speed I achieve today is directly connected to my willingness to say what is not working. A failed assumption doesn’t get to survive because it was mine. Nothing is “complete” because a lot of effort went into it. Drift doesn’t get hidden to protect the elegance of the original design. When something fails, the fastest response is to name the failure accurately; when a design collides with reality, the fastest response is to record the collision; when the evidence contradicts the plan, the fastest response is to change the plan. That feels slower in the moment, because the status reports get less reassuring. In practice it prevents months of work from accumulating behind an assumption nobody was willing to challenge. Transparency is not separate from execution. It is what keeps execution attached to reality.

AI raises the stakes on this, sharply. A model can generate enough implementation, documentation, and persuasive language to sustain a bad assumption almost indefinitely — it can make a wrong direction look productive every single day. That is why the drift logs exist, and why this delivery system rewards contradiction instead of suppressing it: agents are expected to report that the plan was wrong, the evidence is insufficient, or a governing principle has been violated. The system cannot treat bad news as disloyalty.

My career taught me that truth can be organizationally uncomfortable. Building SOAURA taught me it is also an accelerant. The work moves quickly because problems are not required to become politically acceptable before they can become technically visible.

One founder, three deliberate roles

There are not three teams behind this work. VRAISON, Half Open Heart, and SOAURA are all founder-operated — one person working from three deliberately separated positions: the builder, the rights holder, and the platform owner. The separation is functional before it is organizational: the boundaries exist now because the obligations are already different.

VRAISON is the builder. The AI-native engineering practice: architecture, orchestration, governance, delivery. Its product is not code — it is systems in which human intent survives high-speed AI execution.

Half Open Heart is the rights holder. An independent label and publishing house with real artists, recordings, and rights-clear material. It occupies the creator’s seat, forcing licensing, attribution, artistic identity, and ownership into the design from the beginning — in SOAURA, the rights model went into the database schema before the first user ever will.

SOAURA is the platform. The product where the disciplines meet: playback, emotional testimony, privacy, social interaction, subscriptions, licensing, and AI-generated language — difficult enough, across enough hard domains at once, to expose whether the method actually works.

Holding all three seats at once is obvious concentration risk. It also made something unusual possible during the formative period: the technology was never designed without the rights, the rights model was never written without understanding the product, and the product was never promised anything the architecture couldn’t honestly support. As each operation grows, these roles will increasingly belong to different people. The boundaries won’t need to be invented then — they are already load-bearing now.

SOAURA is not the whole story. It is the receipt showing what the VRAISON approach can produce — with Half Open Heart ensuring that the creative work beneath the technology stays owned, attributed, and human.

The closing argument

If you run an enterprise, the lesson from those twenty-two days is not “hire fewer engineers” or “buy more AI tools.” Every one of your competitors has access to the same models you do, this quarter, at the same price.

The competitive advantage will not belong to the company with the most AI tools. It will belong to the company with the strongest judgment, the clearest authority, and the most disciplined system for turning machine speed into outcomes it can actually trust — and prove.

That system is buildable. I know, because I built one, part-time, and then tried to tear it apart.

The codebase is the receipt.

---

Peter Corcoran is the founder of VRAISON, an AI-native engineering practice; Half Open Heart Publishing, an independent label and publishing house; and SOAURA, an emotional music platform. Before founding VRAISON, he spent twenty-five years in engineering and transformation leadership, most recently leading core-banking modernization architecture at a major U.S. regional bank.