<p>I spend a lot of time reading about how developers use AI coding agents. Not the “I built an app in 5 minutes” demos. The production stuff. Teams shipping real code, breaking things, slowly figuring out what works.</p>
<p>Something clicked recently. The people getting the best results aren’t doing anything magical with their prompts. They’ve changed how they work. And the changes look nothing like what the tool vendors suggest.</p>
<h2>The file that matters more than your model</h2>
<p>Max Woolf is a data scientist who wrote “As an Experienced LLM User, I Actually Don’t Use Generative LLMs Often” back in 2025. A self-described agent skeptic. Then he tried Opus 4.5 and started shipping Rust projects he couldn’t have built alone.</p>
<p>His take on what changed: <a href="http://AGENTS.md" target="_blank" rel="noopener nofollow">AGENTS.md</a> (or <a href="http://CLAUDE.md" target="_blank" rel="noopener nofollow">CLAUDE.md</a>, or .cursorrules, whatever your tool calls it). He thinks it’s the single biggest differentiator between good and bad results, more than model choice, more than prompt engineering.</p>
<p>The part that surprised me: negative rules work better than positive ones. “NEVER add redundant comments” and “MUST use uv, not base Python” land harder than describing what you want. His approach is to add a rule every time the agent does something wrong. The file grows from experience, not theory. Most people write theirs once and forget about it. That’s the gap.</p>
<h2>Architecture decisions before a single line of code</h2>
<p>Boris Tane wrote about a workflow I keep coming back to. He asks Claude to write a <a href="http://plan.md" target="_blank" rel="noopener nofollow">plan.md</a> file. Opens it in his editor, adds notes inline (“use drizzle:generate for migrations, not raw SQL” or “no, this should be a PATCH not a PUT”). Sends it back with “address my notes, update the document, don’t implement yet.” Then repeats that 3-6 times.</p>
<p>By the time implementation starts, every hard decision is made. The coding part becomes mechanical. I’ve been trying this and the quality difference is noticeable. The expensive mistakes happen in architecture, not syntax. Letting an agent loose on code before you’ve agreed on the plan is where things go sideways.</p>
<p>This connects to something I saw with fleet parallelism. Someone translated a website into 8 languages overnight using 6 Copilot agents in parallel. All PRs opened within 12 minutes of each other, zero conflicts. The Arabic agent even added RTL support without being asked.</p>
<p>But the agents weren’t the story. The story was the spec work done before any agent touched the code. Each translation file only contained translatable fields. Structural data always came from the English source. The architecture was designed with isolated boundaries so agents could work simultaneously without stepping on each other. Parallelism was a consequence of good upfront design, not a feature of the tools.</p>
<h2>When humans can’t keep up with agents</h2>
<p>PlanetScale is running 2,000 PRs a month through an automated reviewer called Bugbot. 80% of its comments get addressed before merge. Their engineer Fatih Arslan said something that stuck with me: asking a reasoning model to “review this branch” doesn’t find the same bugs. The specialized harness catches state synchronization gaps, async convergence failures, edge cases that trigger restarts across production databases. Generic prompting misses them.</p>
<p>This is becoming a real tension. If your team generates more code with agents, human review becomes the bottleneck fast. PlanetScale estimated they’d need two full-time engineers just reviewing code. That’s engineering bandwidth lost to reviewing, not building.</p>
<p>Stripe is facing the same thing at a different scale. Their coding agents (Minions) merge 1,300+ PRs per week. Their answer was to shift feedback left: agents run linters locally before hitting CI, typically getting 1-2 CI rounds max. Mike Cohn recently argued that the classic cost-of-change curve is dead, killed by three waves: better tooling, agile, and AI. His punchline is that the cost of change is no longer about writing code. It’s about waiting for feedback. Every minute your agent waits on CI is a minute wasted.</p>
<h2>Giving agents the right interfaces</h2>
<p>Mendral does something I find genuinely interesting. They let AI agents debug CI failures across 1.5 billion log lines per week by giving them a raw SQL interface to ClickHouse. No predefined query library. No <code>getfailurerate(workflow, days)</code> function. Just SQL.</p>
<p>Their reasoning: a constrained API limits agents to questions you anticipated. SQL lets them ask whatever they need. And LLMs are surprisingly good at SQL because there’s so much of it in training data. Last week, one of their agents traced a flaky test back to a dependency bump three weeks prior, scanning hundreds of millions of log lines to get there.</p>
<p>On the flip side, there’s a cautionary tale from Helix ML. They migrated a code RAG system from Python to Go using Claude Code. The agent found references to a deprecated “snippets” table that had been replaced months earlier. It rebuilt the entire dead feature. Everything compiled, tests passed. Searches returned zero results because it was querying an empty table nobody uses anymore. The failure only showed up with real production data. If deprecated code exists anywhere in your codebase (type hints, variable names, comments), agents will find it and use it.</p>
<p>This is where test suites become critical. Cloudflare reimplemented 94% of the Next.js API in a week. One engineer, roughly $1,100 in tokens. But the reason it worked: they ported the existing test suite first, then had Claude implement piece by piece, verifying against the tests before merging. The tests defined what “correct” meant. Without them, the agent would have been guessing. Your test suite is your specification now, whether you intended it that way or not.</p>
<h2>Collapsing the context problem</h2>
<p>Cursor’s own support team handles 75%+ of their support interactions through Cursor itself. 5-10x throughput increase. The setup is multi-root workspaces with MCP servers connecting to databases, Slack, Linear, internal docs, and streamed event logs. All in one session.</p>
<p>Investigations start by tracing backward from a symptom through the actual product code. Because every data source is in one place, context-gathering (which was the real bottleneck, not problem-solving) collapses. They also run parallel subagents: one searches logs, another scans for known issues, a third drafts the response.</p>
<p>Any workflow where you’re switching between 5 tabs to investigate something can probably be collapsed this way. The pattern isn’t specific to support.</p>
<h2>Understanding code you didn’t write</h2>
<p>Simon Willison built a macOS presentation app in 45 minutes with Claude Code. Native Swift, 355KB binary, phone-based remote control via built-in web server. He doesn’t know Swift.</p>
<p>After pushing to GitHub, he asked Claude to generate a “linear walkthrough” of the codebase. A sequential explanation of how everything works, file by file. He liked it enough to add it as a pattern in his agentic engineering guide.</p>
<p>I think this is underrated. When agents write your code, the old model of understanding (you know it because you wrote it) breaks down. You need a different approach. A walkthrough gives you the guided tour of a codebase that exists only because an agent built it.</p>
<hr>
<p>None of these ideas are mine. They come from Max Woolf, Boris Tane, Fatih Arslan at PlanetScale, the Mendral team, Helix ML, Steve Faulkner at Cloudflare, Mike Cohn, Stripe’s engineering team, Cursor’s support team, and Simon Willison. I kept seeing the same patterns show up across their work and wanted to collect them in one place.</p>
<p>If there’s a thread connecting all of this, it’s that better results come from changing how you work, not from writing better prompts.</p>


Everything about vibe coding 🤖
Tools, tips, tricks, workflows, best practices, you name it.
Let the vibes guide you

Vibe Coding

A curated collection of real-world patterns from developers and teams shipping production code with AI coding agents. Key insights include: maintaining a living rules file (AGENTS.md/CLAUDE.md) with negative constraints that grows from experience; doing iterative architecture planning in a plan.md before any implementation; designing isolated boundaries to enable parallel agent work; using specialized automated reviewers (like PlanetScale's Bugbot) to handle review bottlenecks at scale; giving agents flexible interfaces like raw SQL rather than constrained APIs; treating your test suite as the specification for agent-driven implementation; collapsing context-switching by connecting agents to all data sources in one session; and generating linear codebase walkthroughs to understand code you didn't write. The throughline: better results come from changing how you work, not from better prompts.

Patterns from developers who actually ship with coding agents

<p>I echo debugging part, honestly I much prefer debugging through talking with LLM then googling and looking through bunch of docs or unstructured pages. You learn new stuff!</p>
<p>The last 2% part happens by me questioning and agreeing on full plan either way.</p>
<p>Nice write-up!</p>
