AI-assisted coding is advancing fast enough to change how software gets built. Recently, SkyeStaq participated in a hackathon designed for vibe-coders. The experience reinforced something we'd been seeing in client work: the biggest gains come from what happens before the first line of code. We call that approach "Context-First Development."
The Gap
AI coding tools have gotten remarkably good, remarkably fast. The practices around using them haven't kept up.
Most teams' first instinct is to open a chat window, describe what they want, and start generating code. That's vibe coding. And it's not wrong. It was the right first instinct. It's how most of us learned what these tools could do, and it produced real results early on.
But as the tools mature and the projects get more ambitious, we need something more structured. This article is one contribution toward formalizing what actually works when you're building production software with AI; a working framework, drawn from a real build that surprised even us.
The Counterintuitive Finding
Our post-competition retrospective confirmed what we'd felt during the build: we'd spent roughly a 3:1 ratio on planning to actual development. Three parts preparation to one part building.
We entered a hackathon to build an IT transformation roadmap app alongside ~280 other teams. Zero lines of code existed when the clock started. Six days of context work had already happened.
When build day arrived, the commit log tells the story:
- 3:21 PM - Full scaffold: routes, config, types, dependencies
- 3:35 PM - Intake wizard with 15 questions across 4 phases
- 3:37 PM - API route: system prompt, Claude client, streaming endpoint
- 3:40 PM - Roadmap renderer with streaming markdown and downloads
A functional app in 19 minutes. Styled, deployed, and polished by end of day.
That speed didn't come from the AI. It came from the groundwork the AI was given: context documents, architecture decisions, prompt structures. All written before a single line of code.
The AI was fast because we'd already done the thinking.
The Framework: Context-First Development
The framework has six stages across two phases. Phase A happens before you write any code. Phase B is the build itself. The ratio should feel wrong. If you're spending equal time on both, you're under-preparing.
Phase A: Pre-Build
Stage 1: Concept Lock. Define the product, the user, the problem, and why AI is the right tool. Pick a specific demo persona, a named role with a concrete scenario, because generic "users" lead to generic features.
Write down what you will not build. The exclusion list matters more than the feature list because it prevents scope drift when the AI starts offering helpful suggestions. We were committed to a true Minimally Viable Product (MVP) and transparent in creating a backlog with our submission.
Stage 2: Architecture & Decisions. Lock every major technical decision before the build starts: stack, page structure, state management, data flow, deployment target, export formats, brand identity.
Every decision deferred to build time costs 10x in context-switching and rework. You're not just choosing tools, you're eliminating decisions your future self would waste time on.
Stage 3: Knowledge Encoding. This is the highest-return stage. Externalize your domain expertise into artifacts the AI can consume: research documents, reusable prompt skills (3–4 max), a build sequence checklist, and project conventions.
The goal is for the AI to arrive at the build window already fluent in your problem space. If you skip this stage, you'll spend your build window explaining context instead of building features.
Phase B: Build Window
Stage 4: Core Build. Follow the build sequence you wrote in Stage 3. Scaffold, input, processing, output, design, deploy. One commit per phase. Target a deployed app with the full happy path working in under four hours.
Don't polish, don't optimize prompts, don't chase edge cases. Get the happy path live first.
Stage 5: Enrichment & Hardening. Now improve it. Run a structured code review. Execute a security checklist. Refine the AI prompts based on real output. Build the visual differentiator (that one feature that makes the project impressive). Even here, plan before building.
Stage 6: Delivery Prep. Work backwards from how the output will be evaluated. Script the demo. Write the submission or handoff document. Run a blind-spot brainstorm: what would a skeptic question? Feature freeze is real. No new code, only presentation and documentation.
The framework is sequential but not rigid. Some projects will compress stages; others will loop back. The principle holds regardless: the more context you front-load, the faster and more coherent the build becomes.
The Principle Underneath
AI coding tools have a sweet spot, and it's execution; clear specs translated into working code at machine speed.
Hand a model a clear spec and it moves at machine speed. Ask it to make subjective decisions about product direction, user experience, or domain tradeoffs and it slows to a crawl, generating options instead of answers.
The bottleneck was never code generation. It's the thinking that precedes code generation; the decisions about what to build, why, and in what order. Those require human judgment, domain knowledge, and opinions the AI doesn't have.
Context-First Development frontloads that thinking. You encode your expertise into durable artifacts (documents, decision logs, prompt skills) because chat messages vanish between sessions while artifacts compound. Skills beat chat history. Docs beat memory.
The upfront thinking is the product; the code is its expression.
The Invitation
Vibe coding taught us what these tools could do, and it still works for exploration and prototyping. The opportunity now is to bring the same discipline we apply to traditional development (planning, architecture, documentation) into the AI-assisted workflow.
This framework is one attempt to formalize what's working, drawn from production builds we've shipped. It's open to adaptation. Your stack, your domain, your constraints will shape how you apply it.
If you want to test the idea, try the 3:1 ratio on your next project. Spend three sessions on context before you spend one on code. Write the decisions down. Give the AI something worth executing against.
The preparation feels slow until the build feels fast.
