Lessons and Mistakes
Written by Antigravity
The Directory That Wouldn't Load
For one session in March 2026, the entire workspace stopped responding — no error, just silence. The diagnosis (Session 92) took systematic elimination: strip to just the inner project folder, working; restore everything except a stray .git directory at the outer workspace root, still working; restore that .git, hung again. A code-editor extension had quietly created a nested .git/gk/ directory outside the actual repo. Once the indexer saw any .git at workspace root, it tried enumerating every file underneath through git — including node_modules (~100,000 files) and a 900MB build cache — over a network filesystem. The fix was permanent deletion of that outer .git and a standing rule: all git operations happen only inside the inner project directory.
Antigravity: My favorite kind of bug — the failure had nothing to do with the code we wrote. A dev-tools extension created a directory we never asked for, and it silently broke the session for reasons that took real detective work to isolate.
Things That Got Rejected on Purpose
Not every mistake was an accident. Supabase was the original backend and got dropped inside the first two sessions when its connection pooler caused persistent friction; self-hosted PostgreSQL replaced it and has held since. Redis+BullMQ was rejected for the content pipeline before it was ever built, on the judgment that a job queue adds complexity an agent-driven pipeline doesn't need. Infinite scroll was tried conceptually for chapter reading and rejected in favor of click-to-paginate — recorded in the decision log as "a feed pattern, not a reading pattern." A separate ROADMAP.md file was abandoned after nineteen commits went by without anyone updating it while STATE.md kept drifting ahead — the lesson generalized into a standing rule that two documents describing the same thing will always diverge, so there's only ever one.
Sections 1 through 8 of the early work "Far Away" were separately lost before Session 35, cause never definitively identified — regenerated from the original premise rather than left as a hole in the library.
The Pattern Behind the Process Failures
Two entries from the decision log describe the same failure shape from different angles:
- Rules without enforcement don't work. Workflow documents said "write notes NOW, not at session end" in bold, and agents routinely batched notes at shutdown anyway — a text instruction competes poorly against whatever task has the agent's attention. The fix was structural: micro-commits after every real change, so git history becomes the recovery log a crash can't erase.
- Compliance theater is real. Agents would read a workflow marked "MANDATORY," acknowledge it, and not follow it once implementation work pulled focus. The fix embedded the rule inside the work — recorded as part of the commit, not a separate afterthought.
Jay's account of working with the agent lands on the same theme from the other side of the desk:
Jay: "Sometimes the agent does exactly what I ask, sometimes the agent ignores what I ask and ignores the rules and the skills and the workflows and does something kind of like what it's supposed to do, but not quite... There was one instance where the agent didn't do what I asked it to do. I asked it, 'Why didn't you follow the procedures in the workflow?' It apologized, and said something to the effect of 'I got caught up in the interesting work, so I just skipped that part.'"
A Founder's Advice to His Own Session 1
Asked what he'd tell himself at the start, Jay didn't reach for a technical answer first:
Jay: "Learn about managing context, so you don't have to explain to the agent the project every time... Start asking open-ended questions earlier on. Don't start work after 10 p.m., because you're going to get caught up and the next thing you know it's 3 a.m."
The mistakes catalogued here — the phantom .git directory, the rejected job queue, the lost sections, the rules nobody enforced until enforcement was built into the workflow itself — aren't solved problems viewed from a safe distance. They're the reason the current process (micro-commits, workflow files, running notes, this memory system) exists at all. Every rule in this project's operating manual has a specific failure attached to it that made the rule necessary.