Technical Context
I fully agree with the brainstorm → spec → plan → implementation formula. When I'm doing AI implementation in real-world development, I almost never ask Claude to write the entire feature at once. At that point, the model doesn't understand the task's boundaries and starts making architectural assumptions for me.
First, I use it as a context aggregator. I provide the feature's goal, pieces of the current architecture, constraints, API contracts, and contentious points, and ask it to return this information in a summarized form: what it understood, what's missing, and where the risks are. This step alone prevents half of all strange decisions.
Next, I don't jump straight into coding. I ask for a spec: what exactly are we changing, what are the non-goals, acceptance criteria, edge cases, and which modules will be affected. If the specification seems weak, a new session won't help because the problem isn't the context window but the fact that the task isn't fully defined yet.
After that, I ask it to expand the spec into a plan. Not an abstract plan like "do the backend, then the frontend," but a proper engineering breakdown: order of steps, dependencies, files, tests, migrations, and rollback risks. Only then do I start the implementation from the plan, usually in small chunks.
I often start new sessions, but not magically "to generate code," but to establish a clean phase of work. In a new session, I pass the refined spec, the plan, and the necessary code context. This is much better than dragging along a long back-and-forth conversation filled with mixed ideas, refutations, and dead ends.
Delegation also works, but not as a substitute for thinking. I might ask Claude to separately gather unknowns, suggest a spec structure, or check the plan for holes. In other words, I delegate subtasks, not the responsibility for the engineering solution.
Impact on Business and Automation
In practice, there are three wins here. First: less wasted code that later needs to be discarded. Second: it's easier to estimate timelines because the plan is already broken down into real steps. Third: it's easier to build automation with AI in a team where multiple people and assistants are working on the same feature.
Teams with complex context benefit the most: legacy systems, integrations, non-standard logic. Those who still ask the model to "build a complete system" in a single prompt and then wonder why everything falls apart during review lose out.
At Nahornyi AI Lab, I solve precisely these kinds of problems for clients: I break down chaotic development into a manageable pipeline where AI automation speeds up releases instead of creating new risks. If your features are drowning in context, let's look at your process and build an AI integration scheme that genuinely eliminates redundant manual work.