Practical developer interpretation
The first AI prompt should not be: write the code.
A better first prompt is: find similar GitHub open-source projects and explain how they are built.
When you ask for code first, the model has to invent structure. It may produce something that runs, but the architecture can be arbitrary. When you ask for comparable repositories first, the model has to reason from existing product and code patterns before it generates anything.
That shift matters because most early build mistakes are not syntax mistakes. They are boundary mistakes. State lives in the wrong place. API routes grow without a clear domain model. Configuration spreads across the app. Deployment assumptions leak into application code.
The opening prompt
I want to build [service description].
The main users are [user type], and the core features are [feature list].
Find similar GitHub open-source projects and compare them.
For each project, summarize the problem it solves, main features, directory structure, data storage approach, authentication boundary, deployment shape, license, maintenance signals, useful design ideas, and parts I should not copy directly.
Do not write code yet. Start with a comparison and a recommendation.
The important line is: do not write code yet.
That line keeps the model in analysis mode. It also gives you a chance to inspect architecture before implementation begins.
What to compare before code
I usually ask the AI to compare the repositories across a few practical dimensions:
- Where the user flow starts
- How client and server responsibilities are separated
- Whether the data model follows domain concepts or UI screens
- Where auth, permissions, and environment configuration live
- How async work is separated from request handling
- Whether tests and seed data explain real usage
- How deployment assumptions shape the codebase
This is not about copying a repository. It is about building a map of decisions.
The second prompt
After the shortlist, I ask:
From these projects, extract the repeated architectural patterns.
For my service, separate what is necessary now from what is overbuilt.
Propose the smallest vertical slice for version one.
Explain the folder structure, data model, API boundary, and screen flow before writing code.
At that point, code generation becomes much more useful. The AI is no longer filling an empty page. It is implementing inside a structure that has already been compared.
Implementation framing
A good AI-assisted build can follow this sequence:
- Ask for comparable open-source projects.
- Compare architecture, product scope, and boundaries.
- Choose the smallest useful vertical slice.
- Ask the AI to generate only that slice.
- Review the generated code against the comparison, not against vibes.
This gives you a practical review checklist. If a generated module does not match the chosen boundary, you can push back. If a feature appears that was not in the first slice, you can remove it. If the AI creates a clever abstraction too early, you have a reason to simplify it.
Top comments (0)