GenAI Development - From Vibe Coding to APM
Version 3 · Last Updated 2026 May 24
It has been updated as my thinking changed. See the Changelog at the bottom for what shifted and when.
Core Idea
GenAI is not a faster way to write code. It is a new type of resource that requires management. The developer’s role shifts from directly producing code to defining intent, structuring work, and validating outputs. I call this working model Agentic Project Management (APM).
State of Thinking
Most discourse around GenAI development is still at the surface — speed, novelty, prompt tricks. The deeper problem is control and coherence over time.
Vibe coding is appealing because it is fast and feels productive. But it drifts. Each prompt builds on the last without a system holding it together. The longer the project runs, the harder it becomes to understand why decisions were made and how to change them safely.
APM is my response to that. Instead of prompting reactively, I treat GenAI like a contributor I am managing: I define the task, set the constraints, review the output, and decide what to do with it. Generation is cheap. The real work is knowing what to ask for and whether the output is actually right.
Running this through SG StoryQuest confirmed the model — but also made the friction concrete. Small bounded tasks produce reliable outputs. Large vague prompts produce drift. The quality of the output is almost entirely a function of how well I defined the task, not how capable the model is.
The biggest unsolved problem is still context. GenAI does not hold system state reliably across sessions. I end up re-establishing context repeatedly, and no part of the current workflow resolves this well.
Thinking Trace
Started from frustration with vibe coding discourse. Everyone was talking about speed. No one was talking about what happens when the system grows and you can’t trace why it is the way it is.
The mental model formed before I had a project to test it on. The reasoning was intuitive: if GenAI is going to produce work I depend on, I need to manage it like any other contributor — with defined tasks, clear constraints, and real review. Prompting as exploration felt like the wrong instinct.
SG StoryQuest was the first real test. Simple enough to build, structured enough to expose where the workflow breaks down. What it showed: the pattern holds, but context fragmentation is a genuine problem that the mental model doesn’t yet solve. Re-injecting context every session is friction that compounds.
What changed?
v2
The model moved from theoretical to tested. Before SG StoryQuest, APM was a reasoning-based position. After it, the core holds but a real limitation surfaced — context management is not a minor inconvenience, it is a structural gap.
Why it changed?
v2
Implementation reveals things ideation cannot. The belief was right in direction but underestimated the operational cost of statelessness across sessions.
Evidence / Signals
- Small, scoped tasks produce noticeably more consistent outputs than open-ended prompts
- SG StoryQuest exposed how quickly coherence breaks down without task structure
- Reusing context across sessions requires constant re-injection — no tooling solves this well yet
Open Questions
- What is the right task granularity for delegation — where does it stop being worth it?
- Can tooling eventually solve context fragmentation, or is it a fundamental constraint?
- At what project scale does APM stop working without more formal agent structure?
Connections
- Applied in SG StoryQuest - Thinking
- Evolved into GenAI Development - From APM to OpenSpec
Changelog
- v3 — Added connection to evolved node; thinking arc on this node is now complete
- v2 — Tested through SG StoryQuest; core model confirmed, context fragmentation surfaced as structural gap
- v1 — Initial node