Why Most Developers Get Mediocre Results from AI
Every developer has tried this: type a one-line prompt, get 200 lines of plausible-looking code, then spend two hours fixing it. The instinct is to blame the model, but AI assistants like Claude are force multipliers for clarity — vague input produces confident, wrong output. 'Minimal input' doesn't mean lazy prompts; it means front-loading a small amount of structure so that every prompt afterwards can be short and still land accurately.
The Golden Rule: You Plan, AI Executes
Anthropic's own research on real Claude Code sessions found a clear division of labour: developers make roughly 70% of the planning decisions, while the AI makes about 80% of the execution decisions. In other words, people decide what to build and the agent decides how to build it. The workflow below is built around that split — you own the plan, the documentation, and the acceptance criteria; Claude owns the typing.
Phase 1: Plan the Project Before Any Code
Never start with 'build me an X'. Start with a planning-only session: describe the goal, the users, the stack, and the constraints — and explicitly tell Claude not to write code yet. Ask it to ask you clarifying questions first, then produce a scope document, an architecture overview, a folder structure, and a milestone plan. If you use Claude Code, this is exactly what plan mode exists for: it separates exploration from implementation, so you never solve the wrong problem at high speed.
I want to build a multi-tenant invoice tracker for small agencies.
Stack: ASP.NET Core 9 + Next.js 15 + PostgreSQL. Solo developer, 8-week budget.
Do NOT write any code yet.
1. First, ask me every clarifying question you need.
2. Then produce: scope (in/out), architecture overview, folder structure,
core database entities, and a milestone plan (M1, M2, M3...)
where each milestone is independently testable.Phase 2: Turn the Plan into Living Documentation
Don't let the planning output die inside the chat. Save it as real files in your repo — a PROJECT.md for scope and architecture, plus a short conventions file listing stack versions, naming rules, build/test commands, and hard 'never do this' rules. Claude Code automatically reads a CLAUDE.md file at the start of every session; in the web app or API you simply attach the same document. Keep it concise — one focused page that Claude actually follows beats a 400-line style guide that gets partially ignored — and update it every time an architectural decision changes.
Phase 3: Divide Large Projects into Milestones
AI models have a context window, and output quality drops as it fills up. So a large project should never be one endless conversation. Break it into modules — auth, billing, reporting — define the interfaces and database contracts first, then build one module per session, pointing Claude at your PROJECT.md each time. Finish, test, and commit each milestone before starting the next. A fresh session with good documentation beats a bloated session with a full memory, every single time.
Write Coding Instructions Like a Spec, Not a Wish
Once the plan and docs exist, each coding prompt should read like a mini-specification. Name the exact files to modify, the pattern to follow, the versions in play, and — just as important — what Claude must NOT touch. Give one task per message with expected inputs and outputs, and you will stop receiving creative solutions to problems you never had.
// Weak — invites guesswork
"Add login to my app."
// Strong — reads like a spec
"In the ASP.NET Core 9 API (see PROJECT.md), add POST /api/auth/login.
- Validate the request with FluentValidation, matching RegisterRequestValidator.
- On success return a JWT (60 min expiry) + rotating refresh token,
following the existing pattern in AuthService.cs.
- On failure return 401 using our standard ProblemDetails shape.
- Do NOT add new NuGet packages. Do NOT modify the registration flow.
Touch only: AuthController.cs, AuthService.cs, LoginRequestValidator.cs."Always Ask for a Test Project
Every build instruction should end with the same sentence: 'and create or update the test project.' Ask for a proper xUnit (or NUnit/Jest) project alongside the code, covering the acceptance criteria from your milestone plan. Even better, flip the order — tell Claude you are doing test-driven development, have it write tests from expected input/output pairs first, run them to confirm they fail, and only then implement until everything passes. Saying 'TDD' explicitly matters: it stops the model from writing mock implementations just to turn the tests green. Tests convert 'looks right' into 'provably right', which is the entire point of using AI for production code.
How to Report Build and Runtime Errors
'It doesn't work' is the most expensive sentence you can send to an AI. When a build or runtime error appears, hand over evidence, not vibes: the exact error text and stack trace, the file or method involved, what changed since it last worked, what you expected to happen, and your environment details. Report one error at a time, ask for the root cause before the fix, and after applying the fix, re-run and paste the fresh output instead of assuming it worked.
WHAT I DID: Ran `dotnet build` after adding the ReportModule project.
EXACT ERROR (full text):
error CS0246: The type or namespace name 'ITenantContext'
could not be found (ReportService.cs, line 14)
WHAT CHANGED: Added ReportModule.csproj — no other edits
since the last green build (commit a1b2c3).
EXPECTED: Build succeeds as it did before the change.
ENVIRONMENT: .NET SDK 9.0.301, Windows 11.
First explain the root cause, then give the minimal fix.
Do not refactor anything unrelated.The Payoff: Minimal Input, Maximum Output
This workflow front-loads perhaps an hour of planning and documentation. In return, every prompt for the rest of the project shrinks to a few lines, because the context lives in your repo instead of in your typing. Accuracy goes up, rework goes down, and the AI stops behaving like a slot machine and starts behaving like a reliable junior engineer who has actually read the onboarding docs.
AI doesn't reward the developer who types the least — it rewards the one who thinks the clearest. Give it a plan and it gives you a product; give it a wish and it gives you homework.— Kathan N. Patel
I use this exact workflow to ship .NET and Next.js products — compliance SaaS, legal-tech integrations, and internal tools. If you want help setting up an AI-assisted development workflow for your team, or you have a product to build, use the contact form and let's talk.
