Hi, I’m David.
I’m close enough to middle age that I have no interest in pretending I discovered the future of software development in a week.
What I did do was spend one serious week building a small local app with AI assistance, while trying to keep the project understandable.
That turned out to be harder, and more interesting, than I expected.
The coding agent could move quickly. Sometimes very quickly. It could generate code, refactor, write boilerplate, and help move the project forward.
But it could also widen scope, preserve the wrong assumption, “helpfully” redesign something I wanted to keep boring, or act on context that was never meant to become implementation work.
The main lesson I took from that week was simple:
AI-assisted development is not only a coding problem.
It is a context management problem.
So I started using a lightweight loop:
Task Brief -> think through the problem
Codex Contract -> give the coding agent a bounded instruction set
Final Review -> test, inspect, patch, and update project memory
The result was not perfect AI coding.
The result was reviewable AI coding.
That distinction felt important enough to write down.
The three articles
I published three companion articles from that first week.
They are meant to stand on their own, but together they describe the workflow, the memory system, and the objections I think are worth taking seriously.
1. Vibe Coding Done Right
This is the accessible starting point.
It explains how I used a lightweight, spec-driven workflow as a solo developer working with ChatGPT, Codex, VS Code, PowerShell, and a local LLM through LM Studio.
The point is not the exact stack.
The point is the separation:
- one place for thinking, learning, and review;
- another place for bounded implementation;
- documentation as the memory that keeps the next task grounded.
2. Documentation as Project Memory in AI-Assisted Development
This is the more technical case-study piece.
The part that surprised me most was documentation.
Not documentation as a polished manual.
Not documentation as a chore at the end.
Not documentation nobody reads.
Documentation as project memory.
The project used a small set of live documents to preserve architecture, data shapes, API contracts, and technical debt.
Those documents were updated as part of the implementation transaction, not someday after the work.
That gave the next AI-assisted task a cleaner starting point.
3. Defensive AI Engineering: Hardening the Project Memory Loop
This one is for the reasonable skeptics.
Because the obvious criticisms are fair.
Isn’t this just documentation debt?
Why manually pass context around when IDE agents can read the repo?
Can you trust AI to update its own docs?
Does this scale beyond one solo developer building a prototype?
I do not think those questions should be hand-waved away.
The third article is my attempt to stress-test the workflow rather than sell it as a universal answer.
Supporting repo
I also published a small GitHub repo with the supporting files from the case study.
It is not a framework or package.
It is just the artifact trail: project-memory files, example Codex Contracts, and supporting notes from the development sequence.
davidvk89
/
ai-project-memory-loop
A lightweight workflow for using live project documentation as memory in AI-assisted development.
ai-project-memory-loop
Supporting files for a one-week case study in using live project documentation as memory during AI-assisted development.
This repository is not a framework, package, or complete methodology. It is the artifact trail behind three companion articles about keeping AI-assisted development bounded, reviewable, and human-led.
Core idea
AI-assisted development has a context problem.
Coding agents can move quickly, but they only work from the context they are given. A long planning conversation can contain rejected ideas, shorthand, future plans, temporary assumptions, and half-decisions. For a human, that is normal design exploration. For a coding agent, it can become accidental permission.
The workflow documented here uses a lightweight loop:
Task Brief -> explore the problem
Codex Contract -> define the bounded implementation
Final Review -> test, inspect, patch, and update project memory
The project memory files are updated as part of the work, not someday after the work. That gives the…
Why I’m posting this
I am not claiming authority on AI engineering.
I am a guy who spent a week building with AI, ran into context drift almost immediately, and stumbled into a workflow that made the project feel less fragile.
That seemed worth sharing.
Maybe someone else is also trying to use AI coding tools without turning their project into a mysterious pile of files that technically runs but no longer makes sense.
If so, I hope some part of this is useful.
Top comments (0)