In the last minutes of a Q&A during a session at AWS Summit Amsterdam 2026 with someone from Anthropic, I took the “stage” via the microphone to announce the upcoming fourth Claude meetup in Amsterdam. A bit of a bold move to draw some attention to my meetup, that’s true, but it led me to meet two very kind people working on a startup who were having a problem.
They were running into issues with Claude Code and complained about PRs of 3000 lines of code, which made reviews almost impossible and made understanding what was built pretty hard on them. This is definitely an issue when applying the code-as-you-go strategy, as I want to call it. It causes fatigue easily and makes understanding your app hard. That should not be the case. Understanding what your app does, what code is built by the model and what it is supposed to be used for should be clear to you. Sounds obvious, right? Call it a beginner’s mistake, call it what you want, but with a few tips one can move from code-as-you-go to AI engineering. Here’s how.
Strategy
My favorite strategy involves task lists outside of the conversation.
Your conversation is a state: it is knowledge and intent enriched with LLM output, consolidated into text in a hidden directory. It is silently deleted by Claude Code after 30 days (see my other post on increasing this). Your code, your business rules and your intent are a form of state too: the state of the operational thing you are building for solving a specific problem.
These two should remain separate. A lot of the convo with the model is not important to your codebase. What is important is the code the LLM made and the prompts you gave it to describe your intent. The rest is bloat: asking it to commit code, to change that background color, and so on. Conversation with the LLM can be noisy.
Your codebase and your plan should not be noisy.
So, best is to be as rigorous with your specifications as with your code. Explain to Claude what you want to build, let it grill you on unclear stuff, and let Claude write it down in a file outside of the conversation. This way you have a conversation piece: a classic! A document you can talk about further.
If the intent is clear and written down in this conversation document, you can have Claude make a task list out of it (like TASKS.md). Regardless of your conversation with Claude, you can keep referring to this task list at any stage of your development workflow. You can start new sessions or close old ones, or even lose your conversation, but still the state of your application is in markdown files: the conversational documents and task lists living next to your code.
Study @TASKS.md and pick the most important task to implement.
Write property based tests or unit tests (whichever is best).
After making the changes to the files run the tests.
When the tests pass, commit changed files and check off the
completed task in the tasks list.If you now build one task at a time and create a pull request, or at least a commit, for each task, you have a much clearer view of what you’ve been building and what to review. This mitigates the risk of having pull requests containing 3K lines of code.
In addition, as bonus, remember this: let Claude output specs and intent into HTML! We humans are trained in reading websites, we use them daily, so why wouldn’t you let Claude write an overview of your application in HTML? It could even draw flow charts in SVG to make it more insightful.
Convos are ephemeral, extract what matters
Other strategies are also possible: externalizing your specification to Linear or Confluence, using Beads as a task list system, or connecting Claude to Jira with an MCP, but those are topics for another post. What remains is this: extract intent from the conversation into a different layer.