Reading a codebase you did not write
Upload it and ask for the map: entry points, data flow, the three files that matter, the thing that will surprise you. An hour instead of a week.
Coding with AI
Coding with AI: ship code you understand, with a second AI checking the first.
Whether you have coded for years or started last month, AI changes your job in the same way: you stop being the person who types the code and become the person who directs it, checks it and decides. Done well, you ship faster and with fewer bugs than before. Done badly, you ship confident-looking code you cannot debug at 2 a.m. This page is the well-done version.
Free to start: your first Project, your files, the major AI families. The latest models matter most for review and debugging.
What actually changes
The AI writes. You review. That is a different skill, and it is learnable.
The trap is obvious once you have fallen into it. An AI produces a function that looks complete, with sensible names and a confident explanation. It runs. Two weeks later it double-charges a customer, because it never checked whether a webhook was a retry. Nobody caught it because the only reviewer was the model that wrote it, and a model does not doubt its own work.
So the discipline of coding with AI is not about prompting harder. It is about building a loop where every piece of code is checked by something that did not write it: a second model, a test, and your own eyes on the exact scenario that matters. In MultipleChat that loop is natural, because the same question with the same files can go to ChatGPT, Claude and Gemini at once, and the places they disagree are the places to look.
The loop
Put the context in one place, once
Create a Project for the codebase. Import the repository from GitHub where enabled, or upload the files that matter: the README, the data model, the module you are working in, the conventions you follow. Add instructions such as "we use Postgres, we never store secrets in code, all money is in integer cents". Every conversation after that starts from this.
Ask for one small thing
One function, one endpoint, one migration. Paste the file it goes in. "Only change what I asked for; return the full file with everything else identical." Big requests produce plausible code that touches things you did not mention.
Have a different model review it
Send the result to a second model with the same Project context: "Review this as a senior engineer who did not write it. Bugs, security, edge cases, ordered by severity, with the fix." When it finds nothing, ask a third. When two of three flag the same line, that line is wrong.
Ask for the tests before you trust it
"Write the tests this code needs, including the failure cases nobody wants to think about." Run them. A test that fails on the retry case is worth more than any explanation.
Run the exact scenario, then commit
Not "it runs": the specific case that would embarrass you. The retry, the empty list, the user in another time zone, the 10,000-row import. Then
git commit, so the next AI mistake can be undone in one command.
Know the failure modes
The seven mistakes AI code makes most
These come up in review again and again, across every model. Learn them and you will catch most of them yourself; give the list to a second model and it will catch the rest.
| Mistake | What it looks like | How to catch it |
|---|---|---|
| No idempotency | A webhook or job that applies the same event twice on retry: double charge, duplicate email. | Ask: "What happens if this runs twice with the same input?" |
| Invented APIs | A library method that does not exist, or a parameter from an older version. | Ask a model with web research to confirm against current docs; run it. |
| Swallowed errors | try/except: pass. The failure disappears and the data is silently wrong. | Search the diff for empty catches. Ask: "Where can this fail quietly?" |
| Secrets in code | An API key or database password in a source file, now in Git forever. | Ask: "Which of these values are secrets and where should they live?" |
| Dates and time zones | "Today" computed on the server, so users in Sydney lose a day. | Ask specifically about midnight, DST and a user in another zone. |
| N+1 queries | A loop that hits the database once per row. Fine with 10 rows, dead at 10,000. | Ask: "How many queries does this make for 1,000 records?" |
| Unvalidated input | Trusting the request body, the CSV, the URL parameter. | Ask: "What is the worst input a user could send here?" |
Why two models beat one
Each model has blind spots, and they are rarely the same blind spots. In practice one tends to miss the retry case while another misses the time zone. Sending the same file to both, with the same context, is the cheapest code review you will ever get.
Beyond new code
Where AI pays off most for people who already code
Safe refactors with tests first
"Write the tests that pin current behaviour, then refactor." Tests first means the refactor is checkable, not hopeful.
The stack trace you have stared at for an hour
Paste the trace, the file and what you expected. Ask two models; they often disagree on the cause, and the disagreement narrows it faster than either alone.
Version upgrades and language ports
Breaking changes listed from the real changelog, then applied file by file with review. Tedious work that AI does well when it is given the facts.
Documentation that matches the code
README, API docs, the comment on the regex nobody understands. Generated from the code itself, not from memory.
Architecture with the trade-offs visible
Monolith or services, Postgres or a document store, queue or cron. Ask models to argue both sides before you choose.
Free is the start. The latest models are the difference.
Review and debugging are where model quality shows.
Generating a function is easy; every model can do it. Finding the retry bug in it, explaining a 40-line stack trace, or holding a 30-file repository in view while it reasons about a change is where the newest models pull away from older ones. The free plan is a real way to learn the loop. When the code is going to production, you want the strongest reviewers available.
Newer models hold your whole Project in view instead of the last few messages, reason through trade-offs instead of picking the first plausible answer, and are wrong less often and with less confidence. For the questions on this page, that is the difference between advice that sounds right and advice you can act on.
Pro from $20 a month, cancel any time. The free plan stays free.
- Your first Project and file uploads
- The major AI families to try the workflow
- A small daily message allowance
- The latest ChatGPT, Claude, Gemini, Grok and Perplexity models, all on the same Project
- Far more messages a day, so a working session does not stop halfway
- Modes where several models draft, challenge and verify each other's answers
- Larger uploads and more files per Project, so the whole repo fits
- Independent verification passes for library versions and API facts
Start here
First messages for a coding Project
Import the repo or upload the files first. Then start with one of these.
MapHere is the codebase. Give me the map: entry points, data flow, the three files that matter most, and the thing most likely to surprise a new developer.
BuildAdd [feature] to [file]. Only change what I asked for. Return the full file, then explain the change in three sentences.
ReviewReview this as a senior engineer who did not write it. Bugs, security, edge cases, ordered by severity, each with the fix. Do not praise the code.
TestWrite the tests this code needs, including the failure cases: retries, empty input, other time zones, very large input.
DebugHere is the stack trace, the file, and what I expected. What is the cause, and what is the smallest fix? List other possible causes if you are not certain.
SecureList every place this code trusts input it should not, and every value that is a secret. Show where each secret should live instead.
Honest answers
What people ask
Do I still need to learn to code if AI writes it?
You need to read code well enough to check it, which is easier than writing it and comes quickly if you ask "explain this in three sentences" after every piece. The people who get into trouble are the ones who never read what they ship.
Which AI model is best for coding?
It changes with each release and by task; one may be stronger at generating, another at review. The honest answer is to stop betting on one. Send the same task to several with the same context and keep what survives the others' review.
Is my code used to train the models?
No. Files and conversations stay in your account and are never used to train any model, by MultipleChat or by the AI providers. See security.
How do I give the AI my repository?
Create a Project, then import selected files from GitHub where enabled or upload them directly. Add Project instructions for conventions and constraints. Sync when the code changes.
Does MultipleChat run or deploy my code?
No. It is where code is planned, written, reviewed and explained. You run it in your editor and terminal and deploy with your own provider, which keeps everything under your control.
What is free?
Your first Project, file uploads and the major model families, with a daily message allowance. The latest models, far more messages, larger uploads and the multi-model verification modes are on paid plans. See plans.
Put the repo in a Project and ask for the map.
Ten minutes from now you will know more about your codebase than you did this morning, and a second AI will be checking the first. Free to start.
Also: how to build an app with AI · build software with AI · start a business with AI