Code Generation in ADE: Not a Magic Box, But a Systematic Process

AI-powered development environments (ADE — AI Development Environment) have become an indispensable part of the software production process. Setting traditional programmer roles aside, ADE combines the product thinking process with software development and product management, transforming the “solo entrepreneur” into a “solo crafter.” While the process may seem like a one-person show, it actually brings together the functions of an entire team into a single individual. Although this environment instantly offers us — relatively — code like a wizard, it requires a conscious and systematic pre-preparation process to unlock its true potential.

This article interprets the Spec-Driven Development (SDD) methodology, which forms the basis of AI-powered development processes. My goal is to position AI not as a standalone tool, but as part of a development workflow, enriching a modern framework that combines traditional engineering principles with the requirements of the AI era to achieve an output that is as close to ideal as possible. When ADEs are left to take an idea and move directly to the coding phase, the process can become slow due to issues and limitations such as missing details, hallucinations, or constraints (time and tokens), as they focus only on core technical details.

At this point, before coding begins, ambiguities must be clarified by answering relevant questions from both the business and technical worlds, such as “why?”, “how?”, and “what should be solved now?” This strengthens the project’s value and coding capability from the outset. It also minimizes the risk of AI generating “self-assured but incorrect content.” While it may not be possible to eliminate all hallucinations (in creative fields like poetry or storytelling, this might even be desirable), when it comes to technical, financial, security, or critical decision-making agents, evidence-based results are of vital importance. The goal is not zero imagination, but selective reliability.

Let’s examine step-by-step how to give AI the right instructions before having it write the code.

1. Research: Understanding the Problem and the Ecosystem

Every software project begins with a problem to be solved or an opportunity to be seized. At this stage, our goal is to accurately define the problem and scan existing solutions in the ecosystem to build a strong knowledge base. This is where the solo crafter puts on their product manager hat. While AI services can be used in this research and enrichment step, the critical point to note is that AI is trained on old data and bases its conclusions on that old data. For this reason, you should be careful with the guidance you receive.

Resources for Research:

• Academic literature and whitepapers (arXiv, Google Scholar) → To understand theoretical approaches.
• Stack Overflow, Reddit, Hacker News → To discover real-world developer problems and solutions.
• ProductHunt, IndieHackers → To examine similar product ideas and implementations.
• GitHub / GitLab → To find reference architectures and code structures from open-source projects.
• Official documentation (Framework/SDK/API) → To understand technical limitations and possibilities.
• AI-powered analysis tools (Firecrawl, SerpAPI, etc.) → To quickly gather information and analyze current trends.

🔑 Tip: Remember, at this stage you need to answer not just the problem, but also the question “why should it be solved now?” This directly contributes to the project’s feasibility and clarifies your roadmap.

2. Idea: Initial Draft and Scenarios

After the research phase, the initial solution idea is developed in light of the information obtained. This idea can start with a single-sentence summary and then be enriched with user scenarios. This is the part where the solo crafter takes on the role of a designer. Again, when using AI services for idea generation and scenario enrichment in this step, it is necessary to question the timeliness of the data and be careful with guidance based on outdated information.

Techniques:

• Brainstorming & Mind Mapping: To visualize the branching of ideas.
• User Story Mapping: To translate user needs into scenarios.
• Design Thinking: The loop of Empathize → Define → Ideate → Prototype → Test.

3. Spec-kit: Documentation and First-Level Draft

Before moving an idea to the coding stage, it must be turned into a specification document (spec-kit). This documentation shows that the solo crafter is now thinking like an analyst. This also prepares the ground for AI to say “I don’t know” in uncertain situations by telling it to “define the Truth & stakes from the start.”

Spec-kit: A CLI-based script from GitHub’s SDD framework that generates basic Product Requirements Documents (PRDs), task plans, and requirements documents from a paragraph of an idea.

The Spec-kit covers the following sections:

• Problem Definition: A clear definition of the problem to be solved.
• Scope: What the project will and will not do.
• Use Cases: User scenarios and flows.
• Technical Requirements: Platform, framework, and integration needs.
• Acceptance Criteria: The definition of “done.”
• Risks and Constraints: Points like data access, performance, and security.

The document prepared at this stage serves as both the foundation for the prompts to be used within the ADE and as a reference document for the project’s entire future.

4. Enrichment: Feasibility, PRD, Requirements, Task Plan

After the Spec-kit is created, the document must be enriched at the technology, architecture, UI, and component level. This stage shows that the solo crafter has now become an architect. The detailed planning done here is a preparation for applying the “logic cop” and “Guardrails” approach mentioned by Daron Yöndem to the code. In this step, too, you can get help from AI services, but you should keep in mind that AI’s conclusions may not be up-to-date as a result of being trained on old data.

4.1. Technology Choices

• Language & Framework: (e.g., TypeScript + Next.js, Python + FastAPI, Java + Spring Boot)
• Database: (Supabase / PostgreSQL, MongoDB, Firebase)
• DevOps / Hosting: (Vercel, Netlify, Docker + Kubernetes, GitHub Actions)
• Authentication: (Supabase Auth, Auth0, Clerk, custom JWT)

4.2. Architectural Approaches

• Monolithic vs. Microservices: Decision is made based on project size.
• Event-Driven Architecture: Used in areas requiring IoT and real-time data.
• Clean Architecture / Hexagonal Architecture: Preferred for long-term sustainability.
• Serverless Approach: Ideal for rapid prototyping and low costs.

4.3. UI / UX Approaches

• Component-based UI: Technologies like React, Svelte, Vue.
• Design System / UI Kit: ShadCN UI, MUI, Tailwind + Flowbite, Radix UI.
• UX Principles: Loading states, empty states, error handling, and responsive design.
• Accessibility (a11y): Screen-reader friendly, color contrast for color blindness.

4.4. Task-Based Component / Library Plan

A direct component and library mapping can be made for each requirement.

• Authentication Task → Supabase Auth + OAuth2 flow.
• Graphing Task → Recharts, D3.js, or Chart.js.
• Form Management Task → React Hook Form + Zod validation.
• State Management Task → Zustand, Redux Toolkit, or React Query.
• Testing Task → Vitest, Jest, Cypress (End-to-End).
• Analytics Task → PostHog, OpenTelemetry, Plausible.

In the task creation phase, defining a GIT repo, setting checkpoints, creating sub-branches if necessary, and regularly performing commit & push are also points that should not be overlooked.

4.5. Project Standards and Development Guide

1. Tech Stack

The tools and versions of the project are clearly specified:

• Astro 4.5
• Tailwind CSS 3.4
• TypeScript 5.3
• Supabase 2.0

2. Project Structure

The roles of the main folders are described:

• src/components → Reusable UI components
• src/lib → Business logic and domain services
• src/pages → Route-based pages
• src/styles → Global styles and theme management If you want to go into more detail, ADEs are already at a point where they can create most of this with approval.

3. Commands

The most frequently used npm / bash commands are specified:

• npm run dev → Local development
• npm run build → Build for production
• npm run test → Run tests
• npm run lint → Code style check
• npm run deploy → Automatic deployment

🔑 This list prevents the AI from generating incorrect commands and breaking the build process

4. Code Style and Rules

• Formatting: Prettier + ESLint.
• Naming: camelCase (variables), PascalCase (components).
• Import/Export: Destructuring if possible (import { foo } from 'bar').
• File Names: kebab-case (e.g., user-profile.tsx).

5. Repository Etiquette

• Branch Names: feature/TICKET-123-description.
• Commit Message Format: [type]: brief description (e.g., feat: user login screen).
• Merge Strategy: Merge Commit after PR, squash for production.

6. Core Files and Helpers

Central files that the ADE needs to know are marked:

• src/lib/api.ts → Central file for API calls.
• src/lib/utils.ts → General utility functions.
• src/lib/config.ts → Shared configurations.

7. The “Do Not Touch” List

Critical areas that the ADE should never change are specified:

• Existing (legacy) code.
• config/* files.
• Security policies and access control.
• Accessibility (a11y) controls.

5. ADE: Transitioning to the AI-Powered Development Environment

Now we have a sufficiently mature idea, comprehensive documentation, and a clarified task list. At this point, the project is handed over to the ADE. This is where we implement the RAG (Retrieval-Augmented Generation) and Tool Composition stages, as also mentioned by Daron Yöndem.

Before starting to code, it is also very, very important to have the ADE review and interpret the documents and clarify any points it deems necessary to avoid getting stuck during the development phase. All these improvements will provide great comfort and support in terms of starting the coding, and managing token and limit issues.

The role of the ADE:

• Creating the code skeleton.
• Generating module-based code according to requirements.
• Preparing test scenarios.
• Querying missing points.

6. Detailed Prompts: Clear Instructions Before Coding

When asking ADE to generate code, deciding how much free rein to give it is a critical decision. I will discuss this topic in more detail in the second part of the article.

To quickly mention it, the decision to be made before starting to code is whether the ADE should proceed with a task-oriented approach or a manual prompt approach.

6.1. The “Take the Task and Develop” Approach

• Advantage: The ADE can suggest more creative solutions.
• Disadvantage: The risk of misunderstanding the requirements increases.
• Use Case: Prototyping, Proof of Concept (PoC), and code generation for exploratory purposes.

6.2. The “Guide with a Detailed Prompt” Approach

• Advantage: Code is generated that is 100% compliant with the requirements.
• Disadvantage: It limits the flexibility of the ADE.
• Use Case: Projects close to production and environments with established team standards.

6.3. The Hybrid Model

The most efficient method is often a hybrid:

1. First, tell the ADE to “take the task and develop” → to see alternative paths.
2. Then, the resulting code is reviewed and improved with a detailed prompt.

Example Scenario: Authentication Module

• Task: User login with Google OAuth.
• Spec-kit Requirement:
• Next.js + Supabase will be used.
• There will be a “Remember Me” option.
• After 3 incorrect login attempts, the user will be locked for 5 minutes.

Flexible Prompt to ADE:

“Write a Google OAuth-based login flow using Next.js + Supabase. Add a ‘Remember Me’ feature. Suggest different methods for temporary lockout on incorrect login.”

Detailed Prompt to ADE:

“Write the code for a Google OAuth login flow using Next.js (App Router) + Supabase auth. The user login form will have a ‘Remember Me’ checkbox. If this box is checked, the refresh token will be stored in the browser for 30 days. For incorrect logins, Supabase’s rate limit feature will be used. Generate a simple but responsive interface with TailwindCSS. Finally, add route protection with Next.js middleware.”

Conclusion

Using ADE in the coding process only shows its true value when the right preparation is done. Research, ideas, spec-kits, and enriched documents enable the ADE to generate more conscious and error-free code. This systematic approach lays the groundwork for the “Faithfulness” and “Calibration” metrics mentioned by Daron Yöndem, providing developers with:

• Reduced ambiguity,
• Clarified requirements,
• The ability for AI to query and fill in missing information,
• Faster, more sustainable, and higher-quality code development.