[{"data":1,"prerenderedAt":219},["ShallowReactive",2],{"blog-post-/blogs/what-ai-code-can-change":3},{"id":4,"title":5,"body":6,"description":201,"extension":202,"meta":203,"navigation":214,"ogImage":205,"path":215,"seo":216,"stem":217,"__hash__":218},"en/blogs/en/29.what-ai-code-can-change.md","Should You Read AI-Generated Code? Ask What It Is Allowed to Change",{"type":7,"value":8,"toc":194},"minimal",[9,21,36,45,53,56,59,62,65,70,75,78,81,84,87,90,93,96,99,106,109,113,116,123,126,129,132,135,163,169,172,175,178,182,185,188,191],[10,11,12,13,20],"p",{},"A recent ",[14,15,19],"a",{"href":16,"rel":17},"https://www.youtube.com/watch?v=Hh3AmV46epI",[18],"nofollow","argument about whether engineers should read AI-generated code"," caught my attention.",[10,22,23,24,29,30,35],{},"Mitchell Hashimoto's answer was four words: ",[14,25,28],{"href":26,"rel":27},"https://x.com/mitchellh/status/2072738025344565262",[18],"“I read the code.”"," He had just ",[14,31,34],{"href":32,"rel":33},"https://x.com/mitchellh/status/2072715852944957531",[18],"described a workflow"," in which one model planned, another implemented, and another judged the result. His final quality gate was still source comprehension.",[10,37,38,39,44],{},"Elsewhere, he drew a broader boundary: unread private code is one thing; ",[14,40,43],{"href":41,"rel":42},"https://x.com/mitchellh/status/2067970516951150721",[18],"handing AI-generated work to another maintainer is another",".",[10,46,47,48],{},"Uncle Bob took nearly the opposite position. He said he does not read the implementation his agents produce. Instead, he invests in specifications, unit tests, Gherkin acceptance tests, mutation testing, quality metrics, QA, and final verification. His definition of the engineer's role was equally direct: ",[14,49,52],{"href":50,"rel":51},"https://x.com/unclebobmartin/status/2080257779395154409",[18],"“I am the engineer because I am accountable.”",[10,54,55],{},"The discussion quickly exposed two competing claims.",[10,57,58],{},"One side argued that unread code cannot be responsibly maintained or debugged. The other asked what productivity AI provides if an engineer still has to inspect every generated line.",[10,60,61],{},"Both arguments are reasonable. Mitchell keeps human understanding close to the implementation. Uncle Bob moves much of it into the specification and evidence. They agree that a human owns the result, but disagree about how much source comprehension that ownership requires.",[10,63,64],{},"That disagreement is not theoretical for me.",[66,67],"youtube-embed",{"title":68,"videoId":69},"Should You Read AI-Generated Code?","vlCfO_EjF8k",[71,72,74],"h2",{"id":73},"the-question-changes-at-work","The question changes at work",[10,76,77],{},"I do not read every line of every AI-generated artifact.",[10,79,80],{},"AI lets me delegate more implementation than I can inspect at equal depth. The practical challenge is deciding where outcome-level confidence is enough and where I need a system model.",[10,82,83],{},"For a private prototype, a one-off analysis, or a script I can discard, I may inspect the output, run the tests, and move on. The consequences are bounded and recovery is simple.",[10,85,86],{},"My behavior changes when AI touches a critical system or a system of record.",[10,88,89],{},"A critical system matters because failure has serious consequences. A system of record matters because other people and systems treat its state as authoritative. The two often overlap, but they create different risks.",[10,91,92],{},"Five lines that change a permission, account balance, customer status, or migration can deserve more attention than a thousand lines of disposable interface code. The size of the diff tells me little about the size of the consequence.",[10,94,95],{},"Consider a normalization function. If it cleans a copied CSV, a bad result can be discarded. If the same function writes into a system of record, the value may flow into reports, permissions, customer communication, and automated decisions.",[10,97,98],{},"Reverting the code may stop the next bad write. It does not necessarily restore corrupted records, downstream copies, audit history, or decisions already made.",[10,100,101],{},[102,103],"img",{"alt":104,"src":105},"A retracted code strip beside a ledger whose marked state has already propagated to three downstream records","/blogs-img/2026-08-02-ai-code-01.webp",[10,107,108],{},"I do not have a dramatic incident behind this rule. That is the point. The boundary needs to exist before the incident.",[71,110,112],{"id":111},"my-view-review-depth-should-follow-authority","My view: review depth should follow authority",[10,114,115],{},"The wrong question is whether engineers should read AI-generated code.",[10,117,118,119],{},"My question is: ",[120,121,122],"strong",{},"What is this code allowed to change?",[10,124,125],{},"Review depth should not be set by who wrote the code or how many lines changed. It should follow the authority of the change, who inherits the consequences, and whether failure can be detected and repaired.",[10,127,128],{},"Reading and testing both matter, but they fail differently. Reading builds the system model needed for maintenance and unusual failures; it does not prove correctness. Tests create repeatable evidence at scale; they only exercise expectations we encoded. If the implementation, tests, and review all come from the same AI context, they can also repeat the same mistaken assumption.",[10,130,131],{},"Reading less has another cost: a team can lose its shared model of the system. That is why production and critical changes cannot rely on test evidence alone.",[10,133,134],{},"So I use four levels of review:",[136,137,138,145,151,157],"ul",{},[139,140,141,144],"li",{},[120,142,143],{},"Outcome:"," For private, disposable, reversible work, verify the result.",[139,146,147,150],{},[120,148,149],{},"Evidence:"," When another person or process depends on the output, inspect tests, logs, CI, and checks that bring a different method or context.",[139,152,153,156],{},[120,154,155],{},"System model:"," For production behavior or authoritative state, someone accountable must explain the data flow, business invariants, failure propagation, observability, and recovery.",[139,158,159,162],{},[120,160,161],{},"Critical path:"," For permissions, money, privacy, deletion, migrations, security, or system-of-record writes, understand the relevant source path.",[10,164,165],{},[102,166],{"alt":167,"src":168},"Review depth rises from Outcome to Evidence, System Model, and Critical Path as changes become more authoritative","/blogs-img/2026-08-02-ai-code-02.webp",[10,170,171],{},"The levels are cumulative. Reading the critical path does not replace testing, and green tests do not replace understanding the state transition.",[10,173,174],{},"In my work, a system-of-record change starts at the system-model level. Its critical write path usually requires source-level understanding.",[10,176,177],{},"My release rule is simple: no named owner, no reviewed write path, no explicit business invariants, and no credible reconciliation and recovery plan means no release.",[71,179,181],{"id":180},"ownership-means-owning-the-state-transition","Ownership means owning the state transition",[10,183,184],{},"AI lowers the cost of implementation. It does not lower the cost of consequences.",[10,186,187],{},"We cannot read every generated line with equal intensity. We also cannot let unread code become somebody else's problem. The practical decision is where human understanding must be deepest.",[10,189,190],{},"I do not need to understand every line an AI writes. But if the code can rewrite what a business treats as true—or create consequences the business cannot accept—someone accountable must understand how the state changes, what must remain invariant, how it can fail, and how reality will be restored.",[10,192,193],{},"Before accepting an AI-generated change, I now ask: if every test is green and the world is still wrong, who can explain why—and restore the truth?",{"title":195,"searchDepth":196,"depth":196,"links":197},"",2,[198,199,200],{"id":73,"depth":196,"text":74},{"id":111,"depth":196,"text":112},{"id":180,"depth":196,"text":181},"A practical framework for deciding how deeply humans should review AI-generated code, based on the authority and consequences of the change.","md",{"date":204,"image":205,"alt":206,"category":207,"tags":208,"youtube":213,"published":214},"2nd Aug 2026","/blogs-img/2026-08-02-ai-code-cover.webp","A human hand guides a provisional code strip through an authority gate where it becomes trusted records","ai-native-systems",[209,210,211,212],"ai-coding","code-review","system-of-record","accountability","https://youtu.be/vlCfO_EjF8k",true,"/blogs/en/what-ai-code-can-change",{"title":5,"description":201},"blogs/en/29.what-ai-code-can-change","E95u_fKFNE52GzBiDrjltIQ1Eb5fR5E8by-EuYJAbPg",1785813535021]