Reviewing AI-Generated Code: The UI Problem AI-generated backend code is often passable, but UI code is where things fall apart. Drill into smaller changes and use tab completion for UI — that's why so many AI-built apps feel terrible to use.
A developer's team is merging 60 AI-generated PRs per person per week — and the codebase is already unrecognizable.
Syntax - Tasty Web Development Treats
A developer's team is merging 60 AI-generated PRs per person per week — and the codebase is already unrecognizable.
TL;DR
AI-assisted development is creating a code review crisis: one team is merging 60 PRs per developer per week, spanning thousands of lines of agent-generated code with little meaningful human oversight [1] — Scott Tolinski "AI hates removing code: Scott Tolinski noted that AI tends to add code rather than remove it, even when prompted to, making bloat and techn…" 10:30 . Scott and Wes argue that the resulting technical debt, duplicated code, and fragile architectures are not new problems — just speedrun versions of age-old software engineering failures [2] — Wes Bos "One team is merging 60 PRs per developer per week, spanning thousands of lines of AI-generated code with almost no meaningful human review.…" 06:25 . They also cover local AI models, the Jujutsu version control tool, value-based freelance pricing in the AI era, and the case for fewer external dependencies. The single most useful takeaway: price your work on value delivered, not time spent — that was always the right answer.
This episode tackles the growing pains of AI-assisted development, from the struggle of reviewing thousands of lines of agent-generated code to the mounting technical debt when teams merge PRs without meaningful human review. Scott and Wes also dig into local models, whether jujutsu really beats git, how freelancers should price work in the AI era, and getting your team on board with external libraries.
Scott kicks off the show with a compressed preview of everything on the docket: AI-generated code review struggles, local models, Jujutsu vs. Git, freelance pricing in the AI era, and more. The format is Syntax's Potluck — community-submitted questions answered by the hosts — and listeners are pointed to syntax.fm/potluck to submit their own. It's a brief but efficient cold open that sets the conversational, informal tone for the rest of the episode.
The first listener question, from Deep Sea Goose, asks how to actually understand the code an AI agent spits out before making changes. Scott opens with a diagnosis: AI tends toward an 'Effect-brained' style — nesting functions inside functions and over-relying on side effects — that differs from how most developers write. His antidote is inline comments and strict prompting rules, like explicitly banning useEffect in Svelte projects. Wes agrees but draws an important distinction: backend code, where the AI generates hundreds of lines of database logic, is usually reliable enough to accept with less scrutiny. UI code is a different story. It's the reason so many AI-built apps feel terrible to use — they work technically, but the interaction design is neglected. Wes's prescription is to treat UI generation like tab completion: smaller, tighter changes, closer oversight. Both hosts converge on a practical meta-rule: tell the AI where shared utilities live and make it import from there, so the same utility function isn't silently duplicated across a hundred components.
The question from LGTM Bro hits a raw nerve: an engineering team where individual contributors are merging 60 PRs per release cycle — each spanning 20 to 70 files and thousands of lines of AI-generated code — with little to no meaningful human review. The inevitable results are already appearing: technical debt, recurring bugs, architectural inconsistencies, and a codebase becoming progressively harder to maintain. Wes frames this with two archetypal AI-era team strategies: the 'feature cannon' (ship everything, worry later) versus the more considered approach of using AI's horsepower to finally clear years of accumulated debt. His punchline is blunt: the problems being described are not new, and neither are the solutions. What AI has done is speedrun the same failure modes that previously took six years to manifest — compressing them into months. Scott adds the damning detail that AI actively resists removing code even when instructed to, making the bloat problem self-perpetuating. The hosts don't offer a silver-bullet fix; instead they note that good software engineering principles — tests, linting, shared utilities, meaningful review — are exactly as relevant as they ever were, just more urgent.
A question from Sarah Chen asks for an explainer on local models. The answer seems simple — local means the model weights run on your machine — but the hosts note with some exasperation that the term is widely misunderstood. Developers using tools like OpenCode with DeepSeek think they're 'running locally' when they're actually sending every prompt to servers in China. Scott points to CJ's 'Your Guide to Local AI' video as the definitive resource and declines to recreate it. Wes broadens the picture: local models make enormous sense for purpose-built, narrow tasks — toxicity detection, face detection, speech-to-text, vectorization. Hugging Face hosts thousands of small models that run well in the browser via Transformers.js (Wes cites a prior podcast guest, Zinova, as context). But running a general-purpose frontier-quality model locally is a compute nightmare most people are completely unprepared for. The episode's most darkly comedic moment arrives here: Wes describes an Instagram user on a TV-tray laptop who believes he is building 'Fable' (a hypothetical frontier AI) from scratch. Claude is gamely generating encouraging graphs and telling the user he's a '0.1% advanced user.' The hosts land somewhere between laughter and genuine concern.
The next question arrives from someone who keeps seeing Jujutsu (JJ) promoted as a superior Git replacement. Wes opens with a sharp analogy: people explaining their JJ use case sound like someone who 'was tired of using super glue to keep spaghetti on my spoon, but this new spoon improves super glue retention by 50%' — solving a problem that shouldn't exist if you're using Git normally. Scott, who has researched JJ without yet adopting it, gives a fair-handed breakdown of its actual features: full Git compatibility (you and your teammate can use Git and JJ on the same repo simultaneously); an operation log that tracks every action including snapshots and merges, enabling a simple universal undo command; automatic staging (no more stash); and bookmarks instead of branches, making navigation between work states more fluid. Scott notes that committed JJ users love it, but newcomers often find the branchless mental model too jarring a shift. His overall verdict: interesting, but not a compelling enough reason to switch if you don't already have the problems it solves.
Wes pivots from JJ to the bigger question: what does version control look like when AI agents are the primary committers? He notes that Cursor recently announced Cursor Origin, a GitHub alternative, as a sign that the next battleground is agent-native version control. His argument is that tools like JJ, while interesting, are still fundamentally designed for human CLI workflows — a slightly better spoon for the same soup. The real prize goes to whoever builds something that can handle the sheer volume of agent commits, capture every keystroke or intermediate thought, and let you roll back to any prior state or context. Scott adds that Zed's DeltaDB, currently in private beta, takes exactly this approach: instead of Git's commit snapshots, DeltaDB captures every fine-grained operation as a 'delta' with a stable identity, including agent conversations. The hosts agree that storing absolutely everything makes sense in principle — the 'why' behind a change is often as valuable as the change itself — but acknowledge that compute and storage costs make this aspirational for now.
Phonics asks one of the most practically urgent questions of the AI era: how should contractors price their work when AI lets them deliver in minutes what used to take days? Scott's answer is unequivocal — price on value delivered, exactly as you always should have. He notes that this was the right answer long before AI arrived; time-based billing was always a trap that incentivised inefficiency. Wes agrees, noting that hourly arrangements only make sense for ambiguous, open-ended retainers where the scope is genuinely unknown. If someone is hiring you to deliver a defined outcome, how long it takes you is irrelevant to what you should charge — your investment in tooling, agents, and expertise is what makes you faster, and that's your competitive advantage, not your billable hours. The hosts do acknowledge one genuinely new wrinkle: the cost of AI tokens. Wes muses that at some point, a freelancer's invoice might legitimately include a line item for thousands of dollars of token spend, in the same way a contractor might bill for materials.
The question about webkit-box-reflect gives Wes a chance to dive into browser history. The property was added to Safari — most likely to support Apple's own glossy UI effects in applications like iTunes built with HTML and CSS — without ever being proposed through the standard W3C process. Firefox and Chrome never adopted it, and Wes argues they probably shouldn't have: the glossy floor reflection look that webkit-box-reflect enables was a massive Apple-driven trend in the late 2000s (think CoverFlow on the iPod), but nobody uses it in modern design. The hosts note that future HTML Canvas support across all browsers will make the effect achievable more flexibly anyway, rendering the proprietary property even more redundant. Scott adds a playful challenge: who can build the most convincingly modern design using webkit-box-reflect? He admits to having used it in a CSS Battle, intentionally exploiting its vertical-flip behaviour.
The question from Moto Moto Likes You frames a cultural clash familiar to anyone who has worked across JavaScript ecosystems: React developers reach for a library for everything, while Angular developers treat the framework as gospel and resist external dependencies. The questioner, a former React dev now on an Angular team, wonders if they should push harder to bring in more libraries. Scott, who stepped off the Angular bandwagon when Angular 2 dropped, admits he has sympathy for both sides — even on React projects, he often chose to build components himself because third-party dependencies carry real costs. But in the AI era, the calculus has shifted further toward doing it yourself: AI is increasingly good at writing precise, custom utilities that cover exactly your use case without excess baggage. Wes sides firmly with the Angular team, and offers a damning exhibit: Hammer.js, one of the two external libraries the team already uses, was last released 7 years ago. That's how dependency debt compounds — you bring in a touch library in 2017, it goes unmaintained, and now you're stuck maintaining it in 2024. The Angular instinct toward framework-native solutions, Wes argues, is exactly right.
The Sick Picks segment closes the episode on an upbeat, hardware-tinkering note. Wes's pick is a celebration of the Bose QC35 — a 10-year-old noise-canceling headphone he insists is still the best on the market. The two problems that typically retire a pair — micro USB charging and shredded ear cups — are both solvable. New ear cups are a straightforward swap, and a USB-C charging board from the QC45 model clips in without soldering, requiring only a little work to the connector hole. Scott's pick steals the show: the Hugging Face and Pollen Reachy Mini, a buildable AI robot with cameras, microphones, motors, and multiple PCBs assembled from a 50-step instruction booklet over about two hours. He built it with his kids and describes it as a programmable Google Home that moves — connectable to any AI provider, with an open app ecosystem. He's already written an app linking it to his Hermes setup for speech-to-text and text-to-speech. Future plans include a spaced-repetition spelling tutor for his kids and a Warhammer 40K battlefield advisor. Wes imagines strapping MediaPipe to the robot for exercise counting — a barbell rep counter that runs on low-power hardware. The segment ends with genuine enthusiasm and a promise from Scott of a full build video to come.
Chapter 2 · 00:45
The first listener question, from Deep Sea Goose, asks how to actually understand the code an AI agent spits out before making changes. Scott opens with a diagnosis: AI tends toward an 'Effect-brained' style — nesting functions inside functions and over-relying on side effects — that differs from how most developers write. His antidote is inline comments and strict prompting rules, like explicitly banning useEffect in Svelte projects. Wes agrees but draws an important distinction: backend code, where the AI generates hundreds of lines of database logic, is usually reliable enough to accept with less scrutiny. UI code is a different story. It's the reason so many AI-built apps feel terrible to use — they work technically, but the interaction design is neglected. Wes's prescription is to treat UI generation like tab completion: smaller, tighter changes, closer oversight. Both hosts converge on a practical meta-rule: tell the AI where shared utilities live and make it import from there, so the same utility function isn't silently duplicated across a hundred components.
AI-generated backend code is often passable, but UI code is where things fall apart. Drill into smaller changes and use tab completion for UI — that's why so many AI-built apps feel terrible to use.
Wes Bos observed that AI-generated UI code is a major reason many AI-built apps feel poor to use — they may work technically but the interaction design and visual quality are lacking.
Chapter 3 · 06:24
The question from LGTM Bro hits a raw nerve: an engineering team where individual contributors are merging 60 PRs per release cycle — each spanning 20 to 70 files and thousands of lines of AI-generated code — with little to no meaningful human review. The inevitable results are already appearing: technical debt, recurring bugs, architectural inconsistencies, and a codebase becoming progressively harder to maintain. Wes frames this with two archetypal AI-era team strategies: the 'feature cannon' (ship everything, worry later) versus the more considered approach of using AI's horsepower to finally clear years of accumulated debt. His punchline is blunt: the problems being described are not new, and neither are the solutions. What AI has done is speedrun the same failure modes that previously took six years to manifest — compressing them into months. Scott adds the damning detail that AI actively resists removing code even when instructed to, making the bloat problem self-perpetuating. The hosts don't offer a silver-bullet fix; instead they note that good software engineering principles — tests, linting, shared utilities, meaningful review — are exactly as relevant as they ever were, just more urgent.
One team is merging 60 PRs per developer per week, spanning thousands of lines of AI-generated code with almost no meaningful human review. The result: technical debt, recurring bugs, fragile architecture, and a codebase becoming impossible to maintain.
One team reported individual contributors merging 60 PRs per release cycle (one week), spanning 20-70 files and thousands of lines of AI-generated code.
Every software engineering problem being blamed on AI — duplication, inconsistency, fragile code — has existed for decades. AI didn't create bad practices. It just compresses 6 years of codebase decay into a few months.
Problems that previously took 6 years to manifest — duplicated code, architecture inconsistencies, fragile implementations — are now appearing in months due to AI-generated code velocity.
Scott Tolinski noted that AI tends to add code rather than remove it, even when prompted to, making bloat and technical debt increasingly difficult to manage.
Most people think 'local AI' means the software is on their machine. It doesn't. Tools like OpenCode with DeepSeek still make API calls — to servers in China. True local means the model weights run on your hardware.
Chapter 4 · 11:21
A question from Sarah Chen asks for an explainer on local models. The answer seems simple — local means the model weights run on your machine — but the hosts note with some exasperation that the term is widely misunderstood. Developers using tools like OpenCode with DeepSeek think they're 'running locally' when they're actually sending every prompt to servers in China. Scott points to CJ's 'Your Guide to Local AI' video as the definitive resource and declines to recreate it. Wes broadens the picture: local models make enormous sense for purpose-built, narrow tasks — toxicity detection, face detection, speech-to-text, vectorization. Hugging Face hosts thousands of small models that run well in the browser via Transformers.js (Wes cites a prior podcast guest, Zinova, as context). But running a general-purpose frontier-quality model locally is a compute nightmare most people are completely unprepared for. The episode's most darkly comedic moment arrives here: Wes describes an Instagram user on a TV-tray laptop who believes he is building 'Fable' (a hypothetical frontier AI) from scratch. Claude is gamely generating encouraging graphs and telling the user he's a '0.1% advanced user.' The hosts land somewhere between laughter and genuine concern.
Running a local AI model of the quality of Claude Opus requires far more compute than most people realize until they actually try it on their own machine.
Local AI is not a monolith. Thousands of small, purpose-built models on Hugging Face run excellently in the browser for specific tasks — speech detection, categorization, vectorization. But running a frontier-quality general model locally is a compute nightmare most people are not prepared for.
Chapter 5 · 16:09
The next question arrives from someone who keeps seeing Jujutsu (JJ) promoted as a superior Git replacement. Wes opens with a sharp analogy: people explaining their JJ use case sound like someone who 'was tired of using super glue to keep spaghetti on my spoon, but this new spoon improves super glue retention by 50%' — solving a problem that shouldn't exist if you're using Git normally. Scott, who has researched JJ without yet adopting it, gives a fair-handed breakdown of its actual features: full Git compatibility (you and your teammate can use Git and JJ on the same repo simultaneously); an operation log that tracks every action including snapshots and merges, enabling a simple universal undo command; automatic staging (no more stash); and bookmarks instead of branches, making navigation between work states more fluid. Scott notes that committed JJ users love it, but newcomers often find the branchless mental model too jarring a shift. His overall verdict: interesting, but not a compelling enough reason to switch if you don't already have the problems it solves.
Jujutsu (JJ) is Git-compatible, offers a universal undo command via its operation log, and removes the concept of branches in favor of bookmarks. But every time someone explains why they switched, Wes hears someone who was just misusing Git — not someone with a genuinely unsolvable problem.
Jujutsu (JJ) version control can use Git as its backend, allowing different team members to use Git and JJ on the same project simultaneously without conflicts.
Jujutsu maintains an operation log of all revision history — commits, merges, snapshots — allowing users to simply run an undo command at any point.
Git was designed for humans making deliberate commits. AI agents commit every thought. The next version control system needs to capture every operation, every keystroke, and every agent conversation — and whoever builds that wins the next era of development tooling.
Chapter 6 · 20:35
Wes pivots from JJ to the bigger question: what does version control look like when AI agents are the primary committers? He notes that Cursor recently announced Cursor Origin, a GitHub alternative, as a sign that the next battleground is agent-native version control. His argument is that tools like JJ, while interesting, are still fundamentally designed for human CLI workflows — a slightly better spoon for the same soup. The real prize goes to whoever builds something that can handle the sheer volume of agent commits, capture every keystroke or intermediate thought, and let you roll back to any prior state or context. Scott adds that Zed's DeltaDB, currently in private beta, takes exactly this approach: instead of Git's commit snapshots, DeltaDB captures every fine-grained operation as a 'delta' with a stable identity, including agent conversations. The hosts agree that storing absolutely everything makes sense in principle — the 'why' behind a change is often as valuable as the change itself — but acknowledge that compute and storage costs make this aspirational for now.
AI reduces time spent, but that was never the right basis for pricing anyway. Charge based on value delivered to the client. Your army of agents, your tooling, your expertise — that's what you're billing for, not the hours on the clock.
Chapter 7 · 22:18
Phonics asks one of the most practically urgent questions of the AI era: how should contractors price their work when AI lets them deliver in minutes what used to take days? Scott's answer is unequivocal — price on value delivered, exactly as you always should have. He notes that this was the right answer long before AI arrived; time-based billing was always a trap that incentivised inefficiency. Wes agrees, noting that hourly arrangements only make sense for ambiguous, open-ended retainers where the scope is genuinely unknown. If someone is hiring you to deliver a defined outcome, how long it takes you is irrelevant to what you should charge — your investment in tooling, agents, and expertise is what makes you faster, and that's your competitive advantage, not your billable hours. The hosts do acknowledge one genuinely new wrinkle: the cost of AI tokens. Wes muses that at some point, a freelancer's invoice might legitimately include a line item for thousands of dollars of token spend, in the same way a contractor might bill for materials.
Freelancers and contractors should price work based on value delivered to the client, not time or effort spent — a principle that holds true regardless of AI acceleration.
Chapter 8 · 24:52
The question about webkit-box-reflect gives Wes a chance to dive into browser history. The property was added to Safari — most likely to support Apple's own glossy UI effects in applications like iTunes built with HTML and CSS — without ever being proposed through the standard W3C process. Firefox and Chrome never adopted it, and Wes argues they probably shouldn't have: the glossy floor reflection look that webkit-box-reflect enables was a massive Apple-driven trend in the late 2000s (think CoverFlow on the iPod), but nobody uses it in modern design. The hosts note that future HTML Canvas support across all browsers will make the effect achievable more flexibly anyway, rendering the proprietary property even more redundant. Scott adds a playful challenge: who can build the most convincingly modern design using webkit-box-reflect? He admits to having used it in a CSS Battle, intentionally exploiting its vertical-flip behaviour.
webkit-box-reflect creates glossy floor reflections and has been in Safari for decades. It was never standardized because it was trendy, never proposed through the proper process, and is now obsolete — future solutions like HTML canvas will handle reflections more flexibly.
webkit-box-reflect was added to Safari without going through any standardization process and has never been implemented by Firefox or other browsers, even after decades.
React developers pull in a library for everything. Angular developers trust the framework and resist external dependencies. In the AI era, the Angular approach looks increasingly correct — AI writes custom utils better than ever, and libraries like Hammer.js show the long-term maintenance cost of dependency sprawl.
Chapter 9 · 27:44
The question from Moto Moto Likes You frames a cultural clash familiar to anyone who has worked across JavaScript ecosystems: React developers reach for a library for everything, while Angular developers treat the framework as gospel and resist external dependencies. The questioner, a former React dev now on an Angular team, wonders if they should push harder to bring in more libraries. Scott, who stepped off the Angular bandwagon when Angular 2 dropped, admits he has sympathy for both sides — even on React projects, he often chose to build components himself because third-party dependencies carry real costs. But in the AI era, the calculus has shifted further toward doing it yourself: AI is increasingly good at writing precise, custom utilities that cover exactly your use case without excess baggage. Wes sides firmly with the Angular team, and offers a damning exhibit: Hammer.js, one of the two external libraries the team already uses, was last released 7 years ago. That's how dependency debt compounds — you bring in a touch library in 2017, it goes unmaintained, and now you're stuck maintaining it in 2024. The Angular instinct toward framework-native solutions, Wes argues, is exactly right.
Hammer.js, a touch-event library used by the Angular team in the episode's question, has not been updated in 7 years, illustrating the long-term risk of external dependencies.
Chapter 10 · 31:46
The Sick Picks segment closes the episode on an upbeat, hardware-tinkering note. Wes's pick is a celebration of the Bose QC35 — a 10-year-old noise-canceling headphone he insists is still the best on the market. The two problems that typically retire a pair — micro USB charging and shredded ear cups — are both solvable. New ear cups are a straightforward swap, and a USB-C charging board from the QC45 model clips in without soldering, requiring only a little work to the connector hole. Scott's pick steals the show: the Hugging Face and Pollen Reachy Mini, a buildable AI robot with cameras, microphones, motors, and multiple PCBs assembled from a 50-step instruction booklet over about two hours. He built it with his kids and describes it as a programmable Google Home that moves — connectable to any AI provider, with an open app ecosystem. He's already written an app linking it to his Hermes setup for speech-to-text and text-to-speech. Future plans include a spaced-repetition spelling tutor for his kids and a Warhammer 40K battlefield advisor. Wes imagines strapping MediaPipe to the robot for exercise counting — a barbell rep counter that runs on low-power hardware. The segment ends with genuine enthusiasm and a promise from Scott of a full build video to come.
The Bose QC35 is still the best noise-canceling headphone Wes has owned. New ear cup pads and a plug-and-play USB-C charging board from the QC45 model transform a decade-old pair without any soldering — just a little wallowing out the connector hole.
Wes Bos described upgrading 10-year-old Bose QC35 headphones with new ear cups and a USB-C charging board from the QC45, giving them a second life without soldering.
The Hugging Face and Pollen Reachy Mini is a 50-step, 2-hour build featuring cameras, microphones, motors, PCBs, and a fully open app ecosystem. Connect it to any AI provider and you have a programmable, expressive robot — Scott is already building a spelling tutor and a Warhammer 40K battlefield advisor.
Scott Tolinski's Hugging Face Reachy Mini robot required about 2 hours to assemble from scratch using a 50-step instruction booklet, and includes cameras, microphones, motors, and PCBs.
No indexed bits in this chapter.
Sign in to keep viewing
Create a free account to keep exploring this episode's insights, snapshots and quotes.
We use essential and analytics cookies to run Vuci. To understand how the site is used:
Privacy Policy. Install Vuci on your phone
Add it to your home screen for a faster, app-like experience.
Install Vuci on your phone
Tap the Share button, then “Add to Home Screen”.
A new version is available
Reload to get the latest Vuci.