People spend a lot of time asking which AI is best at coding.
Is Claude better than ChatGPT? Is ChatGPT catching up? Is one better at architecture while another is better at debugging? Does one produce cleaner React code? Does another understand large repositories better?
Those can be useful questions, but I’m increasingly convinced they’re not the most important ones.
The more important question is this:
What kind of process are you using to keep the AI from taking your project off the road?
A capable AI can write excellent code and still leave you with a mess. It can make a sound architectural decision, implement it well, and then fail to preserve enough information for the next session to understand what it did.
That’s not a theoretical problem. I’ve just watched it happen during a major architectural change in PageSnip.
The code was good.
The process was slipping.
And because the code was good, I let the process slip longer than I should have.
Good code and a good development process aren’t the same thing
There are at least three separate things involved when you use AI for software development:
- The quality of the AI’s technical judgment
- The quality of the code it produces
- The reliability of the process surrounding the work
People tend to roll those together and call the whole thing “coding ability.”
That’s a mistake.
An AI might be excellent at analyzing a performance problem. It might recommend the right database architecture, identify unnecessary state changes, and produce code that makes the application dramatically faster.
At the same time, it might ignore your documentation rules, fail to update the project history, and leave the next session with no reliable way to understand what changed.
The code from the first session may work perfectly.
The next session may still be a disaster.
That means code quality alone isn’t enough to judge whether an AI is safe to use on a serious project.
The AI session is temporary
This is the central fact behind session-based coding:
The conversation is temporary. The repository has to survive it.
An AI session may know an enormous amount about your project by the time you’ve worked together for several hours. It has seen the decisions being made. It remembers which approaches were rejected. It knows why a particular function was changed and why another part of the code was deliberately left alone.
None of that knowledge is guaranteed to survive the session.
The thread may get too long. The AI may compress the conversation. You may hit a usage limit. The session may begin losing details or behaving erratically. You may decide it’s simply time to move the work into a clean thread.
The replacement AI doesn’t inherit the original session’s understanding.
Even when you’re using the same model, the new session is effectively a new developer arriving at the project.
That developer needs more than a zip file full of code.
It needs the project’s operational memory.
Your repository needs to contain the truth
My session-based workflow is built around the idea that each repository should contain enough current information for a new AI session to continue the project safely.
That includes things such as:
- The current architecture
- The project rules
- Areas of the code that must not be changed
- Important decisions and why they were made
- The current build status
- Known defects
- Work that has been completed
- Work that remains
- Testing results
- Instructions for producing the next build
These files aren’t paperwork added after the real work is finished.
They’re part of the real work.
If the AI changes the code but doesn’t update the documents, it hasn’t completed the task.
That may sound strict, but the alternative is worse. Without those documents, the next session has to reconstruct the project from the code, from an incomplete handoff, or from whatever I happen to remember.
That defeats much of the value of session-based coding.
The whole point is that I shouldn’t have to personally reteach the entire project every time a session changes.
A handoff has to be maintained before you need it
It’s tempting to think of a handoff as something you create at the end of a session.
That’s too late.
By the time a session begins going sideways, it may no longer be capable of producing a completely reliable account of everything that happened.
A good handoff is built throughout the work.
Every completed build should leave the repository in a condition where another qualified session can pick it up.
That means the architecture notes are current. The change history reflects the actual changes. The build number is correct. The known-issues list hasn’t been forgotten. The startup instructions describe the project as it exists now, not as it existed six builds ago.
If those things are maintained continuously, the final handoff prompt can be fairly simple.
It tells the next session where to look and what needs to happen next.
If those things haven’t been maintained, the final handoff prompt has to become a substitute for the missing project memory. That’s where details get lost.
Don’t ask the AI to read the files. Make it prove that it did.
One of the most important lessons ChatGPT has taught me is that telling an AI to read a file doesn’t mean it actually read the file.
It may skim it.
It may read the headings and infer the rest.
It may rely on information from earlier in the conversation.
It may recognize the project and assume that what it remembers is still correct.
It may open one or two files, decide it has the general idea, and begin working.
Most of the time, it won’t announce that it took a shortcut. It’ll simply give you a confident answer.
That’s why my startup prompts now require evidence.
Before a new session is allowed to make changes, it has to report back with things that could only have come from reading the current repository.
For example, it may have to identify:
- The current build number
- The major architectural components
- The project’s protected boundaries
- The latest completed work
- The known problems still under investigation
- The files it expects to change
- The tests that must pass
- The exact source it is treating as authoritative
This doesn’t make mistakes impossible.
It does make shortcutting much easier to catch.
There’s an enormous difference between:
Read the startup documents and let me know when you’re ready.
and:
Read the startup documents completely, inspect the current code, and report back with the current architecture, build status, protected areas, unresolved issues, and your proposed plan. Don’t make changes until you’ve demonstrated that your understanding comes from the files in this repository.
The second prompt creates a checkpoint.
The AI can’t simply say, “I’ve reviewed everything.”
It has to show its work.
The repository is the source of truth, not the AI’s memory
This matters even more when you return to an AI you’ve used on the project before.
Previous knowledge can be helpful, but it can also be dangerous.
The AI may remember an earlier version of the architecture. It may remember a defect that has already been fixed. It may remember a function that no longer exists. It may recall a plan that was discussed but never approved.
That kind of memory can make the AI sound unusually knowledgeable while leading it in exactly the wrong direction.
A strong continuation prompt should make the hierarchy clear:
- The repository you just supplied is the source of truth.
- The documents inside that repository describe the current project.
- The current code must be inspected directly.
- Previous conversations and remembered code are not authoritative.
- Any conflict must be resolved in favor of the current repository.
That’s not just useful when switching from Claude to ChatGPT or from ChatGPT to Claude.
It matters when moving between two sessions of the same AI.
The name on the model doesn’t make the new session the same developer.
Availability is part of capability
Model comparisons usually focus on the quality of the answer.
In real development work, availability matters too.
An AI that writes outstanding code but repeatedly becomes unavailable in the middle of a major architectural change creates a different kind of risk.
You have to start managing the model’s limits alongside the project itself.
You begin thinking about whether there’s enough capacity left to complete the next build. You wonder whether you should stop before starting a difficult change. You may have to produce a handoff sooner than planned because the AI is warning that it’s about to become unavailable.
That doesn’t mean a limited model is unusable.
It does mean the limits are part of the development environment and should be considered when comparing tools.
In my own work, ChatGPT has been much more predictable in that regard. I regularly run several sessions in separate browser tabs using the highest reasoning setting available to me. I haven’t had to organize my development day around waiting for the AI to become available again.
That continuity has real value.
It doesn’t prove that ChatGPT will always write better code than Claude.
It means I can keep working without the tool unexpectedly becoming the project bottleneck.
Reputation is not supervision
One of the reasons I relaxed my process was that I’d heard the same claim many other people have heard:
Claude is better at coding.
Claude was producing good work, so the claim appeared to be confirmed.
That made it easier to overlook the fact that the session wasn’t following all of my project rules.
I treated the quality of the code as evidence that the process was safe.
It wasn’t.
No AI’s reputation should exempt it from your workflow.
Not Claude.
Not ChatGPT.
Not whichever model is leading the benchmarks next month.
A more capable model may make more sophisticated mistakes. It may also make those mistakes more convincingly.
The better the output looks, the easier it is to become less vigilant.
That’s when the structure matters most.
The same rules apply to agentic coding
Session-based coding makes the boundaries easy to see because you manually move from one conversation to another.
Agentic coding can hide those boundaries.
An agent may inspect the repository, modify several files, run tests, revise its work, and continue through multiple steps with much less supervision.
That can be useful, but it doesn’t eliminate the need for structure.
It increases it.
The agent still needs:
- A clear source of truth
- Explicit boundaries
- Current project documentation
- Defined completion criteria
- Required tests
- A record of what it changed
- A way to recover when its internal understanding goes wrong
Whether the AI works for ten minutes or ten hours, it shouldn’t be allowed to become the only place where the project’s reasoning exists.
The code tells you what the program does.
It doesn’t always tell you why it was changed, which alternatives were rejected, what remains unfinished, or what the next developer needs to know.
That information has to live somewhere outside the AI.
A practical session-based coding discipline
The exact files and workflow will vary from project to project, but the underlying rules are simple.
Start with a current repository
Don’t begin a new session with an old build, an incomplete patch, or a copy of the project that may not contain the latest changes.
Make the AI identify the repository it’s using and confirm that it’s treating that copy as authoritative.
Require a startup report
Before changes begin, require the AI to summarize the architecture, current status, protected boundaries, known defects, and proposed work.
The report should contain enough detail to demonstrate that the files were actually inspected.
Make documentation part of every build
Don’t accept “the code is done” while the startup, architecture, build, testing, and handoff documents remain stale.
A build isn’t complete until another session could understand it.
Keep changes small enough to verify
Large architectural work can still be completed in stages.
Each build should have a defined purpose, a limited set of changes, and a clear test result.
That makes it easier to identify where a regression was introduced and easier to hand the work to another session.
Stop when the session becomes unreliable
Once the AI starts losing context, repeating itself, ignoring established rules, or offering excuses instead of evidence, don’t keep pushing because you’re almost finished.
That’s how “almost finished” turns into several hours of cleanup.
Get the repository into the safest state available, produce a handoff, and restart with a fresh session.
Verify the new session before trusting it
A good handoff doesn’t guarantee a good continuation.
The new AI still has to prove that it understands the current project.
Don’t let it start changing code merely because it says the handoff was clear.
The model is not the method
Claude can write good code.
ChatGPT can write good code.
Both can make mistakes. Both can ignore instructions. Both can confidently claim to understand files they haven’t examined closely enough.
The difference between a successful project and a disaster isn’t simply which AI is doing the typing.
It’s whether the work is surrounded by a structure that survives the AI session.
The repository has to contain the truth.
The handoff documents have to remain current.
The AI has to inspect the actual files.
It has to demonstrate that it understands them.
And no matter how impressive the code looks, you have to keep your finger on the pulse of the process.
Good code can make you feel safe.
That’s exactly when you need to be most careful.
Related field note
This guide grew out of a real architectural overhaul in PageSnip and what happened when a successful Claude session had to hand the project to a new one. Read the full story in The Good, the Bad and the Ugly.