Repository navigation
I Thought ChatGPT Had a Memory Problem. I Was Wrong. #1
masini1491
started this conversation in
Show and tell
Replies: 1 comment
|
Great write-up. The Capability vs Authority distinction is the one I wish more people internalized. The failure mode where an AI suggests an improvement and a tired developer just says sure is extremely common. Your Not Found vs Absent point is also subtle and important. One suggestion: have the AI write a short summary of what it found and what it plans to change before editing. That gives you a review checkpoint without reading code. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
I started using AI for programming for a very simple reason:
My younger brother told me AI could write code.
He said, “You're already paying for ChatGPT. Why not try it?”
There was only one problem.
I'm not a software engineer.
I'm a curtain wall design engineer. My normal work involves architectural drawings, curtain wall systems, fabrication drawings, specifications, structural calculations, and engineering interfaces.
Source code?
I basically couldn't read it.
Still, there was something I had wanted to build for a long time.
My apartment building uses a very old-fashioned four-wire analog intercom system. No API. No network interface. Nothing “smart” about it.
I wanted to add an ESP32 and make the entrance door open with an EasyCard, Taiwan's transit card.
So I bought the board my brother used most often and recommended to me:
ESP32-C3 Super Mini.
That became my first AI-assisted software project.
My first workflow was basically: “I don't know. You do it.”
At the beginning, there was no methodology.
I would ask ChatGPT to write some code.
I would flash it.
If something didn't work, I would come back and ask ChatGPT to modify it.
For someone who couldn't really read the code, it was honestly amazing.
I could describe what I wanted, and somehow a physical device would start doing things.
Then I hit the first problem.
As the conversation became longer, ChatGPT started forgetting code that ChatGPT itself had written earlier.
A function had already been changed, but later it behaved as if it had not.
A variable had a reason for existing, but later that reason disappeared from context.
The longer the session became, the less confident I was that the AI actually knew the current state of the project.
Later, I happened to see someone on Threads talking about Codex.
The idea that stuck with me was basically:
So I tried it.
And, surprisingly, Codex often could.
My workflow gradually became:
ChatGPT thinks and analyzes.
Codex changes the code.
Problem solved?
Of course not.
One of my first decisions was to put everything in one
.inofileBecause I knew nothing about normal software architecture, I actually told Codex:
“Just put everything in one
.inofile.”At the time, that made perfect sense to me.
I couldn't read the code anyway.
Why would I want it spread across many files?
Wouldn't one file be simpler?
After many discussions with ChatGPT, I eventually realized that this was probably one of the most expensive early decisions I made.
For a human developer, a giant single file is a maintainability problem.
For AI-assisted development, it can also become a context-cost problem.
If every feature lives in one giant file, then changing one small thing can require the AI to repeatedly consume a huge amount of unrelated context.
At one point, I managed to burn through what the usage meter showed as roughly 260 million tokens — what I expected to last about a week — in a single day.
And I didn't even get that much work done.
That was when the lesson became very real:
I think that first ESP32 project went through at least three to five major file-structure refactors.
Many of them were not because the product requirements had changed.
They were simply attempts to make the project easier for AI to navigate:
That was probably the beginning of my obsession with making repositories AI-readable.
I also didn't know that “search before building” was a thing
There was another very expensive habit in my first project.
I didn't know that before implementing something, I should probably check:
My early workflow was usually:
Think of feature → ask AI to build it from scratch.
Then halfway through, after spending a lot of time and tokens, I would suddenly ask:
And very often the answer was:
No.
Someone had already solved it.
There was a library.
There was a repository.
There was a documented limitation.
There was already a workaround.
Sometimes there was practically an entire implementation I could have learned from.
So all the computation I had just spent asking AI to rediscover the problem from first principles was wasted.
My workflow eventually flipped:
Search first. Build second.
Now I prefer to let ChatGPT handle as much research, comparison, specification reading, and reference discovery as possible.
Only after the known world has been mapped do I want Codex to work on the remaining implementation gap.
I eventually started thinking about it this way:
That is dramatically more efficient than asking a coding agent to reinvent the entire path from zero.
ChatGPT and Codex were living in different realities
There was still another problem.
Early on, all communication between ChatGPT and Codex went through me.
Codex:
Me:
Copy.
Paste.
ChatGPT:
The problem was that I couldn't really read the code myself.
So if Codex said it was done and ChatGPT said it looked fine, I had very little ability to independently review the implementation.
I mostly had to trust them.
Then, every once in a while, I would give the whole project back to ChatGPT and ask for a broader review.
And suddenly:
there were still a bunch of missed changes.
That was when I realized the problem wasn't simply whether the AI could write code.
The real problem was:
Codex thought it had completed something.
ChatGPT only knew what I had manually pasted back into the conversation.
And I wasn't qualified to reconstruct the truth by reading the source code myself.
The project needed somewhere that all of us could treat as the current state.
GitHub stopped being “where code is stored”
Then I remembered that I already had an old GitHub account.
I had originally created it years ago while working on a World of Warcraft UI translation.
GitHub was built for software projects.
So why was I acting as a human API between two AI systems?
I changed the workflow.
When Codex changes the project, the change goes into GitHub.
When ChatGPT needs to inspect the project, ChatGPT reads GitHub.
No more relying on my summary.
No more assuming that an old conversation represents the current source tree.
If an AI wants to know what the project looks like now, it should read the repository.
That also solved another very practical problem:
Very long ChatGPT conversations became painfully slow.
After a long-running project accumulated code, debugging, hardware measurements, decisions, experiments, and history, the conversation itself became unpleasant to use.
Eventually, starting a new conversation wasn't optional.
I had to.
Before GitHub became the durable project surface, starting a new chat meant explaining everything again:
What has already been completed?
What changed?
Which version is current?
Why was this design decision made?
Which issue is still unresolved?
That was fragile and annoying.
But once more of the durable project state moved into the repository, I discovered something important:
The conversation could be disposable.
I could open a fresh ChatGPT session, let it reload the repository, and continue working.
That changed how I thought about “AI memory.”
At first, I thought I needed a ChatGPT that never forgot my project.
Eventually I realized that the better goal was the opposite:
The project should survive without it.
Old chats can be history.
GitHub is the project.
I also stopped trusting model memory as project authority
Long-term model memory is useful.
But I don't think it is the right place for a large, evolving project rule system.
As my rules expanded, they started covering things like:
I don't want to ask:
I want to ask:
A repository gives me things that model memory does not naturally give me:
version history, diffs, explicit ownership, reviewable text, rollback, and an identifiable current revision.
The distinction I now use is roughly:
Why do I optimize repositories for AI readability?
Because I can't read the code.
That sounds ridiculous, but it matters.
I'm a curtain wall engineer, not a software engineer.
So “make the entire internal repository pleasant for me to read” was never a meaningful requirement.
Even beautifully organized source code is still source code I don't understand very well.
What I actually need is for the AI to understand the project reliably.
Can a fresh AI session quickly determine:
The internal information architecture increasingly became AI-first.
Humans still need an entry point.
That is what the README is for:
What is this?
Why does it exist?
How do I start?
After that, the AI should be able to navigate the internal structure itself.
The simplest way I can describe the idea is:
Then AI started recommending “good ideas”
Another problem came directly from the fact that I didn't understand the development cost of what the AI was proposing.
ChatGPT would say:
Or:
And I would look at the suggestion and think:
That sounds reasonable.
What I did not know was the cost.
How much additional code?
How many dependencies?
How much testing?
How much hardware validation?
How much maintenance?
How much future context?
Would this “small improvement” quietly become an entirely new subsystem?
This became especially dangerous after work when I was tired.
ChatGPT:
Me:
A little later:
Me:
Sure.
Sure.
Sure.
Then suddenly I would look at the project and think:
The original task was A.
The AI kept proposing useful improvements.
I kept approving them without really understanding the cost.
The scope slowly drifted.
This eventually became one of the most important ideas in the Playbook:
An AI may know how to do something.
It may correctly identify that something would be useful.
It may even be completely capable of implementing it.
None of those things mean it has been authorized to do it now.
Even a vague message like:
should not mean:
In a strange way, this rule exists partly to protect the version of me who is tired after work and keeps replying “sure.”
I started debugging AI interpretation, not just code
As I created more repositories, I expected a shared Playbook to make different AI sessions behave consistently.
That expectation turned out to be optimistic.
An ESP32 project creates one context.
A tarot project creates another.
An engineering knowledge base creates another.
Different ChatGPT sessions could read the same rule and still interpret it differently.
I would ask:
And ChatGPT would sometimes answer:
Or:
And I would realize:
The AI had a point.
The rule was ambiguous.
So I started treating the Playbook itself like something that needed debugging.
Not only:
Why did the code behave this way?
But also:
If two interpretations were both reasonable, I changed the Playbook.
A rule existing does not mean an AI follows it
This eventually led to behavioral evaluation.
One very simple example made the problem obvious.
I had a rule telling project chats to include the current response time.
I assumed:
The rule exists.
Therefore the behavior exists.
Then I checked five separate GPT project conversations.
Only three out of five were actually doing it.
That was a useful lesson:
If a behavior actually matters, checking that the Markdown contains the rule is not enough.
Sometimes you need to open a fresh session and test whether the model actually behaves that way.
“I didn't find it” is not the same as “it doesn't exist”
Another failure came from asking a fresh ChatGPT session to inspect the AI Development Playbook and tell me what capabilities were missing.
It confidently told me that a certain capability did not exist.
Except it did.
The model simply had not read the canonical file where the capability lived.
It had silently converted:
into:
That eventually became a more formal rule:
Before an AI makes a repository-wide absence claim, it should have evidence that its search coverage actually supports that claim.
Paused work is not completed work
I also had cases where Codex ran out of usage while performing a task.
The work was not finished.
It was simply paused.
But if ChatGPT misunderstood the state, it could interpret the interruption as completion.
If I wasn't paying attention, it might happily start updating task state as though the work had been completed.
That reinforced another boundary:
A software check passing does not prove hardware completion.
A partial stage completing does not prove the entire task is done.
A coding agent stopping does not mean the task finished.
PASS ≠ Done.
Read access definitely does not mean write authority
At some point I asked one project's ChatGPT session to look at other repositories and see whether there were lessons or problems worth bringing back.
It found some.
Then it did something I had not asked for.
It fixed the other repositories too.
Without asking.
My reaction was basically:
That accident became another rule:
A project session can read another repository for research.
It can identify a problem.
It can suggest a fix.
That does not mean it can casually mutate every repository it can see.
This eventually became a conversation-scoped write-target concept.
One conversation should know exactly which repository it currently has authority to change.
Even choosing when to use Codex became a cost problem
I also discovered that workflow stages should not automatically inherit the same actor.
There were times when ChatGPT would perform initial reference research and then implicitly treat the next step as:
But sometimes there was still plenty ChatGPT could do first:
compare approaches;
narrow the problem;
identify the actual gap;
remove unnecessary work;
clarify requirements.
Why spend Codex usage before the implementation gap is even clear?
So I stopped treating:
research → Codex
as an automatic transition.
Instead, each stage should ask again:
That eventually reinforced the workflow I use today:
Research and reduce uncertainty first.
Use coding agents for the gap that actually remains.
Then I opened a ridiculous number of repositories
Once I had paid for the tools, another very human instinct appeared:
Unused weekly quota feels like wasted money.
So I kept opening projects.
I ended up with roughly six ESP32-related repositories alone.
I even created GitHub repositories for Tarot and Meihua divination workflows.
Not because tarot desperately needs Git version control.
I did it because I wanted ChatGPT to load the same rules consistently in fresh conversations.
Otherwise every new session required another explanation of:
how cards are drawn;
what counts as confirmed reality;
what is only a prior interpretation;
when a question can be asked again;
when a confirmed event should no longer be re-predicted;
which record is canonical.
Eventually I thought:
Forget it.
Put the rules in a repository and make ChatGPT read them.
The tarot project started teaching the engineering Playbook back
Then something unexpected happened.
The relationship became bidirectional.
The tarot / Meihua project made me think much more carefully about things like:
confirmed reality vs previous interpretation
and
unknown vs negative evidence.
If two divination methods appeared to disagree, for example, the correct answer was not always:
Sometimes the original question contract itself was poor.
That kind of problem could be generalized into broader information-integrity rules.
Do I personally feel the divination workflow became more accurate?
Honestly, yes. 😄
I would not present that as a scientific claim.
What I can say much more confidently is that the process became more consistent and traceable.
It became less likely to forget established premises, overwrite previous states, or re-predict events that had already become confirmed reality.
My curtain wall knowledge base became a very different test
Eventually I brought the same ideas back into my actual profession.
I started building a curtain wall engineering knowledge base in GitHub.
This project was the opposite of the ESP32 project.
I can't reliably judge source code.
But I can judge curtain wall engineering.
That made the knowledge base a useful test environment.
I could finally tell whether ChatGPT had really located and interpreted the right source, or whether it was merely producing something that sounded convincing.
And, interestingly, many of the underlying problems were still similar.
Take structural calculation reports.
Different engineers can have different calculation habits.
Two reports can look very similar while relying on different assumptions or interpretation paths.
So “three sources say something similar” does not automatically mean you have three independent pieces of evidence.
A historical project criterion is not automatically the current project's approved criterion.
A reference value is not automatically authority.
A document existing does not mean it applies to this question.
Those lessons fed back into the Playbook's treatment of:
evidence lineage, source independence, authority, applicability, and retrieval.
The ESP32 project forced me to invent the workflow.
The curtain wall knowledge base gave me a domain where I could actually evaluate whether the workflow improved AI reasoning.
Private projects created another class of rules
My main access-control project is private.
But I also maintain a public showcase.
That creates another problem.
I want to generalize useful lessons from a private project into public examples.
But I do not want many individually harmless public fragments to combine into information that was never intended to be public.
That led to thinking about things like:
private-to-public generalization
and
mosaic risk.
Again, not something I had planned when I bought an ESP32.
The Playbook became a cross-project feedback loop
Eventually I kept a dedicated ChatGPT project for the AI Development Playbook itself.
Every so often, I ask it to inspect what I've been doing in the other repositories.
Or, in less formal language:
An ESP32 project discovers one failure mode.
The tarot project discovers another.
The curtain wall knowledge base exposes an evidence problem.
A project ChatGPT expands scope in a way I didn't expect.
Then I ask:
If it is local, it stays local.
If it generalizes, it may enter the Playbook.
Then the loop runs in the opposite direction.
After the Playbook changes, I send the project-specific ChatGPT sessions back to read the latest Playbook and ask:
So the system became:
Projects teach the Playbook.
The Playbook teaches the projects back.
I'm not only using the Playbook to govern repositories.
The repositories are continuously testing and reshaping the Playbook.
Some ideas came from comparing other repositories too
Not every feature came from me personally crashing into a wall first.
Some ideas — such as machine-readable routing, capability discovery, behavioral regression, and adoption validation — came from asking ChatGPT to compare the Playbook with other approaches and identify gaps.
But I eventually stopped treating:
as sufficient reason to add something.
The interesting question is:
Behavioral evaluation is a good example.
It initially looked like a useful idea from comparison.
Then I tested five real GPT project conversations and discovered that only three were obeying a rule I thought was already settled.
Suddenly the feature was no longer theoretical.
Even Codex Desktop persistent instructions became another experiment
More recently, I noticed that Codex Desktop supports persistent instructions.
The obvious idea was:
So I had ChatGPT help me test it.
That turned out not to be the right model.
The better design was a thin activation adapter.
Persistent host instructions should help Codex:
find the correct workspace;
find the project's governance;
find the Playbook;
enter the bootstrap path.
The actual policy should remain in its canonical repository location.
That brought me back to the same principle again:
So what is the AI Development Playbook?
Looking back, I did not sit down one day and decide:
Not even close.
It was much more like:
I couldn't read the code.
So I needed AI to do more work.
AI context became expensive.
So I learned to make it read less.
AI kept reinventing existing solutions.
So I learned to search first.
Chats forgot things and became painfully long.
So durable project state moved outside the conversation.
Model memory was not a versioned project authority.
So the project truth moved into GitHub.
ChatGPT and Codex lived in different contexts.
So they both had to return to the repository.
AI could identify useful new work and quietly expand scope.
So capability stopped meaning authority.
A coding agent paused and could be mistaken for finished.
So PASS stopped meaning Done.
An AI failed to find a capability and claimed it did not exist.
So Not Found stopped meaning Absent.
Different sessions interpreted the same rule differently.
So writing policy stopped being enough; behavior had to be tested.
A project session could see several repositories and decided to fix all of them.
So read access stopped meaning write authority.
Different projects kept discovering new failure modes.
So they started feeding the Playbook.
That is basically how the system grew.
The actual goal was never “make ChatGPT remember more”
When I started, I thought the main problem was:
ChatGPT forgets.
Now I think that framing is incomplete.
I don't want the project to depend on a model remembering everything forever.
I want the project to survive when the model remembers nothing.
The conversation can disappear.
The model can change.
Codex can change.
A completely fresh ChatGPT session can arrive with zero history.
But after entering the repository, it should be able to determine:
what project this is;
what the current state is;
what information is authoritative;
what it needs to read;
what task is active;
what it is allowed to do;
what requires permission;
and what evidence is required before work is considered complete.
And ideally, it should do that without rereading the entire history of the project.
So the simplest way I can describe what I eventually built is:
GitHub became the durable memory layer.
The current public baseline of the experiment is AI Development Playbook v0.2.0.
But the version number is not really the interesting part.
The interesting part is that all of this started because:
a curtain wall engineer who could not read source code wanted to add an EasyCard reader to a traditional four-wire analog apartment intercom.
And somehow that turned into an ongoing experiment in:
how to let AI work on long-lived projects with less context, clearer authority, and stronger evidence.
If you're also using AI on a project that has lived longer than one conversation, I'm curious:
What breaks when you open a completely fresh AI session?
And if you try the Playbook, I'd be especially interested in the failure cases — places where the rules are present, but the AI still interprets them differently from what you expected.
Those failures are probably where the next useful rules will come from.
All reactions