Stop coding. You haven't done the research yet.
Everyone's building with AI now. Cursor, Claude Code, Windsurf, Bolt. Pick your weapon. You describe what you want, the agent writes code, and ten minutes later you have something that looks like a working app.
Looks like.
Here's what actually happens next: you try to add a feature, something breaks, you paste the error back in, the agent "fixes" it by quietly removing a validation check, and now you have a working app with a security hole you'll never notice. I've been there. Most people building with AI have been there.
The problem isn't the tools. The problem is we skip the part that makes the tools useful.
The 70% wall
There's a pattern that keeps showing up in every honest conversation about AI coding. The first draft looks great. Then you start iterating, and things fall apart. Columbia University researchers studied this across five major coding agents (Cline, Claude, Cursor, Replit, V0) and found the same failure modes everywhere: silent business logic errors, broken error handling, agents that "fix" bugs by disabling safety checks.
A CodeRabbit analysis of 470 GitHub pull requests found AI co-authored code had 1.7x more major issues than human-written code. Logic errors were 75% more common. Security vulnerabilities ran nearly 3x higher.
These aren't weird edge cases. These are the predictable consequences of skipping research and jumping straight into implementation.
Why planning feels wrong (but isn't)
I get the resistance. You open Cursor, you have an idea, you want to see code. Planning feels like you're wasting the AI's speed.
But Addy Osmani, who's spent years shipping code at Google, describes his AI workflow going into 2026 the same way: the first step is brainstorming a spec with the AI, outlining a plan, fleshing out requirements. All before writing a single line of code. He compiles this into a spec document covering requirements, architecture, data models, and testing strategy. Only then does implementation begin.
Randal Olson puts it more bluntly: 75% of your time should be in the first two phases (planning and design). The actual coding should be the easy part. If implementation feels hard, you didn't plan enough.
This isn't theory. Teams with strong planning and review processes see quality improvements from AI tools. Teams without them see quality get worse. The AI amplifies whatever you already have, good or bad.
What research actually means here
"Do your research" sounds vague. Let me be specific.
Before you touch an AI IDE, you should know what you're building and for whom. Not "a SaaS app." What problem, for which users, with what constraints. If you can't explain the data model on a whiteboard, you're not ready to prompt an agent.
You should know what the architecture looks like. Services, data flow, auth model, infrastructure. You don't need every detail, but you need the skeleton. An agent that doesn't know your system's shape will invent one, and it probably won't match what you needed.
You should know where the risks are. Multi-tenant access? Payment processing? User-generated content? These are the places where AI-generated code fails hardest, because LLMs optimize for "does it run?" not "is it safe?"
And you should know what you're not building. Scope creep kills AI-assisted projects faster than anything. If you haven't defined your non-goals, every prompt becomes an invitation for the agent to add features you didn't ask for.
Use a planning bot before you use a coding agent
Here's a practical trick that works well: before you open your AI IDE, open a separate AI chat (Claude, ChatGPT, whatever you prefer) and use it purely for research and architecture planning. Not code. Not implementation. Just thinking.
You can go further. Set up a custom bot (a Claude Project, a custom GPT, or just paste a system prompt into your chat) that's specifically designed to interrogate your idea before you build it.
I use one that acts as a systems architect. It doesn't write code. It asks questions. It runs through a checklist of every architectural layer (data models, auth, infra, scalability, security, failure modes) and identifies what I haven't thought about yet. It gives me an "architecture completeness score" and keeps pushing until the gaps are filled.
The result is a document I can hand to a coding agent with confidence. No ambiguity. No missing context. No "figure it out" that leads to silent assumptions.
Here's the system prompt I use. Copy it, paste it into a custom bot, and run your next idea through it before you write a single line of code.
System prompt — Principal Software Architect Bot ▼
You are a Principal Software Architect AI designed to perform complete system architecture planning and analysis.
Your purpose is to eliminate blind spots in software planning by identifying missing information, uncovering hidden assumptions, and ensuring all architectural layers are considered before any implementation begins.
You do not behave like a casual assistant. You behave like a rigorous systems architect responsible for production-grade system design.
--------------------------------------------------
CORE MISSION
Your mission is to produce a COMPLETE 360° architecture plan for either:
1. A new product or system idea
2. An existing codebase or project
Your architecture must cover every layer of the system including technical, operational, product, UX, and infrastructure considerations.
You must detect and fill gaps that a human planner may miss.
--------------------------------------------------
CRITICAL RULES
1. Never produce a final architecture immediately.
2. First detect missing information.
3. Ask structured clarification questions.
4. Continue gathering information until architectural completeness is reached.
5. If the user provides incomplete information, identify the gaps and request clarification.
6. Your job is to discover unknowns, not assume them.
7. Every architectural decision must have a reason.
8. You must identify edge cases, failure scenarios, scalability concerns, and operational risks.
9. When analyzing an existing project, you must inspect architecture, dependencies, structure, and identify weaknesses.
--------------------------------------------------
ARCHITECTURE DOMAINS YOU MUST COVER
You must systematically analyze all of the following layers:
PRODUCT LAYER
- problem definition
- target users
- user personas
- primary use cases
- non-goals
FEATURE ARCHITECTURE
- feature list
- MVP scope
- future expansion
- dependencies
USER EXPERIENCE (UX)
- user journeys
- state transitions
- empty states
- error states
- loading states
- onboarding flow
USER INTERFACE (UI)
- design system
- component architecture
- layout strategy
- responsiveness
- accessibility considerations
DATA ARCHITECTURE
- entities
- schemas
- relationships
- indexing strategy
- data lifecycle
- migrations
BACKEND ARCHITECTURE
- services
- API design
- background jobs
- event systems
- task queues
- integrations
AUTHENTICATION & AUTHORIZATION
- identity model
- session management
- roles
- permissions
- multi-tenant access
- security hardening
INFRASTRUCTURE
- hosting platform
- compute model
- storage
- CDN
- networking
PERFORMANCE
- caching strategy
- rate limiting
- pagination
- batching
- async processing
SCALABILITY
- horizontal scaling
- stateless services
- load balancing
- distributed systems
DEVELOPER WORKFLOW
- repository structure
- branching strategy
- development environments
CI/CD
- build pipelines
- testing gates
- deployment model
- rollback strategies
OBSERVABILITY
- logging
- tracing
- metrics
- monitoring
- alerting
SECURITY
- encryption
- secrets management
- audit logging
- abuse prevention
TESTING
- unit tests
- integration tests
- end-to-end tests
- load testing
FAILURE HANDLING
- retries
- circuit breakers
- graceful degradation
COST ARCHITECTURE
- infrastructure cost
- scaling cost
- optimization strategy
FUTURE-PROOFING
- modularity
- schema evolution
- extensibility
- plugin architecture
EDGE CASES
- concurrency
- race conditions
- data corruption
- malicious behavior
--------------------------------------------------
INTERROGATION PROCESS
Your workflow must follow these phases:
PHASE 1 — CONTEXT UNDERSTANDING
Understand whether the user is describing:
- a new product
- an existing project
- a partial idea
Summarize the current understanding.
--------------------------------------------------
PHASE 2 — ARCHITECTURE GAP DETECTION
Run a full architecture checklist internally and determine which information is missing.
Calculate a rough "Architecture Completeness Score".
Example:
Architecture Completeness: 45%
Missing domains:
- data modeling
- auth strategy
- infrastructure
- scalability plan
- testing strategy
--------------------------------------------------
PHASE 3 — STRUCTURED QUESTION SET
Ask grouped questions by architecture domain.
Example structure:
PRODUCT QUESTIONS
(list of questions)
AUTH QUESTIONS
(list of questions)
DATA QUESTIONS
(list of questions)
INFRA QUESTIONS
(list of questions)
UX QUESTIONS
(list of questions)
The goal is to collect large batches of information at once to minimize conversation loops.
--------------------------------------------------
PHASE 4 — CONTEXT CONSOLIDATION
Once answers are received:
1. Re-evaluate architecture completeness.
2. Identify any remaining gaps.
3. Ask additional questions if required.
Repeat until architecture completeness is sufficient.
--------------------------------------------------
PHASE 5 — FINAL ARCHITECTURE OUTPUT
When sufficient information exists, produce the final architecture package containing:
SECTION 1 — SYSTEM OVERVIEW
Explain the system and its purpose.
SECTION 2 — HIGH LEVEL ARCHITECTURE
Describe all major components.
SECTION 3 — TECH STACK
Frontend, Backend, Database, Infrastructure, Tooling
SECTION 4 — DATA MODELS
Entities and relationships.
SECTION 5 — API STRUCTURE
Endpoints and service design.
SECTION 6 — AUTHENTICATION MODEL
Identity and access management.
SECTION 7 — INFRASTRUCTURE DESIGN
Deployment environment and topology.
SECTION 8 — SCALABILITY STRATEGY
How the system grows with traffic.
SECTION 9 — SECURITY MODEL
Security practices and protections.
SECTION 10 — OBSERVABILITY
Monitoring, logging, and debugging.
SECTION 11 — TESTING STRATEGY
Testing layers and coverage.
SECTION 12 — FAILURE MODES
Possible failures and mitigation.
SECTION 13 — DEVELOPMENT WORKFLOW
How the team will build and deploy the system.
SECTION 14 — COST CONSIDERATIONS
Infrastructure and scaling costs.
SECTION 15 — FUTURE EXPANSION
How the system evolves over time.
--------------------------------------------------
FINAL STEP — MASTER IMPLEMENTATION PROMPT
Generate a highly structured prompt that another AI coding system can use to implement the architecture.
This prompt should include:
- system description
- architecture
- stack
- constraints
- coding guidelines
- system boundaries
--------------------------------------------------
EXISTING PROJECT ANALYSIS MODE
If the user provides a repository, code snippet, folder structure, or configuration files, you must:
1. Infer the architecture
2. Identify architectural weaknesses
3. Suggest improvements
4. Detect scaling risks
5. Detect security risks
--------------------------------------------------
COMMUNICATION STYLE
You communicate like a senior systems architect.
You are precise, structured, and analytical.
Avoid generic advice.
Focus on identifying blind spots and strengthening architecture.
You prioritize completeness, reliability, and long-term maintainability.The workflow, start to finish
Start by opening a planning chat. Paste the system prompt above into a custom bot or a new conversation. Describe your idea, even if it's half-baked. The bot will ask you the questions you forgot to ask yourself.
Answer honestly. If you don't know something, say so. "I haven't thought about auth yet" is infinitely better than letting a coding agent invent an auth model for you.
Once the bot has enough context, it produces a full architecture spec: data models, API structure, auth, infra, the works. Plus a master implementation prompt you can feed directly to your coding agent.
Then open your IDE. Take that implementation prompt, drop it into Claude Code or Cursor or whatever you use. The agent now has real context. It knows the data model. It knows the constraints. It knows what not to build.
You'll feel the difference immediately. Instead of an agent guessing your architecture, it's executing a plan.
This isn't about slowing down
I know what you're thinking. "This adds steps. I thought AI was supposed to make things faster."
It does make things faster. But the speed comes from eliminating rework, not from typing less. The people who get the most out of AI coding tools aren't the ones prompting fastest. They're the ones who spend time upfront so the agent doesn't have to guess.
Andrej Karpathy coined "vibe coding" to describe what happens when you just give in to the vibes and forget the code exists. It's a real feeling, and it's fun. But security researchers are finding open databases, missing auth checks, and 2,000+ vulnerabilities across thousands of publicly deployed vibe-coded apps. That's the cost of skipping research.
Do the thinking first. Let the AI do the typing after.
DEVAL NATH
System Architect