Stop writing code first. Write intent first.
The explore-plan-implement workflow that turns natural language into your most reliable interface to a new codebase.
You joined a new codebase last week. The docs are dense, the architecture is unfamiliar, and you have business value to ship this sprint. The traditional answer is two weeks of reading before you touch a file.
There is a faster path, and it does not start with code. It starts with a prompt like this one:
Analyze this codebase and provide a high-level overview of:
1. Technologies, frameworks, and architecture
2. Project structure and module organization
3. Build, test, and deployment processes
By the end of this post you will know how to:
- Use natural language to map a codebase in an afternoon instead of a fortnight
- Force a plan before any code gets written, so the model cannot freelance
- Sequence discovery, planning, and implementation so each phase compounds the next
- Predict the three things your team will hit when they adopt this workflow
The bottleneck was never typing
Software has always had two bottlenecks: understanding what exists, and deciding what to build next. Typing was never the hard part. Coding assistants did not make typing faster — they made the first two cheap.
The mistake most engineers make is using assistants as faster keyboards. They ask for code on turn one. They get something plausible, paste it in, and discover three days later that the model invented an API, missed a consent gate, or solved the wrong half of the problem.
The fix is a workflow, not a better prompt. Treat English as the programming language, and treat code as the compiled artifact at the end. Explore → plan → implement, in that order, with the model held to the boundary of each phase.
Phase 1: Discover before you decide
Never ask for code on turn one. Ask the model to read.
Coding assistants can scan thousands of files in minutes and tell you what is actually there — not what the README claims, not what the original architect intended, what is on disk today. Two prompts carry most of this phase:
Analyze this codebase and provide a high-level overview of:
1. Technologies, frameworks, and architecture
2. Project structure and module organization
3. Build, test, and deployment processes
Then narrow to the path you actually need to change:
Trace the checkout process from 'Checkout' click to order
confirmation, including components, API calls, and state
management.
The output of this phase is not code. It is a written summary you can read, push back on, and correct. If the model gets the architecture wrong here, you catch it for the cost of a paragraph. If you skip this phase, you catch it for the cost of a merged PR.
Phase 2: Plan before you build
Once the model knows the territory, force it to draw a map before it lays any track. The rule of this phase: no implementation until the plan is on the page and you have approved it.
For a focused change, one prompt handles this:
Before implementing, provide:
1. Files to create/modify
2. Required dependencies
3. Potential risks
4. Testing approach
5. Rollback plan
No code yet — planning only.
For larger work — a new endpoint, a schema change, a component tree — name the surface area:
Design a RESTful API for user profiles with CRUD operations.
Include: endpoints, request/response schemas, status codes,
and error handling.
Verification:
- List endpoints with methods and paths
- Define schemas with example payloads
- Document status codes and errors
- No implementation yet
The phrase "no code yet" is load-bearing. Without it, a capable assistant will produce a plan and a 400-line draft in the same response, and you will skim the plan because the code is right there. Hold the boundary.
When the plan is wrong, you fix it in plain English, in seconds. When generated code is wrong, you fix it in a review cycle. Cheap errors live in plans. Expensive errors live in diffs.
Phase 3: Implement with the plan as the contract
Now the model writes code, and the plan from Phase 2 is the spec it is held to. Two prompts do most of the work here.
For new behaviour, anchor on tests:
Implement password reset with TDD:
1. Test reset request flow
2. Test token generation/storage
3. Test password update
4. Test email notification
Write minimal code to pass each test.
For changes to existing code, force a "show, don't do" step:
Plan the refactoring of payment processing:
1. Current issues
2. Proposed solution
3. Affected files
4. Potential risks
5. Test coverage needed
Review the plan, then say "proceed." That single approval gate is the difference between an assistant that produces a PR you can land and one that produces a PR you have to unwind.
Context is the whole game. A weak prompt looks like:
fix this bug
A strong one looks like:
Debug 404 at /api/users:
1. Check routing and controllers
2. Review connection layer
3. Propose solution with steps
4. Present changes for review
You are not being polite to the model. You are giving it the same brief you would give a new engineer on day one. Everything you would say out loud belongs in the prompt.
Three things you will hit when you adopt this
If you run this workflow on a real team for a month, expect the following:
- Your senior engineers will resist this for the first two weeks. Intent-first feels slower than typing-first because the keyboard sits idle during Phase 1. The win shows up at PR review, not at the editor. Measure cycle time from ticket to merge, not lines per hour, or you will kill the workflow before it pays back.
- Your code review process will need a rewrite. Plan-first PRs land with a written design attached, and your reviewers will not know whether to review the plan, the diff, or both. Decide up front: the plan is the contract, the diff is the evidence. Reviewers approve the plan first, then verify the diff matches.
- You will catch architectural mistakes earlier than you ever did with pure type-driven design. A wrong API shape is obvious in a five-bullet plan. It is buried in a 600-line diff. Teams that adopt this stop shipping the class of bug where "the code compiles and the tests pass but the design is wrong."
If you are already feeling the first one, that is the signal you are running the workflow correctly.
What this is not
This is not a license to skip code review. The model will still hallucinate an API, miss an edge case, or write tests that pass for the wrong reason. Every diff still needs a human read.
This is not "vibe coding." The plan is the discipline. Without it, you are just typing slower with extra steps.
And this is not a replacement for design documents on greenfield work. If you are building something from scratch, the explore phase has nothing to read. You still need an architecture before you start.
The shift
The most effective engineers in the next five years will not write more code. They will write clearer intent. The keyboard becomes the last step, not the first. The skill that compounds is the one that was always undervalued — defining the problem precisely enough that the answer is obvious.
English is the new programming language. The compiler is patient. The workflow is what makes it produce something you can ship.
If you tried to delegate a real task to a coding assistant this week and got back something you had to throw away, send me the prompt you used and the diff you rejected, and I will tell you which of the three phases you skipped. [email protected].