The 85% Trap: What I Learned Building With Agentic Coding

If you’re just getting started with agentic coding, this is the beginner trap nobody warns you about. The first 85% arrives in minutes. The remaining work (integration, consistency, production-readiness) takes longer to fix than it took to generate. This post breaks down why the gap exists, why closing it naively makes things worse, and shares a practical framework I use to build with AI without falling into the trap.

This is valid at this point in time. The tools are evolving fast. But the patterns I’m describing here (scoping, sequencing, owning decisions) will hold regardless of which model or tool you use. They’re about how you work with AI, not which AI you work with.

Why the First 85% Feels Like Magic

The initial experience with models like Gemini 3.0 Pro or Claude Opus 4.5 is genuinely impressive. You describe what you want. Minutes later, you have working code, a structured plan, or a component that does exactly what you asked.

Things you’d normally bootstrap from existing code or libraries, done from a prompt. Scaffolding a website from scratch, generating React components, building API endpoints, wiring up a data model. On the Salesforce side: LWC components, Apex classes, trigger frameworks. The stuff that used to eat hours of context-switching between docs, examples, and your IDE? Compressed into a conversation.

If you’ve been following my earlier writing on AI-assisted development, you know I’m not skeptical about these tools. The threshold was crossed. The productivity gains are real.

But there’s a second phase nobody warns you about.

I remember the moment it clicked. I asked for a website that didn’t exist yet, described what I wanted, and within minutes I had polished layouts with colour schemes, typography, and structure that looked like a professional designer spent days on it. It was extremely impressive. That was the “this changes everything” moment.

Why That 10-15% Gap Is Actually 30%

Here’s what happens when you look past the demo.

The AI delivers output that’s close but not end-to-end consistent. It can code. It can strategize. It can play creative director. Each capability works in isolation. But the moment you need all the pieces to work together as an integrated application, with components talking to each other, APIs plugged in, shared state managed across layers, that’s where it breaks.

The decisions AI made across your project are locally reasonable but quickly lose the end-to-end view. It stops seeing things from multiple angles. One component follows one pattern, another follows a slightly different one. The data model makes sense for this feature but conflicts with that one. The naming conventions are almost consistent. Almost. As a beginner, you don’t notice this until you’re deep into it.

That 10-15% gap you estimated? Once you account for inconsistencies, conflicting patterns, and the integration work needed to make everything actually fit together, you’re looking at 20-30% of real effort remaining.

In the Salesforce world, this shows up clearly. AI generates an Apex class that handles the happy path beautifully. But it doesn’t account for the sharing model implications you designed three months ago. Or it creates an LWC component with a slightly different error-handling pattern than the one your team standardized on. Each piece is fine. The system doesn’t cohere.

How Fixing the Gap Makes Things Worse

This is the part that caught me off guard.

You see the 15% gap. You start fixing. Reasonable, right?

Except every fix touches something else. You update one component’s pattern, and now it’s inconsistent with three others. You refactor for consistency, and the AI that helped you build the original doesn’t have the full context of what you changed and why. You ask it to help fix the fixes, and it introduces new opinions that conflict with your corrections.

Instead of covering the remaining 30%, you’re fighting to keep the 70% that looked good.

I experienced this firsthand. I built a website with every 2026 best practice I could think of: internationalization, all the recommended features, multiple product pages running in parallel. The AI happily generated all of it. And then I spent hours, then days, fixing minor inconsistencies instead of moving forward. Each fix created two new problems. The frustration wasn’t that AI failed. It’s that I’d set it up to fail by asking for everything at once.

I had to rewrite. Descope to Pareto. Accept that 20% of the features was enough for launch. Every feature needs oversight. Every decision needs end-to-end glue. More features means exponentially more glue work.

Why AI Won’t Tell You “That’s a Terrible Idea” (Until You Force It)

This is the psychological trap that makes the 85% problem dangerous.

By default, AI never pushes back. It reflects your ambition without grounding it in reality. Ask for a simple landing page, and you get a simple landing page. Ask it to build something like Amazon, and it says “sure, here’s the architecture.” Complete with microservices, recommendation engines, and a fulfillment system. No hesitation. No “what’s your actual scope?”

A colleague experienced exactly this. Asked an AI to plan something resembling Amazon’s capabilities. The AI produced a comprehensive architecture that mirrored Amazon’s platform. An experienced person says “it depends on what you want to achieve.” AI says “absolutely, let’s build it.”

Now, you can force AI to be critical. You can tell it to challenge your assumptions, poke holes in your plan, act as a devil’s advocate. And it will. But then you might end up on the opposite side: everything looks like a bad idea, every approach has fatal flaws, every scope is too ambitious. The pendulum swings from “yes to everything” to “no to everything.” Finding the right balance between AI as an enabler and AI as a critic is a skill in itself, and most beginners don’t even know they need it.

This is the Dunning-Kruger effect applied to AI-assisted work. The less experience you have with production systems, the more impressive that 85% looks. You don’t see the missing error handling, the absent security model, the gaps in how the pieces connect. You see a working demo and assume you’re 85% done.

The confirmation bias compounds it. You had an ambitious idea. AI validated it. You feel great. Nobody in the loop said “maybe start smaller.” And now you’re deep into a project that was scoped by your ambition and enabled by a tool that defaults to agreement.

What the Real Skill Actually Is

It’s not prompting.

The skill that separates productive AI-assisted work from the 85% trap is scoping, sequencing, and context management. Context management is getting more attention lately, and for good reason. People are realizing it’s the single biggest factor in whether AI-assisted work produces consistent results or chaos.

When you switch context between features, between projects, between conversations, you lose track. But here’s what’s less obvious: the AI loses track too. It’s bilateral degradation. The AI’s context window fills up or resets. You forget what the AI knows and doesn’t know. You start re-explaining things. The AI starts contradicting earlier decisions because it doesn’t have them in context anymore.

This hit me from two sides at once.

On the human side: I was building an AppExchange product, working on websites in parallel, and creating tools to speed up my own workflow, all at the same time. My cognitive overload was real. I was context-switching between projects so fast that I couldn’t keep track of which decisions belonged to which codebase. The quality of my own judgment was degrading because I was spread too thin.

On the AI side: the context window is not infinite. For Claude it’s around 200K tokens, and it performs best in the first half. Once you’re compacting the conversation or switching to a new session, the AI is essentially starting fresh on your project. Without a proper strategy and framework in place, it’s almost a brand new project for it every time. I experienced this repeatedly: I’d set up 10 rules for the AI to follow, and after a context switch it would follow one rule perfectly while ignoring the other nine. Over and over.

The real skill is knowing where the limitations are. Yours and the AI’s. What solutions do you prefer and why? What’s your strategy for taking baby steps instead of giant leaps? How do you maintain coherence when your tool has no long-term memory?

How to Build With AI Without Falling Into the Trap

The framework is simple. Deliberately simple. Because the biggest lesson from all of this is that simplicity is the strategy. Keep It Stupid Simple isn’t a cliche here. It’s the operating principle that makes AI-assisted development work.

Scope Ruthlessly

Pareto before you prompt. 20% of the features, not the 2026 dream list.

AI will never tell you “that’s too much for now.” It will happily generate an architecture for everything you can imagine. That judgment (what to build first, what to defer, what to cut entirely) is yours alone.

Build in Closed Loops

One feature. One component. Validated to production-ready. Then the next.

Not three things in parallel. Not “let me start this while that’s being reviewed.” The moment you’re juggling fixes across multiple half-built features, you’ve lost. Each open loop is a context that both you and the AI need to maintain. More open loops means more bilateral context degradation.

A closed loop means: define it, build it, test it, confirm it meets your standard, move on. The loop is small. The validation is rigorous. Only then do you start the next one.

Own Every Decision

You are the operator. The owner. Not the AI. Not the code it generated.

If you can’t explain why a particular architectural choice was made, you don’t ship it. “The AI suggested it” is not an architecture decision. It’s an abdication of responsibility.

AI suggests. You decide. You take responsibility for what gets produced. Production-readiness isn’t a universal checklist. It’s whatever standard you can stand behind. For a website, a component, a Salesforce feature: you own it.

This means reviewing AI output critically, not gratefully. Understanding the patterns it chose and whether they align with your project’s conventions. Checking whether the solution accounts for the constraints AI doesn’t know about: your org’s sharing model, your team’s skill level, your deployment pipeline’s limitations.

The loop repeats. Scope, Build, Own. Each cycle gets faster as you learn what works for your stack, your standards, your context.

Key Takeaways

• The 85% is real, but so is the trap. AI generates impressive output fast. The integration and consistency work to make it production-ready is where real effort lives. Don’t confuse a demo with a deliverable.

• More features equals exponentially more glue work. Every feature AI generates needs human oversight for end-to-end coherence. Scope to Pareto (20%) before you prompt, not after you’re drowning in fixes.

• AI is a yes-man by design. It validates ambition without reality-checking it. The less experience you have, the more dangerous this is. Bring your own skepticism.

• Context management is the hidden skill. Both you and the AI degrade when context switches. Build sequentially in closed loops. One feature validated before the next begins.

• Start with steps you can understand. Don’t step into the final AGI vision immediately. Be reasonable with tasks, goals, milestones. The more structured and reflective you are, the more you interact with community and other perspectives, the better your frameworks become.

This is how I work with AI now. Not with less ambition, but with more discipline. The tools will keep getting better. The need for scoping, sequencing, and ownership won’t go away. If anything, as AI gets more capable, the cost of undisciplined use gets higher.

Where This Is Heading

Looking forward, I can see clearly where this goes. A proper enterprise setup will be capable of connecting all the interdisciplinary topics, categories, teams, and angles together. The right context management, the right agent orchestration, the right frameworks to maintain coherence across an entire product lifecycle. There are already frameworks moving in this direction: tools like Spec Kit and Shotgun are building the infrastructure for exactly this kind of coordinated agentic development.

But here’s my advice: to get there, you have to start somewhere. Don’t make your first goal building an autonomous agentic platform for end-to-end product development. That’s the 85% trap at an organizational scale. Start with the Scope, Build, Own loop on a single feature. Get comfortable with the limitations. Build your intuition for where AI helps and where it hurts. Then scale up.

Future posts will go deeper into specific setups: how I approach Salesforce projects with AI, greenfield builds, legacy modernization. The framework stays the same. The application varies.

---

Related

This post is part of a series on AI-assisted development and vibe coding:

• The threshold: Supervising Systems That Write Code [2025 Reality Check] covers the moment AI crossed from productivity tool to development paradigm shift.
• The decision shift: Redefining OOTB vs Custom in an AI World [New Decision Criteria] explores how AI changes the build-vs-buy calculation for Salesforce architects.
• Getting hands-on: Why I Had to Get Hands-On with AI Development [A CTA’s Wake-Up Call] shares the experience of building a real product to close the credibility gap.