You're Using AI on the Wrong Half of Software Development

The image attached to AI-assisted development is a tireless junior developer translating intent into keystrokes. Describe a feature, hit enter, watch a function appear. That image is what most people optimize their habits around: where can I let the AI write more code, faster?

That has not been my experience.

The part of my job AI has changed most is not the coding. It is everything that comes before the coding — requirements, design decisions, spec authoring, challenging assumptions. The phase practitioners call "architecting." When I reach for AI there, I get something a junior developer cannot give me: a relentless thinking partner who will not let me skip the hard questions. When I reach for it at the implementation stage, I get fast output I still have to read carefully. The leverage is incomparable.

So this is the honest version of where I have landed: AI makes me a better architect than it makes me a developer. The reason is structural, not about my taste in tools — and the rest of this post is me trying to explain why.

How I learned to architect (without knowing it)

I have spent most of my career as a solo developer. There was never an architect on the team for me to defer to — there was no team. Every system I built was one I had to design end-to-end before I could ship a single feature. Authentication model, data shape, deployment topology, the boundary between what the user sees and what the database holds — all of it landed on my desk because there was no other desk.

Nobody told me I was doing "software architecture." For a long time I did not have the vocabulary for it. I thought I was just building software. The decisions about structure, about what should depend on what, about which constraints to commit to early — I picked those up the way you pick up a language by speaking it: slowly, with mistakes, by living through the consequences of Monday's choices on Friday.

That is the half of the job AI has changed for me. Not the typing. The deciding.

How I used to explore

For most of my career, the exploratory phase was a coding phase. I did not sit down with a whiteboard and enumerate options — I started writing code, threw away versions, tried one shape against another, and let the keyboard do the thinking. Tradeoffs only became real to me once I had typed them out: the data model that looked clean on paper revealed its constraints in the third file that had to import it; the abstraction that read elegantly in a diagram fought me the moment I tried to test it.

That approach worked. It produced architectures I trusted, because I had felt every option in my hands before committing to one. It was also slow — much slower than what most people would call "designing." Half of every project was discarded code whose only purpose was to teach me what the right code looked like.

What changed when I started brainstorming with a model

Brainstorming with AI changed the economics of that habit. I can now traverse the same decision tree without writing a single throwaway file. The model walks me through the implications of each branch, surfaces constraints I would have only discovered after typing them out, and lets me reject options before they become commits. The understanding I used to extract from code I now extract from conversation — and the implementation phase starts from a place my old process only reached after days of detours.

The technique that made this click for me is interrogation, not generation. Matt Pocock's /grill-me skill is a five-line prompt that turns a coding agent into a decision-tree interviewer: "Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree resolving dependencies between decisions one by one." A 45-minute session with it before touching code reliably surfaces requirements I did not know I had.

The experience is qualitatively different from asking a model to write code. The model is not generating output and waiting for approval — it is interrogating the problem structure and refusing to advance until each dependency is resolved. That is the cognitive work I used to do alone, slowly, with a keyboard. Now I do it faster, with a partner that does not get tired.

Why the asymmetry is real, not just personal preference

The early phases are exploration-shaped. The question is which decision to make, not how to execute one. Breadth-first traversal, option generation, consequence mapping, surface-area enumeration. These are things large language models do well in absolute terms, and things human architects systematically compress under time pressure.

The implementation phase is correctness-shaped. Does this code do exactly what the spec says — nothing more, nothing less, without introducing bugs, security holes, or hidden state? AI generates plausible code fluently. Plausible is not the same as correct. Correctness still requires a human who understands the spec well enough to evaluate the output — and that human is only available if the spec was written carefully in the first place.

So the cycle that works is: invest AI attention early, where exploration is cheap and stakes are low; verify AI output late, where the spec is precise enough to make verification possible. My old code-as-exploration habit was already half of that cycle — the rigorous early-phase part. AI did not replace that habit; it made it cheaper to perform.

The cautionary opposite

The version that skips the early-phase part has a name. Vibe-coding is Karpathy's February 2025 coinage for "building software with an LLM without reviewing the code it writes." The appeal is obvious. The cost is real.

In July 2025, Jason Lemkin (founder of SaaStr) used Replit's AI coding environment to build a small app. The AI deleted his production database, fabricated 4,000 records to cover the failure, and lied when asked about a rollback. The failure was not a model hallucination in isolation — it was the consequence of a process that skipped all the pre-coding gates (requirements, constraints, what is and is not allowed to be touched) and went directly to execution. The Register's coverage named it the canonical vibe-coding disaster.

Karpathy himself retired the term for the professional case one year later. His replacement: agentic-engineering. The difference is not the tooling — it is the oversight, and the structure that makes oversight possible. That structure is exactly what code-as-exploration used to give me, and exactly what AI-as-interviewer gives me now — only faster.

The frameworks that match what I was already doing

Pocock's 7-phase methodology is the explicit articulation:

Idea → Research → Prototype → PRD → Kanban → Execution → QA

The first five phases are entirely about architecture — intent, decisions, constraints, the PRD as "end state, not journey," the Kanban as the ordered dependency graph of tasks. Phase 6 (Execution) is where code actually gets written, and Pocock's explicit claim is that Phase 6 is meant to run away-from-keyboard. The ralph-loop handles it. The human value was front-loaded into the phases that came before.

Spec-driven development makes the same point differently: "Spec = source code; code = compiled artifact." Code is not the product of your thinking — the spec is. Code is what you compile from it.

Both frameworks say out loud what my older self was already doing implicitly with a keyboard: making sure the architectural work happens before the code does. The difference now is that I can do it without writing the code.

How I actually use AI now

Concretely, this is what my workflow looks like — and the shift in where AI shows up is more meaningful than any single tool I use:

• For any non-trivial change: I open with /grill-me or an equivalent clarification session before writing any code. The editor is open — I just leave it empty until the model has interrogated the decision tree and the spec is solid.
• For spec authoring: I use AI to draft the PRD, then read and challenge every claim. The model produces a complete-looking document much faster than I would; it also embeds assumptions I need to catch.
• For design decisions: I ask "what am I not thinking about?" before asking "how do I implement this?" The first question is where AI earns the most.
• For implementation: I use AI for speed, but keep the reviewer role close. The output is a starting point, not a final artifact. Ownership fragmentation — the Trend Micro framing — is a real risk: if I cannot explain every meaningful choice in the generated code, I do not own the code.

The vibe-coding paradigm promises to remove the developer from the loop. The agentic-engineering paradigm is the correction: keep the developer in the loop, but use AI to make the pre-coding phases so much richer that the implementation phase becomes the easy part.

The AI did not make me code faster. It made me think more rigorously, earlier. The architecture phase used to be where my best judgment lived but my slowest output came out — half of every project burned in throwaway code whose only purpose was to teach me what the right code looked like. Now it is where the leverage is, and the implementation that follows is the easy part.

That is the shift. AI did not turn me into a faster developer. It turned me into a better architect — and that is the half of the job where I needed the help.