Your agent writes a database migration. It looks clean. It passes review. It ships.
Then production breaks.
The migration dropped a column. Three other services were still reading that column, and the agent never knew they existed.
That isn't a reasoning failure. It's a visibility failure.
Every team building with agents sits somewhere on that gap. Where you sit comes down to one question. How much do you trust your agent, and what have you done to earn that trust?
TL;DR
Building with agents has three layers, and trust is what separates them.
Layer one trusts blindly. It ships what breaks. These are the vibe coders.
Layer two watched layer one fail and stopped trusting. A human owns everything that reaches production. These are engineers not leveraging agents enough.
Layer three trusts agents completely, but only because it built the conditions that make the trust deserved. These are engineers leveraging agents fully.
The intelligence is already there. What's missing is context, and context is what turns trust from a gamble into something you engineer.
The three layers
Layer one: the vibe coders
Vibe coders with good tools.
They point an agent at a problem, get something that runs, and ship it. The frontend looks finished. The demo works. Then it meets real users and real data, and the parts nobody looked at are the parts that fail: the schema, the auth flow, the permissions, the migration that never ran.
They trust the agent completely, and that trust is free, because nothing in the process ever tests it. That isn't confidence. That's just not checking.
This is the layer that gave vibe coding its reputation. They're not wrong that agents build fast. They're wrong about what "done" means.
"Vibe coding" isn't a critic's insult. The term comes from Andrej Karpathy, a founding member of OpenAI who went on to run AI at Tesla and lead the vision team behind Autopilot, and he coined it approvingly, describing his own workflow. That's what makes his description worth reading closely, on 2 February 2025:
"There's a new kind of coding I call 'vibe coding', where you [...] forget that the code even exists. [...] I 'Accept All' always, I don't read the diffs anymore."
Andrej Karpathy, 2 February 2025
That's the posture stated plainly. Accept everything, inspect nothing.
The unnerving part is that this trust survives contact with evidence. METR ran a randomized controlled trial giving 16 experienced open-source developers 246 real tasks in repositories they already knew well. Those developers expected AI to make them 24% faster. It made them 19% slower. Afterwards, having just been measurably slower, they still believed they'd been 20% faster.
Source: METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (July 2025)
The limits of that study are real and worth stating: 16 developers, early-2025 tooling, mature codebases they already knew. METR now labels the result historical, and a February 2026 continuation found some evidence of speedup: a newer cohort of 57 developers across 800+ tasks came in at 4% slower, with a confidence interval spanning zero. Take the productivity number with the caveats attached.
The perception gap is the part that survives. Feeling faster and being faster are two different measurements, and layer one only ever takes the first one.
Layer two: engineers not leveraging agents enough
Engineers who actually adopted AI, then hit its edges.
They watched layer one fail and drew a hard conclusion: vibe coding is worthless and it doesn't scale. Agents are fine for generating code, but someone who understands the system has to own what reaches production.
So the agent writes. The engineer reviews, approves, and owns.
It works. Most serious teams shipping AI-assisted software are right here, and they're shipping.
The survey data says this is where the industry actually sits. In Stack Overflow's 2025 developer survey, 84% of developers said they use or plan to use AI tools, up from 76% the year before. Over that same year, the share who don't trust the accuracy of AI output went from 31% to 46%. Only 3% said they highly trust it.
Source: Stack Overflow Developer Survey 2025, AI section, with 2024 figures from the 2024 survey
Adoption and distrust went up together. That's layer two in one picture: use it everywhere, believe it nowhere.
But look at what it does with trust. It withholds it permanently. It treats the ceiling on agent output as fixed, a property of agents themselves, sitting below what production needs, forever. In this model the human isn't scaffolding. The human is the design.
The result is underuse, and underuse is the hardest failure to notice because it doesn't look like one. Nothing breaks. Nothing pages anyone. The agent just keeps getting handed the small half of the job, generating code while a human keeps the schema, the migrations, the auth config and the production state in their own head. Layer two spends its judgment deciding whether the agent's output is acceptable, which is exactly the work it could be spending on making the agent's input sufficient.
Layer one pays for its mistake in incidents. Layer two pays for its mistake in ceiling, and the invoice never arrives.
The most experienced developers hold that line hardest. Among developers with ten or more years of experience, only 2.5% highly trust AI output, and 20.7% highly distrust it, the highest distrust of any experience bracket. Their top frustration, cited by 66%, is AI solutions that are "almost right, but not quite."
That last number is the tell, and it points somewhere layer two doesn't look. "Almost right" is not what stupidity produces. It's what you get from something competent working off incomplete information.
Layer three: engineers leveraging agents fully
Engineers who trust agents completely. Whatever an agent can be made to own, it should own.
They hit the same failures everyone else does. What's different is the diagnosis.
When an agent ships something broken, layer two decides the agent wasn't good enough and adds another human. Layer three asks what the agent didn't know.
When something blocks them, they don't take the work back. They prompt more precisely, run more agents, and give the agent better context.
The agent's intelligence was never the bottleneck. Its context was.
Trust is the axis
"Trust" sounds soft. It isn't.
Layer one's trust is unearned. Nothing tests it, so it fails the first time production does.
Layer two's distrust is earned, and that's exactly the problem. It generalizes from real failures into a permanent rule, and a permanent rule caps you at human review throughput forever.
Layer three's trust is built. It isn't a belief about how good the models are. It's a claim about what you put around them: what the agent can see, what it remembers, and what checks it before its work lands.
That's the difference between trusting an agent and making an agent trustworthy. The first is a personality trait. The second is engineering.
Google's 2025 DORA report arrives at the same place from a different direction. Its headline finding on AI-assisted development is that "AI's primary role is as an amplifier, magnifying an organization's existing strengths and weaknesses."
An amplifier doesn't have a quality of its own. It has yours. Point it at a system where nothing is legible and nothing is remembered, and it scales exactly that. Which is why layer three spends its effort on the system rather than on the prompt.
Your agent isn't dumb, it's blind
Coding agents don't fail because they can't reason. They fail because they're reasoning about a system they can't see.
An agent that doesn't know what tables exist will invent them. One that can't read your auth config will guess at it. One with no view of which migrations already ran will write a conflicting one.
None of that is a reasoning failure. That's competent work on missing information.
Give it the schema, the auth config, the bucket contents, the deployed functions, and the runtime logs, and the same model behaves differently.
That's why the fix for bad agent output is so rarely a better prompt, and so often a better view of the system.
The industry has already renamed this problem. Karpathy, who gave us "vibe coding" in February 2025, spent the following June arguing for a different term:
"+1 for 'context engineering' over 'prompt engineering'. People associate prompts with short task descriptions you'd give an LLM in your day-to-day use. When in every industrial-strength LLM app, context engineering is the delicate art and science of filling the context window with just the right information for the next step."
Same person, sixteen months apart, describing the move from layer one to layer three. Stop accepting all diffs. Start engineering what the model can see.
Every mistake has a decision behind it
Here's the part most teams skip.
Every mistake, whether a human makes it or an agent makes it, has a decision behind it.
A bug isn't a random event. It's the visible end of a choice someone made: a schema shaped a particular way, a permission left open, an assumption about what a field contained. The bug is the symptom. The decision is the cause.
So when an agent produces a bug, don't patch the output and move on. Do three things: trace it back, find the owner, re-enhance.
Trace it back. Follow the bug to the point where the agent committed to something. Not where the error surfaced. Where the choice got made.
Find the owner. Every decision has one. Sometimes it's the agent, acting on a belief about the system that was wrong. Sometimes it's a human, in a schema or a config or a convention written months ago that the agent read and faithfully obeyed. The owner isn't who to blame. It's where the correction has to land. Fix the symptom while the owning decision stands, and the bug comes back wearing different clothes.
Re-enhance. Write the correction back as context the agent carries forward, so the belief that produced the bug can't produce it again.
Four questions drive it:
- What did the agent decide, and when?
- What did it believe about the system at that moment?
- Where did that belief come from, or what was missing that let it form?
- What has to change so it's correct next time?
Do this consistently and bugs stop being pure cost. You exploit each one to the maximum, because each one permanently removes a category of failure and makes the agent more trustworthy than it was that morning.
That's the inversion. Layer two treats a bug as work to absorb. Layer three treats it as the highest-signal input it gets.
One shot was never the bar
Most people evaluate agents on a hidden assumption: that a trustworthy agent gets it right the first time.
Layer three doesn't accept that.
Agents won't do the right thing on the first shot. That was never the bar.
What matters is whether the system converges. One agent, prompted once, judged on its first output, is the weakest setup possible, and it's the one nearly every skeptical evaluation uses.
Multi-agent orchestration changes the shape of the problem. Agents that plan, implement, review, and verify as separate roles catch each other's errors. Agents that accumulate memory stop repeating mistakes already traced. Agents given the right context at the right step guess less at every step.
What comes out isn't one model's first draft. It's the product of many passes, each carrying what the last one learned.
That's what makes an agent trustworthy. Not being right immediately. Being corrected in a way that sticks.
What this means for your backend
If context is what earns trust, the infrastructure your agent builds against isn't a neutral detail. It decides whether the agent can see.
A backend built for humans ships dashboards and docs, and assumes a person will read them and hold the state in their head. An agent can't do that. It gets whatever the platform makes legible and guesses about the rest.
That's what InsForge is for. Agents connect through an MCP server or through the CLI and Skills, and both exist so an agent can operate the backend the way a backend engineer would: pull documentation, schemas, and metadata for deployed functions, bucket contents, and auth config; read runtime logs to check what it built and debug what broke; run migrations, deploy edge functions, create buckets, configure auth providers.
The point isn't more tools to call. It's that the agent can look before it decides, and when it still gets something wrong, there's a trail back to the decision that caused it.
Where this goes
Layer one isn't going to turn out fine. Shipping unreviewed agent output doesn't start working at some future model size.
Layer two is a depth, not a destination. It treats human review as architecture instead of scaffolding, and that assumption weakens every time context, memory, and orchestration improve.
Layer three is a bet that the ceiling everyone attributes to agents is really a ceiling on what we've given them to work with, and that trustworthiness is something you build, not something you wait for.
Stop asking whether your agent is smart enough. Start asking what it didn't know, and why nothing told it.