Everyone is building apps with AI now. My cousin built one. Your manager built one. Somebody built one during a meeting about whether we should build one.
That's genuinely great. But it raises a fair question: if a first-time builder and an engineer with ten years of experience use the same model with the same prompt, what's actually different?
Let's run the experiment in our heads. Two developers, same AI, same request:
"Build me a task-tracker app with user login."
Meet Nia, the native AI builder: smart, fast, has never shipped software before. And Sam, the seasoned engineer, who has broken production enough times to be careful.
Day 1: no difference at all
Both get a working demo in an afternoon. Login page, task list, a nice dark theme, a little confetti when you finish a task. Both post a screenshot. Both get 40 likes.
If you only look at day 1, experience doesn't matter. This is the part of the story everyone's excited about, and they're right to be. The AI did in an afternoon what used to take a week.
The difference shows up later, the way it always does in software: in the second month, when you change things.
Where the tokens go
Here's Nia's day 3. A user reports that tasks sometimes disappear.
Nia: tasks disappear sometimes, fix it
AI: (rewrites the storage layer)
Nia: now login is broken
AI: (rewrites the auth flow)
Nia: login works but tasks still disappear
AI: (adds a retry, a cache, and a second database "for reliability")
Nia: it's slower now and still broken. FIX IT PROPERLY
AI: (apologises, rewrites the storage layer again)
Every one of those messages drags the whole conversation and a growing chunk of the codebase into context again. Every fix touches more files than the bug lives in. After a week the app works most of the time, nobody knows why, and the token bill looks like a phone number.
Sam's day 3, same bug:
Sam: Read CLAUDE.md. Tasks occasionally disappear after editing.
Don't change code yet: find where tasks are written and list
the ways two writes could race.
AI: Two tabs saving the same task: last write wins, no version check.
Sam: Write a failing test that reproduces it with two concurrent saves.
AI: (test fails, as expected)
Sam: Fix it with a version column and a conditional update. Keep the diff small.
AI: (12-line change, test passes)
Sam: (reads the diff, commits)
Four messages. One small diff. A test that will catch the bug if it ever comes back. Sam spent fewer tokens than Nia, not more. Experience didn't make Sam write better prompts in some magic way. It made Sam ask for smaller, checkable steps.
(If that bug looks familiar, it's the same race I wrote about in Model business workflows as state machines. AI doesn't remove these problems. It just reaches them faster.)
Same model, two loops. Only one of them ends. Explore the interactive diagram
The side-by-side
| Nia (first-time builder) | Sam (experienced engineer) | |
|---|---|---|
| First prompt | "Build the whole app" | "Plan the app; don't write code yet" |
| Size of each request | A feature, or "fix everything" | One change you can review in two minutes |
| Context | Re-explains the project every session | A project instructions file the AI reads every time |
| Definition of done | "It looks like it works" | A test passes, and the diff makes sense |
| When it breaks | "Fix it" (again) | "Explain why before changing anything" |
| Tools | Pastes logs and docs into the chat | Gives the AI tools: skills, plugins, MCP servers |
| Dependencies | Whatever the AI suggested | Asks why each one is needed |
| Secrets | API key in the code, "temporarily" | Environment variables from the start |
| Git | One giant commit called "final" | A commit after every green step |
| Day 30 | Afraid to touch it | Adds features on a Friday |
None of Sam's column is about AI. It's just engineering: small steps, tests, version control, knowing what "done" means. AI is a multiplier, and it multiplies whatever habits you bring.
What makes AI-written code sustainable
"Sustainable" is a fancy word for one question: can someone change this code next month without breaking it? "Someone" includes you, and it includes the AI.
Four things decide the answer:
- Tests that describe behaviour. A test suite is the only spec the AI can't misread. With tests, "refactor this" is safe. Without them, every change is a gamble the AI makes with confidence.
- Small, readable diffs. If you can't explain a change in a sentence, you can't review it, and unreviewed code is how plausible-but-wrong bugs ship. My favourite: a refund endpoint that retries on timeout and pays twice. It looks perfectly correct in a diff (here's how to prevent it).
-
Written-down decisions. A project instructions file (
CLAUDE.md,AGENTS.md,.cursorrules, whatever your tool reads) that says: how to run the tests, what the architecture is, what not to touch. The AI stops rediscovering your codebase every session, and that's most of the token savings right there. - Boring choices. One database, not five. A library everyone knows, not the one the AI half-remembers. AI is very good at writing glue for popular tools and very bad at debugging an obscure one.
Skills, plugins and tools: stop pasting, start equipping
The biggest token sink I see is pasting: the same error log, the same docs page, the same "here's how our project works" paragraph, over and over.
Experienced developers give the AI tools instead:
- Skills and plugins package a repeatable way of doing something, such as a review checklist, a deploy process or an audit, so you don't explain it every time.
- MCP servers let the AI read your tickets, query a staging database or check a deploy itself, instead of you copying the output in. (I built one for Java services for exactly this reason.)
- Your own scripts: a test command, a screenshot script, a linter. The AI can run them and check its own work.
A real example: this site. While building it with an AI assistant:
- Archify drew the diagrams, with its own validation checks, instead of the AI hand-placing boxes.
- An SEO audit skill (claude-seo) ran its checklist against the built site and found a real bug:
robots.txtpointed at a sitemap that no longer existed. - Every visual change was screenshotted in a headless browser before it shipped, which caught a meme overflowing on phones and a diagram that rendered as a broken image.
- And the homepage stack section went through two designs I didn't like. Before the third attempt, I was asked to pick a concept from four sketches. That one stuck.
That last one isn't a tool at all. It's the oldest engineering habit there is: agree on what you're building before you build it. It turns out it works on AI too.
Signs you're vibe coding
Score yourself honestly. One point each:
- [ ] Your most-used prompt is "fix it".
- [ ] You've said "PLEASE" to a compiler in capital letters.
- [ ] Your app has 3 state-management libraries and you know the name of one.
- [ ] There is a file called
utils2_final_REAL.ts. - [ ] Your git history is one commit: "init".
- [ ] You don't know what happens if two users click Save at the same time.
- [ ] The AI added a cache "for performance" and you were too scared to ask why.
- [ ] Your API key is in the frontend, but "only for now".
0–2: you're Sam. 3–5: you're on the way. 6–8: you're Nia, and that's fine. Every Sam started as a Nia. The good news is that every habit in Sam's column can be learned, and the AI will happily help you learn it if you ask it to explain instead of just fix.
The playbook
If you want to work like Sam starting tomorrow, here's the whole thing:
- Plan before code. Ask for a plan and push back on it before any code exists.
- Write a project instructions file on day 1: how to run, how to test, the rules.
- One change per request, small enough to review in two minutes.
- Test first for anything that matters: write the failing test, then the fix.
- Read every diff. If you don't understand it, ask "why" before you accept it.
- Commit after every green step, so you can always go back.
- Equip, don't paste: skills, plugins, MCP servers and scripts the AI can run.
- When stuck, ask for a diagnosis, not a fix. "Explain why this fails" costs less than five rewrites.
Takeaways
- On day 1, AI makes everyone equal. By day 30, habits make the difference.
- Experienced developers often spend fewer tokens, because small steps, tests and saved context beat "fix it" loops.
- Sustainable AI-written code has tests, small diffs, written decisions and boring choices.
- Give the AI tools, not copy-paste.
- Experience isn't about typing faster anymore. It's about knowing what to ask for, and knowing when the answer is wrong.
Originally published at ayushwing.com.
Top comments (1)
The Nia and Sam comparison is the clearest version of this I have read, and the part I would underline is your line that none of Sam's column is about AI. Small steps, a failing test first, reading the diff before accepting it: those are habits, not tools, and habits are exactly what a beginner cannot get from watching a demo.
I see the same gap on the IT and security side, only the interview version is harsher. A hiring manager does not ask how you would fix something in theory. They ask what you have actually handled, and a list of tools you have read about is not an answer. No IT certification is needed to start; what moves someone forward is proof they can handle real work, graded the way a real team would grade it, with a verifiable work record behind it.
That is what the simulated shifts at getonthejob.com are built around: real tickets and incidents, graded like a real team, so the habits in Sam's column get built on work you can walk someone through, not just on advice you read. The free shifts are a good way to feel what that kind of graded work looks like, before anyone is judging you for real.