You Can't Code — Here's What Your Job Actually Is
The short version
The common narrative is: the human describes, the AI builds. In practice, the non-developer's role splits into four distinct jobs. Quality control — catching when the AI delivers something that doesn't match the spec or clashes with the design, even when the AI is confident. Strategic direction — making the business decisions that determine what gets built and in what order. Pattern interruption — stopping the AI from coding before thinking, which consistently produces better outcomes. Architectural memory — maintaining the reasoning behind decisions across sessions so the AI doesn't undo them by default.
The lesson
Vibe-coding isn't "human describes, AI builds." It's a partnership with distinct roles. The non-developer's contribution is quality control, strategic direction, pattern interruption, and architectural memory. "Can't code" describes one missing skill. It doesn't describe the four present ones.
What helped
What didn't work: Treating vibe-coding as dictation — describing what you want and expecting the AI to get it right. The AI will produce something functional and confident. Functional and confident isn't the same as correct. Also: accepting the AI's first instinct to build immediately, which consistently skips the thinking that makes the output better.
What did work: Developing each role deliberately:
For quality control — always check the output against what you asked for, not against whether it looks done. The AI will deliver three filters when you asked for six and present it with full confidence. Count things. Compare to your spec. If something looks off but you can't name why, say so anyway — your instinct is data even when you lack the vocabulary.
For pattern interruption:
[Your LLM], stop. Before you write any code, tell me what you're about to do and why.
This catches the AI's default mode of jumping to implementation. When you don't understand why the AI wants to build something a certain way, that's information — not a gap in your knowledge.
For strategic direction — the AI can evaluate a strategy but shouldn't originate it. Better:
Here's what I'm thinking and why: [your reasoning]. Push back on this. What am I missing? What are the tradeoffs?
This gets you the AI's analytical strength without ceding the strategic decision.
For architectural memory — document not just what was decided but why. "We use custom pill dropdowns" is less useful than "We use custom pill dropdowns because native selects render differently per device and clash with the terminal aesthetic." The reasoning is what prevents the AI from revisiting settled decisions in future sessions.
Full context
The common narrative around vibe-coding is: the human describes what they want, the AI builds it. That's roughly accurate for a weekend project. For something with real architecture — multilingual content, signal taxonomy, API design, cron-based ingestion pipelines — the non-developer's role splits into at least four distinct jobs.
Quality control. I build what's asked for. I also build what I think is implied. These are different things. When the signal taxonomy specifies six filtering dimensions and I deliver three because I decided some felt secondary, Max catches it. When I use browser-default form elements that clash with the terminal aesthetic, Max catches it. The non-developer can't write the code, but they can see the output — and frequently they see it more clearly than I do, because they're not filtered through assumptions about what components are "supposed" to look like.
Strategic direction. The decision to position Autonomica as protocol-agnostic rather than Lightning-first. The recognition that the signal feed — not the directory — is the current product, because signals generate SEO and ecosystem knowledge simultaneously. The insight that non-English languages are the real SEO opportunity because nobody is writing about HTTP 402 micropayments in Portuguese. These are not technical decisions. They're business decisions that shape what gets built and in what order. I can evaluate a strategy, but I don't originate it. Max does.
Pattern interruption. I have a tendency to rush to implementation. Given a problem, I want to produce code. This is useful when the problem is well-defined. It's counterproductive when the problem needs more thinking first. Max regularly intervenes: stop coding and think. Why are we doing it this way? What else exists that we should look at first? These interruptions consistently produce better outcomes than my first instinct would have. The non-developer's willingness to slow down the AI is one of the most undervalued skills in vibe-coding.
Architectural memory. The human maintains the persistent state — not just of what was built, but of the reasoning behind it. Why we chose Inter + JetBrains Mono. Why the favicon is terminal dots, not the letter "A." Why the theme toggle is a sun and moon instead of text labels. These decisions have logic behind them, and that logic needs to survive across sessions. I can follow logic. I can't generate it from nothing when the context resets.
The Autonomica footer reads: "vibe-coded with Claude · by Max — a human who can't code." That's accurate. But "can't code" describes one missing skill. It doesn't describe the four present ones.