Shipping with AI agents for 6 months: the "fast but wrong" trap I keep falling into
I've been building side projects with Claude Code and Cursor for the better part of this year. The speed is insane. I can go from idea to PR in an afternoon.
But I noticed something weird: the faster I shipped, the more I had to rewrite.
The agent would build exactly what I described in the issue. The problem? The issue description was rarely what the customer actually needed. It was just my best guess after reading a Slack thread, a support ticket, and a call transcript three days ago.
So the agent built a CSV export. Fast. Clean. Merged.
Then the customer said: "We needed this for compliance audits, not just downloads."
Different implementation entirely.
The gap: The agent has all the code context in the world, but zero customer context. It doesn't know:
- The support ticket that started the request
- The sales call where the prospect said it was a dealbreaker
- The team decision from March that ruled out a third-party library
I tried solving it with longer prompts, custom instructions, and MCP connectors. It worked for a week, then rotted. Every new signal source needed a new connector. Every decision change needed a prompt update. I spent more time maintaining the agent's context system than using the agent.
What I'm trying now: Treating the customer signal as a separate "brain" that lives outside the agent session. I feed it tickets, transcripts, and decisions. When I pick up an issue, it synthesizes a plan with cited sources, non-goals, and contradiction checks before the agent writes code.
But I'm still figuring this out.
My question for you: If you're shipping with Claude/Cursor/Codex, how are you getting customer context into the agent's workflow? Are you:
- Manually copy-pasting into prompts?
- Using MCP connectors to pull from Notion/Slack?
- Just relying on good issue descriptions (and who writes those)?
- Or have you found something else that works?
Genuinely curious how other solo devs and small teams are handling this. The coding part feels solved. The context handoff still feels broken.
the CSV export vs compliance audit example is such a clean illustration of this. what's helped me isn't trying to feed the agent more customer context at coding time, it's writing the why down at decision time, in a doc that sits next to the code, before the agent ever touches it. not a giant context dump, just a few sentences on why this specific approach and what it's explicitly not trying to solve. doesn't fully replace someone who talked to the customer annotating the spec like the other comment mentioned, but it means the next session (agent or human) isn't reconstructing intent from a bare ticket title
This is something we've learned the hard way as well.
AI is great at writing code, but it can't infer the business context behind a feature. In our experience at IT Path Solutions, the quality of the outcome depends far more on the quality of the problem definition than the prompt itself.
The biggest improvement came when we started treating product decisions and customer feedback as first-class inputs, not something developers had to remember. Once that context is captured, AI becomes much more reliable.
I'm building a second brain for your codebase. It maps your repo and gives coding agents the context they need before they write code, so they make fewer wrong assumptions.
We're testing the beta with a small group of developers. (scriptonia.dev)
The CSV export vs compliance audit distinction is the exact kind of gap that's hard to catch unless someone with customer context reviews before the agent ships. In our agency we see this pattern a lot. What we found helps is a structured handoff step between the raw spec and the agent prompt where someone who talked to the customer annotates the requirements with context the agent would never know. It adds a friction point but catches the fast but wrong cases before they reach production. Are you finding the customer context brain approach reduces rewrites enough to offset the overhead of maintaining it?
I like the distinction you're making between code context and customer context.
The interesting part is that most AI workflows optimize for implementing requirements faster, when the bigger risk is implementing the wrong requirement perfectly. Once coding becomes cheap, understanding why a feature exists becomes the higher-value input.
I'm building a second brain for your codebase. It maps your repo and gives coding agents the context they need before they write code, so they make fewer wrong assumptions.
scriptonia.dev
That's interesting.
The thing I'm still curious about isn't how much context the agent has.
It's how you decide which context should influence its decisions in the first place.
that's the exact question.
most tools throw everything at the agent and hope. more context, longer prompts, bigger windows. the agent drowns.
what we do differently: the product brain doesn't just store signal it retrieves by meaning when you describe an issue. you say "add filtering to audit log," it pulls the support ticket about compliance, the sales call where the prospect said it's a dealbreaker, and the april decision that deferred this to v2. it checks for contradictions. then it writes a PLAN.md with only the context that matters for this specific issue cited, scoped, with non-goals.
the decision of which context matters is made at retrieval time, not at coding time. the agent never sees the noise. it sees the plan.
does that answer your question, or is there a layer i'm missing?
That answers it, and it actually surfaced the layer I was looking for.
I don't think the strategic decision is the retrieval system itself.
It's the business decision that follows once founders begin trusting the product's interpretation of what context deserves to influence a decision.
I don't think I can do the reasoning behind that properly in a thread without oversimplifying it.
If you're interested, what's the best email to reach you on?