Sorry, it’s been a while. I became a mom to two more teen girls in the last month (yes, at the same time, no, I do not recommend it as a productivity hack), and somewhere in between hospital visits and getting my other daughter ready for college move in, I also pushed AdaptoInbox and AdaptoExpenses into beta. Turns out both of those things taught me the same lesson about ownership.
My minion army just crossed fifty agents, and not one of them has an org chart, a manager, or a plan for what happens to its work if I get hit by a bus (I have genuinely forgotten what a couple of them do). That question felt harmless right up until two real companies found out what happens when nobody answers it for a piece of software instead of a person. (Also don’t tell Pete, my boss at Crimson IT that he is right, he’s been saying this for months)
In May 2025, a security researcher disclosed CVE-2025-48757, a vulnerability in the AI app building platform Lovable that came from missing row level security on Supabase tables (the kind of setting that takes about thirty seconds to configure once you know it’s there). Over 170 production applications were exposed. Full databases, user data, authentication tokens, and business records, all readable by anyone with the public key. Two months earlier, a women’s dating safety app called Tea App exposed 72,000 images, including 13,000 government ID photos, because its Firebase storage was left wide open at default settings.
Nobody hacked either company. Nobody had to. The AI generated the functionality correctly in both cases. It just never generated the authorization policy, and nobody governing the project caught that it hadn’t.
I want to use those two incidents as the entry point into something I have been chewing on for a while: prompt engineering is quietly losing its grip as the interesting AI skill, and what is replacing it is governance. Not a better prompt. Ownership, schemas, and a process for what happens when the thing you built six weeks ago in an afternoon needs to survive a security review, an audit, or you leaving the company.
I was on a call with a group of CIOs and vCIOs recently (the kind of meeting where everybody admits what actually happened instead of what they wish had happened), and two stories from that call, alongside those two public incidents, make the case better than a slide deck could.
Why the Prompt Stopped Being the Interesting Part
Here is the thing that changed my mind about prompt engineering as a discipline. A colleague building a small RPG side project needed every NPC in the game to generate dialogue, generate dialogue options, and update a handful of numerical relationship scores, every single turn, using a locally hosted open weight model. Early on he tried to get consistent behavior out of the model with careful prompt wording. It did not hold up. Instructions that worked in one turn drifted in the next (which, if you have ever tried to keep a model “in character” across a long session, will sound familiar).
What actually fixed it was not a better prompt. It was a grammar constrained schema, using GBNF, that made the model structurally incapable of returning anything except valid JSON matching the exact fields his game engine expected. Across all of his testing, he had zero JSON parse failures. The downstream code could consume the model’s output like a database row: typed, validated, predictable.
That is the shift in one sentence. If AI is going to drive an actual business process, it cannot hand you a paragraph and hope you parse it correctly. It has to hand you a schema. The interesting engineering problem is no longer “how do I phrase this so the model understands me.” It is “how do I constrain the output so the rest of my system can trust it without a human checking every response.”
Prompting still matters. But it has quietly become plumbing, not strategy (the electrical work, not the architecture). The strategy work is schema design, output validation, and deciding which parts of a workflow can run unattended and which ones need a human gate.
The Twelve Month Clock Nobody Asked For
Here is a small, boring example of the same governance problem, courtesy of the protocol most of our agents now run on. MCP just finalized its biggest spec revision since launch, and it introduced a formal Feature Lifecycle Policy: Active, Deprecated, Removed, with a minimum twelve month window at each stage. Roots, Sampling, Logging, and Dynamic Client Registration are all deprecated as of this release.
Twelve months sounds generous until you count how many MCP connectors your org has quietly stood up in the last year. If your team built one, or ten, or fifty (and at this point, who is actually counting), the clock started the day the spec shipped, whether anyone assigned an owner to track it or not. That is the governance problem in miniature. We are creating technical debt in real time, faster than most orgs have a process to track it, because the tools got good enough that building something no longer requires asking permission first.
What Ungoverned AI Development Actually Costs
I do not love leading with fear, so let me be direct about why this matters in dollars, not just principle. Escape.tech scanned over 1,400 production applications built through AI assisted coding and found 65 percent had security issues, with 58 percent containing at least one critical vulnerability. Duplication in AI generated codebases increased 48 percent and refactoring activity dropped 60 percent following widespread adoption, and the maintenance cost on that code balloons by roughly 300 percent within the first eighteen months.
None of that means AI coding tools are bad. It means ungoverned AI coding is expensive in a way that does not show up on the invoice for the tool itself. It shows up eighteen months later when nobody remembers why a function exists, the person who wrote it left the company, and the audit trail is a chat log.
Apiiro ran its code analysis engine across tens of thousands of Fortune 50 repositories and found that AI assisted developers commit code at three to four times the rate of their peers, but introduce security findings at ten times the rate. That is not a reason to slow down on AI coding. It is a reason to stop treating “the model wrote it” as equivalent to “someone reviewed it,” which is exactly the gap that took down Lovable and Tea App.
Stanford researchers found a related pattern that matters even for teams who never touch a security misconfiguration: AI coding productivity gains hold up fine in a small codebase, roughly a 60 percent lift around 10,000 lines of code, but largely collapse by the time a codebase reaches 100,000 lines, because the model has no architectural context for a system that size. The tool that felt like a superpower on a greenfield project starts working against you once the project has history, precisely the point at which governance would have mattered most.
Why This Is Personal for Me Right Now
I am not writing this from a comfortable distance. I am in the middle of beta testing two of my own products, AdaptoInbox and AdaptoExpenses, and reading about Lovable and Tea App did not feel like industry news. It felt like a preview of a mistake I could make. AdaptoInbox reads a person’s email. AdaptoExpenses touches financial and expense data. Those are not side project stakes. If either one shipped with a gap the size of a missing row level security policy, I would not be writing a post about someone else’s incident. I would be writing the incident.
So before either beta went out, I built the same governance instincts described in this post into the product itself instead of treating them as a policy to remember later (policies you remember later are how you end up in a CVE writeup). Every workflow AdaptoInbox and AdaptoExpenses run has a defined owner in the codebase, not just in my head. Outputs are schema constrained the same way Jonathan’s game NPCs are, so a malformed response gets rejected before it ever touches a user’s inbox or expense record, not caught after the fact. Beta access is limited and named, the same settings based approach one of the CIOs on that call used for her coding tools, so I know exactly who is touching production data at any point. None of that erases the fear. It just means the fear has somewhere to go besides staying a fear.
What Actually Works
At that same meeting, one of the CIOs walked through how she has been handling this at her org, and it is the clearest governance model I have seen in the wild.
When her team started experimenting with agentic coding tools last December, she air gapped every vibe coder onto a separate machine with a separate user ID before letting anyone touch production. As adoption grew and Anthropic’s licensing changed to include Claude Code access for every standard tier seat, she did not leave that decision to default settings. She used a hook in the plan’s admin console, a settings.json file that names specifically who is authorized to use the coding tool, so that everyone else on the team gets an error message instead of quiet access. Everybody still gets the collaborative AI tooling. Only a defined list gets the ability to ship code.
She paired that access control with a development standard: every project needs a README, needs an AI bill of materials documenting what model built what, and gets scaffolded through a shared enterprise repo rather than starting as a loose folder on someone’s laptop. The goal was not to slow people down. It was to make sure that when someone gets excited and builds something useful in an afternoon (which happens constantly now), there is a paper trail for who owns it and what it depends on.
Another builder in that same group solved a related but different problem. He kept losing track of requirements because every AI coding session generated its own markdown files, buried in whichever work tree happened to be active that day. He moved the entire requirement and roadmap structure into a database instead, registered through its own MCP connector, so that every session, regardless of which tool or which work tree, reads and writes against one source of truth instead of a scattered pile of files that only make sense in hindsight.
Both of these are the same governance instinct wearing different clothes. Decide who can build. Decide where the record of what was built lives. Decide it before the tool ships something into production, not after an auditor asks who owns it.
If you are trying to build this out for your own org, three questions cut through most of the noise: who is authorized to generate and ship code, and is that enforced by a system setting or just a policy nobody reads; where does the definition of what was built live, a database with an owner or a folder of markdown files that only make sense to whoever wrote them; and what happens to an application when its builder leaves. If the honest answer to that last one is “nobody knows,” the application is already technical debt, whether it has caused an incident yet or not.
The Honest Caveat
None of this is solved yet, anywhere, including in my own beta tests. The builder running requirements through a database admitted the interface is still weak and that he built the whole thing as a crutch to get through his own work, not a polished product. That is the right amount of honesty for where this space actually is. We are early, and the governance patterns that will look obvious in two years are still being figured out live, by people admitting what broke before they figured out what worked.
Where This Goes Next
Lovable and Tea App are not cautionary tales about careless companies. They are what happens by default when speed outruns governance, which is the default setting for every org building with AI right now, including mine. Prompt engineering got us in the door. AI development governance, meaning ownership, schemas, and a record of what exists, is what determines whether what we build in an afternoon is still trustworthy a year later.
The same governance instincts are baked into AdaptoMeetings and AdaptoExpenses. If you are further along than “nobody knows who owns this,” I would genuinely like to hear how you are tracking it. And if you are earlier than that, start with the three questions above. They cost nothing and they will save you the eighteen month bill.