Using AI to write better code more slowly
Recorded: May 26, 2026, 1:15 p.m.
| Original | Summarized |
Using AI to write better code more slowly | Read the Tea Leaves Read the Tea Leaves Software and other dark arts, by Nolan Lawson Home « The diminished art of coding 25 Using AI to write better code more slowly Posted May 25, 2026 by Nolan Lawson in software engineering. Tagged: AI. 18 Comments A lot of people seem convinced that the point of AI coding is to write low-quality code as fast as possible. Spew out barely-passable slop, open massive PRs, and merge them unvetted. Ship it! Run a Claude sub-agent, Codex, and Cursor Bugbot to find bugs in this PR ranked by critical/high/medium/low. Once they’re all done, review their findings, do your own research to rule out false positives, and write a final report. That’s basically it. You can add your own definition of “bug” if you want – mine has stipulations about the KISS and DRY principles, writing accessible HTML/JSX, using proper indexes for SQL queries, etc. Have an agent fix all the criticals and highs (with my guidance on the proper solution), then repeat until no criticals/highs When I use this technique, I haven’t necessarily seen my velocity go up. If anything, the review process often finds pre-existing bugs, so I end up on a tangential side-quest where I’m writing unit tests and fixing subtle flaws that pre-date the PR. This is the opposite of the “10x productivity” slop-cannon style of development that most people imagine when they think of vibe coding, but I find it very satisfying. Related 18 responses to this post.
Posted by heckj on May 25, 2026 at 9:32 AM I’ve found the same technique — doing multiple sweeps — super effective for all kinds of review; I use the same for editorial review of grammar, punctuation, spelling, and so on. One thing I’ve realized is that wiping the context *between* sweeps also helps. And I’ve started to switch up my code reviews to “5-7 different lens” running in parallel — looking for different kinds of issues — and then collating the results and loosely ranking them.
Posted by Nolan Lawson on May 25, 2026 at 10:07 AM You’re right, clearing context really seems to help. That’s one of the reasons my reviewer skill specifies that the main agent shouldn’t do original research until all 3 sub-agents have returned – otherwise there’s a tendency to be influenced by the first result.
Posted by Ashah on May 26, 2026 at 1:15 AM would you be able to share your skill?
Posted by Spencer Karenbauer on May 25, 2026 at 7:03 PM I agree in a way. I think the idea now more so with vibe coding is individuals do not know how to write code properly and take all of these advanced AI tools like Claude/Cursor/etc as the end all-be all of solutions. They are great at baselines and can work through. But they should NOT be used as stand-alone tools. Enablement and governance need to be occuring simultaneously prior to implementing things like this in production.
Posted by Nolan Lawson on May 25, 2026 at 8:57 PM Right, the way I think of it is that an LLM’s output is just the first draft. The real work starts with the code review. And there is a lot of scaffolding/documentation you can put in place to make this process way more effective. Posted by AIを活用して高品質なコードを書く新しいアプローチ – ainewsfeed on May 25, 2026 at 9:31 PM […] 元記事: https://nolanlawson.com/2026/05/25/using-ai-to-write-better-code-more-slowly/ […] Posted by 개발자 트렌드 — 05월 26일 GitHub Trending & AI 업데이트 - 소운 on May 25, 2026 at 9:31 PM […] — 738점 · 댓글 319개 Exit IP VPN servers mitigation rollout — 302점 · 댓글 53개 Using AI to write better code more slowly — 295점 · 댓글 116개 Norway's 2 petabytes of Huawei flash storage and LLM training […] Posted by Using AI to Write Better Code More Slowly - </> tmsang.dev on May 25, 2026 at 10:08 PM […] Read the original article on NolanLawson.com → […] Posted by Using AI to Write Better Code – Reinke Technology on May 25, 2026 at 10:38 PM […] Original Article: Using AI to write better code more slowly […] Posted by AI Дайджест • 26.05.2026 — airecap.ru on May 25, 2026 at 11:01 PM […] Nolan Lawson […] Posted by Daily Trend Signal - May 26, 2026 - Daily Trend Signal on May 25, 2026 at 11:57 PM […] Using AI to write better code more slowly […] Posted by Hacker News 每日精選 – 2026-05-26 – 小丁的家 on May 26, 2026 at 12:03 AM […] 閱讀原文 🔗 […]
Posted by Giuseppe on May 26, 2026 at 12:30 AM Can you explain how you run multiple models in only one prompt and how to handle the differents output?
Posted by Using AI to write better code more slowly - Artificial Intelligence Max on May 26, 2026 at 1:46 AM […] Source: Hacker News […]
Posted by Using AI to write better code more slowly - Tech Trend Trove on May 26, 2026 at 1:46 AM […] Source: Hacker News […] Posted by When the Tool Became the Threat: AI Writes Better Code, Steals Better Files, and Nobody Can Prove the ROI - 🦞LobsterBlog on May 26, 2026 at 3:14 AM […] Lawson published a piece this weekend called Using AI to Write Better Code More Slowly, and it landed on Hacker News at 646 points because it says something that should be obvious but […]
Posted by Axora.AI on May 26, 2026 at 4:45 AM Completely agree with this. AI becomes far more valuable when it’s used to improve code quality, identify hidden issues, and strengthen long-term stability rather than just speeding up development. At Axora.AI we believe in slower, thoughtful development with AI support can often lead to much better products.
Posted by Ollie on May 26, 2026 at 5:07 AM This matches my experience closely. I’ve been building a voting app with Next.js and Supabase, and the most valuable thing an agent did wasn’t write features — it was flag that my RLS policies had a gap I hadn’t considered. I would have shipped that. Fixing it took a few hours and sent me down a rabbit hole on Postgres row-level security I didn’t expect to go down that week.Not a productivity win by any typical metric. But now I actually understand that part of the stack. The “pre-existing bugs as a side quest” description is exactly right — and honestly it’s more satisfying than the feature work. Leave a comment Cancel reply Δ Recent Posts Using AI to write better code more slowly The diminished art of coding You had a story Days of miracle and wonder We mourn our craft About MeI'm Nolan, a programmer from Seattle working at Socket. All opinions are my own. Photo by Cătălin Mariș.Archives May 2026 (1) Tagsaccessibility Mastodon GitHub npm Blog at WordPress.com. Comment Reblog Subscribe Subscribed Read the Tea Leaves Join 1,321 other subscribers
Sign me up Already have a WordPress.com account? Log in now.
Read the Tea Leaves Subscribe Subscribed Sign up Copy shortlink Report this content View post in Reader Manage subscriptions Collapse this bar |
The author Nolan Lawson posits a counterargument to the prevalent belief that using artificial intelligence for coding should prioritize speed, arguing instead for a more deliberate, slower approach that results in higher quality code. Lawson suggests that Large Language Models (LLMs) are highly flexible and can be utilized effectively to enhance code quality rather than simply generating rapid, low-quality output. The core insight presented is that LLM agents are adept at discovering bugs within a codebase if provided sufficient repeated exposure, and the true challenge lies in the subsequent prioritization and validation of these discovered issues. Lawson details a specific skill adapted from this concept, which involves using multiple, distinct models and agents to review a pull request, thereby mitigating hallucinations or false positive bug reports. This technique involves running agents like a Claude sub-agent, Codex, and a Cursor Bugbot across a submission, assigning the resulting bugs a severity ranking of critical, high, medium, and low. Following the bug detection, the developer must engage in rigorous self-research to validate findings and create a final report. Lawson notes that this process consistently uncovers numerous bugs, ranging from critical security flaws to subtle performance issues and misleading comments, often resulting in a finding that the initial assumption about the happy path of the architecture was flawed. The typical workflow advocates for addressing critical and high-priority issues first, while strategically skipping medium-level fixes that do not offer proportionate benefit. If a pull request contains an excessive number of critical findings, the developer is advised to reconsider the entire approach. Lawson observes that this methodology does not necessarily increase raw lines of code written per unit of time. Instead, the process often forces the developer down tangential paths, engaging them in writing unit tests and fixing pre-existing flaws that predate the initial request. This side quest, Lawson suggests, is more satisfying than pure feature development because it fosters a deeper understanding of the codebase's failure modes, a perspective he argues is often more instructive than understanding a complex architecture’s ideal operation. The post concludes by urging developers who feel skeptical about AI coding to adopt a slower, more methodical style. Lawson advocates for using agents not as standalone solutions but as tools to probe the system—asking how a pull request functions and where it might fail, or generating supplementary documentation using tools like Mermaid charts. The emphasis is placed on enablement and governance, stressing that the LLM's output is merely a first draft, and the essential work commences during the subsequent, intensive code review phase. Lawson ultimately frames this slower methodology as a more sophisticated form of programming, focusing on carefulness, quality obsession, and improving the codebase for future maintainers. |