AI Multi-Turn Feature Generation
2025-09-12
This document describes a technique I use to implement features with the help of AI tools, such as Claude Code, in a controlled and iterative manner. The goal is to ensure that the generated code aligns closely with my expectations and requirements.
Rationale behind the Need for AI Multi-Turn Feature Generation
The rationale behind this technique is:
- I often felt lost and overwhelmed while using AI tools to assist me with code generation. There were many instances where I asked the AI to develop a feature A, but ended up with a feature A*. When the AI got it right, that extra * was something great—an unexpected yet valuable addition to the feature. However, when the AI didn't get it right, that extra bit of undesired code became noise, obscuring the useful code and making maintenance more difficult.
- I wanted the opportunity to make small corrections during the feature generation process. This would help me feel more in control, but mainly because I find that about 10-15% of the AI's code output doesn't meet my preferences (I might be a bit OCD about it). These moments of intervention also allow me to steer the development towards the exact feature I want (A), rather than the slightly different version (A*) that the AI assumes I want.
- I wanted a method to commit AI changes immediately after the generation loop concludes, creating a checkpoint. This would allow me to review and revert to a previous known state if I'm not satisfied with the AI-generated features (code).
How it works
AI: duh, obviously, the technique depends on AI. Multi-Turn: as I said, I need to implement a feature on short iterations (turns) doing small corrections. Feature: the feature I want, not the one the AI want. Generation: code generated by AI.
The process:
-
Choose a bit of Feature A: We need to develop Feature A, so we start an OODA loop (Observe-Orient-Decide-Act). Begins by Observing everything related to the feature, including the business needs and technical context. In the Orient step, choose a small part of the feature that, based on your observations, is needed first.
-
Create a Precise Prompt: After Deciding what you want to do, write a clear prompt that representing it. Specify the non-negotiable parts of the functionality, while allowing some flexibility for the AI to be creative in other areas.
-
Generate Code: Run the prompt through an AI tool (Act) to generate the corresponding code.
-
Commit Changes: Create an automatic commit using the prompt that initiated the change as its description.
-
Review and Adjust (for the next OODA loop): Review the generated code and make any necessary adjustments or improvements. Update any relevant documentation files (.md files) if needed.
Example
Let's say we have a corporate website that is focused on SEO to help our website appear higher in search results, making it easier for people to find us online. Our website also focuses on providing content about our company and the events we organize. This includes news, articles, and updates that keep our audience informed about what we are doing. The website is managed by marketing users who are not technical experts, but they are skilled in creating great content and promoting our events effectively.
Now, I need to implement this feature:
To see information about the company's events and marketing campaigns. As an anonymous visitor to the site I want to go to a URL and have the page build dynamically based on its slug.
So, instead of asking Claude Code to do all that in a single prompt like this:
> I want you to build a dynamic landing page that will take data to fill each part of the template from the database using the slug as a key.
You can do this (following the OODA loop pattern), where the Act part is writing that prompt to Claude Code:
O: I read the user story; I think about the business and the importance of the feature.
O: The URL is very important for the business (SEO, ads, banners, etc.)
D: I'm going to solve the routes issue first.
A: > I want you to add a page under the route /landing/[slug] that shows the [slug] (the dynamic part of the route) in a span.
O: Test the page at /landing/[slug], compare expectations with reality, adjust context.
O: The slug is important because behavior changes if it exists in the database or not.
D: Take slug, check against database; if it exists, show landing info; if not, redirect to a 404 page.
A: > I want you to show the landing title in a span if the slug exists in the database (using the landing pages client); otherwise, redirect to a 404 page.
O: Test. Does it align with the user story and business? What else is needed in terms of new pages and SEO?
O: I need to add metadata for search engines and social media.
D: Add META tags, OG tags with images, title, and description to the page.
A: > I want you to add meta tags for search engines and OG meta tags using all available information from the landing_page object. If you have doubts about using a specific property of this object, ask me whether it's convenient or not.
O: Test. Share page on social media and check fields. Now, next important thing is that it looks nice!
O: I want it to use an existing landing as a template.
D: Use an existing page as a template and replace content with content from the landing page fetched from database.
A: > I want you to use "the-mentor-meetup.tsx" page as a template for our dynamic landings page. Replace each section's information with corresponding properties from landing_page object. If you're unsure about making any changes, ask before doing so.
What about the automatic commit process after each loop?
I have set up a safety system using Hooks (at least with Claude Code).
I use the UserPromptSubmit
hook to save the current prompt temporarily (improvable code, but you get the idea):
Then, I use the Stop
hook to save or "commit" it, using the saved prompt as the description of that commit.
Significant Revisions
Set 15, 2025: Original publication on dariomac.com