ATRIUMsearch → argument graph
Video · 2026-07-08 · 39m · 12 moments

LGTM, Ship It: The AI Code Review Problem

✦ AI generated

timeline · colored by role

01
Mechanism

Giving an AI coding agent strict, explicit rules about how it's allowed to write code (like banning side effects/useEffect) makes the output read like code you'd actually want to read.

Scott explains that he heavily constrains how AI agents are allowed to write components (e.g., no effects in Svelte) so that when he reads the generated code, it matches the style he actually wants.

transcript

Scott Tolinski: I heavily dictate the style at which they're allowed to write components in. You know, in the Svelte world I'm saying do not use effect. Don't even think about it. Side effects are almost never the right decision here.

supports · 1

02
Mechanism

Giving an AI coding agent strict, explicit rules about how to write components (e.g., banning side-effect-heavy patterns) makes the code it produces easier to read afterward, because it ends up matching the style you'd have written yourself.

Scott says he heavily dictates component style rules to AI agents (e.g., 'no effects' in Svelte) so the resulting code reads the way he'd write it, making it easier to understand.

transcript

Scott Tolinski: I heavily dictate the style at which they're allowed to write components in. You know, in the Svelte world I'm saying do not use effect. Don't even think about it. Side effects are almost never the right decision here... So, therefore, when I go to read the code, it reads like the code I want to read.

explains mechanism · 1rebuts · 1supports · 1

03
Claim

When AI writes UI code, you need to review it in smaller increments and pay much closer attention than you would for backend logic, because sloppy AI-built UI/UX (not broken functionality) is what makes so many AI-assisted apps feel bad.

Wes distinguishes reviewing AI-generated backend code (fine in large chunks) from UI code, which he checks in smaller pieces since bad UX is what makes AI-built apps feel low quality.

transcript

Wes Bos: But when it comes to actually building out the UI, I drill in a little closer and I spend a lot more time on it and do sort of smaller changes because I think that's why a lot of these apps feel like crap is because the UIs on them are just absolutely awful. They technically work well, but how you use them, how you interact with them, and what they look like is often leaves a lot to be desired.

rebuts · 1

04
Claim

The problems teams are hitting with AI-generated code — tech debt, review bottlenecks, architecture drift — aren't new problems at all, and neither are the solutions; teams are just hitting them on fast-forward instead of over years.

Scott argues that the tech debt and review problems caused by AI-assisted coding are the same old software engineering issues, just compressed into months instead of years because AI lets teams generate code so much faster.

transcript

Scott Tolinski: The problems you are describing here are not new at all and the solutions to these problems are not new either at all. You we know how to how to make a good software and the fact that you guys are just doing it on a speedrun is just making it much faster.

supports · 2

05
Claim

The technical debt, inconsistency, and fragility caused by merging huge volumes of unreviewed AI-generated code aren't new engineering problems at all — they're the exact same old software engineering problems, just happening on fast-forward.

Responding to a listener merging 60 PRs a week with almost no human review, Scott argues the resulting mess isn't a new kind of problem — it's classic bad software engineering, just accelerated by AI.

transcript

Scott Tolinski: The problems you are describing here are not new at all and the solutions to these problems are not new either at all. We know how to make a good software and the fact that you guys are just doing it on a speedrun is just making it much faster.

explains mechanism · 1extends · 1gives example · 1rebuts · 2

06
Claim

AI makes technical debt a bigger problem than ever because it's so easy to pile on new code and the AI resists removing code even when explicitly asked, while many of its biggest boosters have never had to maintain an old, long-running codebase and don't grasp the consequences.

Wes argues that inexperienced 'prompt bros' underestimate real tech debt because AI makes adding code trivial but strongly resists removing it, setting teams up for a reckoning.

transcript

Wes Bos: I think one thing that the prompt bros don't realize about this stuff is because, you know, most of them have never maintained old systems or long-running systems or these types of things. That tech debt is really real and tech debt is such a major problem with AI now because it's so easy to add code and like AI hates to remove code even when you beg it to remove code.

explains mechanism · 2

07
Claim

AI coding tools make technical debt worse because it's trivially easy for them to add code, but they resist removing it even when explicitly asked, so the codebase just keeps growing.

Wes points out that people who haven't maintained long-running codebases underestimate how real tech debt is, and that AI's tendency to add code freely while refusing to delete it will come back to haunt teams.

transcript

Wes Bos: That tech debt is really real and and tech debt is is such a major problem with AI now because it's so easy to add code and like AI hates to remove code even when you beg it to remove code. So like yeah, I just feel like the amount of code that we be adding sometimes is going to come back to haunt teams.

explains mechanism · 1gives example · 1supports · 1

08
Definition

A truly 'local' AI model must actually compute on your own machine — running software locally that just calls out to a remote API doesn't count as local.

Scott clarifies the common confusion around 'local' AI: many people think running a local app makes it local AI, when in fact the actual inference is happening via API calls to remote servers.

transcript

Scott Tolinski: Well, local models are just uh models that you're running on your local machine. I think some people really disconnect that and think, 'Ooh, I'm running the software locally, therefore it's local.' But it like when reality they're going off and doing API calls.

09
Mechanism

Jujitsu (JJ) keeps every snapshot, merge, and commit in one unified operation log, which is what enables a simple undo command for any git action.

Scott describes JJ's core mechanism — a single operation log recording every revision, snapshot, and merge — which lets users run a universal undo command that vanilla Git can't offer.

transcript

Scott Tolinski: There's an operation log of all revision logs including like your snapshots, your merging, all commits and everything exist in one giant operation log. So at any given point you can just like run an undo command which that man having an undo command and get how many stack overflow posts would that have saved, right?

10
Mechanism

Jujutsu's unified operation log — which records every snapshot, merge, and commit in one place — gives it a simple undo command that plain Git lacks, something that could have saved countless Stack Overflow rescue posts.

Scott explains that Jujutsu keeps one comprehensive operation log of all revisions, snapshots, and merges, enabling a simple undo command he says plain Git sorely lacks.

transcript

Scott Tolinski: There's an operation log of all revision logs including like your snapshots, your merging, all commits and everything exist in one giant operation log. So at any given point you can just like run an undo command which — having an undo command in git, how many stack overflow posts would that have saved, right?

11
Claim

Freelancers should price their work based on the value they deliver to the client, not on time spent or effort, and that hasn't changed just because AI makes work faster.

Scott argues pricing freelance work has always come down to value delivered, not hours logged, and that AI speeding up production doesn't change that fundamental pricing principle.

transcript

Scott Tolinski: At the end of the day, I think value derived is the only way to price this kind of work and frankly for me has always been the only type of way to to price this work.

extends · 1

12
Claim

Freelancers and contractors should keep pricing their work based on the value delivered to the client, not on time spent or effort, exactly as they always should have — AI just makes it more obvious that hours worked is the wrong metric.

Wes argues pricing should be based on value delivered rather than hours or effort, a principle he says predates AI and still holds even as AI slashes the time tasks take.

transcript

Wes Bos: It's all about the value delivered and if you spend a whole bunch of your time learning something, building out a bunch of tools, creating, I don't know, an army of agents that is so special that nobody else can do it as well or as fast as you, that shouldn't be factored into how long it takes you — you should be billing based on how much value delivered to the client at the end of the day.

gives example · 1

Highlight slides
AI Coding Problems Aren't New✦ from: The problems teams are hitting with AI-generated code — tech debt, review bottlenecks, architecture drift — aren't new problems at all, and neither are the solutions; teams are just hitting them on fast-forward instead of over years.AI Speedrunning Old Engineering Problems✦ from: The technical debt, inconsistency, and fragility caused by merging huge volumes of unreviewed AI-generated code aren't new engineering problems at all — they're the exact same old software engineering problems, just happening on fast-forward.Speedrun, Not New Territory✦ from: The problems teams are hitting with AI-generated code — tech debt, review bottlenecks, architecture drift — aren't new problems at all, and neither are the solutions; teams are just hitting them on fast-forward instead of over years.Scott Tolinski's Take✦ from: The technical debt, inconsistency, and fragility caused by merging huge volumes of unreviewed AI-generated code aren't new engineering problems at all — they're the exact same old software engineering problems, just happening on fast-forward.AI Supercharges Technical Debt✦ from: AI makes technical debt a bigger problem than ever because it's so easy to pile on new code and the AI resists removing code even when explicitly asked, while many of its biggest boosters have never had to maintain an old, long-running codebase and don't grasp the consequences.The Experience Gap✦ from: AI makes technical debt a bigger problem than ever because it's so easy to pile on new code and the AI resists removing code even when explicitly asked, while many of its biggest boosters have never had to maintain an old, long-running codebase and don't grasp the consequences.AI Coding Tools Are Making Tech Debt Worse✦ from: AI coding tools make technical debt worse because it's trivially easy for them to add code, but they resist removing it even when explicitly asked, so the codebase just keeps growing.The Debt Just Keeps Growing✦ from: AI coding tools make technical debt worse because it's trivially easy for them to add code, but they resist removing it even when explicitly asked, so the codebase just keeps growing.
Related episodes