A code inspection of 'serious' LLM-generated code An IfSQ code inspection of a 140,000-line C++ visual modelling application written almost entirely by Claude Code found that LLM-generated code contains serious defects, though LLMs outperformed IfSQ at unearthing certain problems, according to Lab Note #6 from ea.rna.nl. The author reports that more than 50% of his energy now goes to quality and defects rather than features, and that fixing the flagged problems is possible but gradually degrades the effectiveness of coding with LLMs. The project also includes about 15,000 lines of stable documentation and 30,000 lines of temporary documentation, and the author concludes that LLM agents "will in no way be able to replace actual human engineers. Special note for subscribers who get this in the mail: this is an extremely long post because it contains two entire python scripts I use and that some may want to download and a large document that is part of my ‘contextual harness’. There is nothing I can do about that. This one is easier to read on my site where these long segments are within a small scroll box. To find out more about the reality of all the generally overblown promises about LLMs, I have been doing a very serious experiment on the poster child for Generative AI: coding . I wrote one critical post https://ea.rna.nl/2026/06/07/anthropic-openai-may-be-spending-more-than-1000-for-every-100-you-pay-them/ , and I am close to writing up my conclusions, but I am hitting some work that I have to do first before I can publish that e.g. create a demo video which is a lot of work, and before that I need to finish some final functionalities and improvements. This is Lab Note 6. Some basic explanations about my setup are in Lab Note 1 https://ea.rna.nl/2026/09/26/serious-coding-with-llms-lab-notes-2026-09-25-codex-vs-claude-code-usage-limit-resets/ . Some basic technical notes on tokens, context are in Lab Note 5 https://ea.rna.nl/2026/10/21/serious-coding-with-llms-lab-notes-2026-10-21-the-throttling-of-subscriptions-by-openai-and-anthropic-is-really-happening/ . Experiment : As an experiment to learn about the limits of LLM-coding, I am building a professional visual modelling application from the ground up. It can handle multiple grammars definable in JSON . It has state of the art graphics. It is rich in what users can influence and how e.g. schemes, style/colour/geometry properties . It is responsive. It is well documented. It has a solid software architecture. Every line of code and many of the other texts have been generated by the LLM so far almost exclusively Claude Code . It runs on macOS and Windows Linux will be added later . If I finish it and I am satisfied, it will be open sourced. This is a serious sized project: 140k lines C++, about 15k lines stable documentation and 30k lines of temporary documentation analysis, design and planning for substantial changes over the last half year , so about one third of what is in play is not code but documentation. Warning : That I am doing this should not be read as either pro or contra coding with LLM-agents. I am highly critical of the hype, but I am trying to establish the limits of LLM-coding based on as serious a use case as possible. I can say already that my experience so far has let me conclude that LLM-agents will in no way be able to replace actual human engineers. Note , these lab notes do not explain all technical details. I generally try to write for a general audience, but if you’re not a software engineer you’ll need to kind of ‘read over’ everything you do not understand, but you can still get the gist of it. This is an extremely long and detailed note. Sorry for that. So, let’s do a TL;DR A review based on the IfSQ method brought to light that LLMs are better than IfSQ in unearthing certain problems, but also that the code that LLMs generate have serious problems that were unearthed by IfSQ. Attacking those problems is possible, but it slowly degrades the effectiveness of coding with LLMs. For a software engineer, the experience of coding with LLMs remains a somewhat awe-inspiring experience, but that is in part typical shallow human judgement. Underneath, reality bites. By now, more than 50% of my energy goes to quality and defects, not features. I can do more than I ever did, but for how long? Next time I will report on how much better the code got after Claude reworked it based on the inspection results. And if you get this by mail as a — very appreciated — subscriber, this one you should read on the web as the large amounts of code aren’t in scroll-boxes in that email. Before we start: Slop, Sludge and ‘Vakwerk’ A month ago, Michael Larabel wrote AI Made A Lot Of “Hideous” Code But Found Major Bottlenecks For Faster Linux Compilation https://www.phoronix.com/news/AI-To-Faster-Linux-Kernel-Comp . In it, he relates the observations by a Linux kernel engineer, Lorenzo Stoakes, about the combination of the effects of LLM-coding that has struck many: the code may work but it can be hideous . Another example is this item from a Linux kernel graphics development GitLab repository: iMac 5K shows only 1 tile 2560×2880 instead of a 2 tile display 5120×2880 https://gitlab.freedesktop.org/drm/amd/-/work items/4455 note 3728748 , which started out with a 1500 lines of code LLM-assisted patch, which was brought back to 50 lines and might even become only 25 lines of code. This kind of echoes the paper OpenAI released on a quasi-Riemann proof which is an important result, but the 200-page paper produced by the LLM would be rejected by a journal because, while the math checks out mechanically checked by LEAN , it was extremely poorly written. A 49-page version from OpenAI with a slightly different proof with a smaller but still important result was edited by a human. According to reports https://www.quantamagazine.org/ai-proved-the-quasi-riemann-hypothesis-what-happens-now-20261019/ it might be possible to bring that size substantially down further. We all know AI-slop by now. AI-generated results that are so poor that — often without humans noticing — they do more harm than good. But in mathematics we have those results mentioned above. Results that check out are correct but the form is poor. I am reminded of the use of the word ‘sludge’ as defined by Cass R. Sunstein of Harvard University here https://papers.ssrn.com/sol3/papers.cfm?abstract id=3379367 . Sludge as a form of friction. If LLMs generate, we might classify them into the following three categories, broadly: 1. AI- Slop : Generated results that are incorrect. The cheap model results are often that; 2. AI- Sludge : Generated results that are correct, but roundabout, bloated, ‘kludgy’ way; 3. AI- Vakwerk : This is what we want and are being sold… .Vakwerk means ‘result of a skilful job’. But it has a second meaning that is ‘truss’ which is a sturdy structure. I have tried to come up with something in English or well known in English, but even with all the suggestions an LLM could make I found none better than this. All languages have the meaning, but none like Dutch. So, let’s propose this as a loan-word. I considered ‘AI-solidity’ my 2 , ‘AI-art’, and many more . My project is an experiment to get vakwerk solid results from coding with LLMs, which in themselves are stochastic, so there is a fundamental contradiction we are confronting. The Code Audit As I wrote in Lab Note 4, I recently had the code from Claude inspected at IfSQ Level 2 https://ifsq.org/level-2.html . IfSQ stands for “The Institute for Software Quality” and it is a method based on visual inspection by an experienced engineer that provides a measure of maintainability : analysability, modifiability, testability, modularity, reusability. IfSQ is directed at inspecting code created by humans and to be maintained by humans . The latter is important as I expect the economics of LLMs is going to be a fundamental problem that limits their usefulness in many if not most, we will see cases. LLMs are hideously inefficient in more ways than one, but they are currently extremely heavily subsidised https://ea.rna.nl/2026/06/07/anthropic-openai-may-be-spending-more-than-1000-for-every-100-you-pay-them/ , mostly by venture capital and private credit. So, my project has a stated goal: the code must be maintainable by humans I try to be prepared for when the serious models become unaffordable for me when the party is over, and we also might take future software engineers’ conundrums into account — more on that a next time . In IfSQ, a code sample is collected and audited on a couple of aspects: 1. Work in Progress WIP , such as TODO statements in comments in the code, disabled code, an empty block left open for later; 2. Structured Programming SP : too long routines, too deep nesting, too complex routine; 3. Single Point of Maintenance SPM : Magic Numbers or Strings, Copy/Paste programming, the latter is known by its acronym DRY : Do not Repeat Yourself. Copy-pasting code is a recipe for maintenance issues as changing the code easily leads to forgetting one or two copies; 4. Defensive Programming DP : Parameters not checked, return value ignored, unexpected state not trapped e.g. a switch statement without a default: clause . You can easily get false positives here, there are many if statements that are fine without an else . “Do this if that, else do nothing” is a fine flow. So, you need to inspect which is the case and that isn’t mechanical, it requires understanding code hence human in the loop . 5. Causes for Concern CfC : Apparent missing functionality, apparent wrong results, hard to maintain. These are not part of a Level 2 inspection, but they can be part of a more heavy ‘review’. I’m getting back to that below. An overall rating goes from AAA best , via AA,A,B,C,D,E,F,FF, to FFF worst , based on the estimated number of defects per thousand lines of code. I’ve worked on such an audit myself once, about twenty years ago and I’ve been using one during my time as Lead Architect for the Judiciary of The Netherlands two decades ago. I then found IfSQ to be one of the better ways to audit code quality, so I decided to ask originator of this method — Graham Bolton http://linkedin.com/in/gbolton — if he wanted to play along today. He did. Graham has created some tools to support this form of an audit, but in the end the judgement remains a human judgement. Supported by the tools, however, he could quickly inspect about half of the code. The idea of this kind of audit is not just simply a measurement. It is a result that is meant to be discussed with the engineers. When we used such an audit twenty years ago, you could see the junior engineers fight its findings “come on, how bad is that” while experienced, senior engineers shifted nervously in their chairs as they recognised how bad the findings were for the future of a system. Graham confronted them with what they already understood but had ignored. So, I worded the result of the audit and gave that back to Claude to work with. Caveat: Graham did a quick and rough version of the inspection still a lot of work — thanks, Graham so the tools he uses bring up candidates to look at, but as a human he has to check these if the candidates are really issues. So, we will have some false positives as Graham did a quick scan and not a one-by-one deep analysis of the candidates. As an example, an if statement not followed by an else statement is a potential issue an issue with defensive programming, an unexpected result is not handled and the program simply runs on in a broken state after which everything can go wrong . A switch statement without a default: label is too. But there are many situations where this is not true. Using a hard coded number e.g. distance from border: 6 points in code is a bad sign for maintenance, because if you change it in one place, will you not forget it to change it somewhere else , while code that finds the center of a box by dividing height and width by 2.0 is not an issue. The result of the IFSQ inspection on my LLM-generated code was interesting and helpful. To start with: the overall score was FF. Which looks bad, obviously. Here is the overall result: So, why was it so bad? What did Graham’s IfSQ audit flag? And given that the audit is based on human creators, how bad is this result if you just keep using an LLM which maybe isn’t bothered by these scores at all? Let’s answer all of these. IfSQ finding: Work in Progress WIP : Perfect IfSQ’s WIP-detection is very limited. It looks for things like dead code, TODO statements in comments, that sort of thing. That is behaviour that is typical for poor or too much under stress coders, not for LLMs generating code. An LLM is ‘often wrong, never in doubt’, so it will not leave something like that in the code like an uncertain human would. IfSQ finding: Defensive Programming DP : OK My code quality document that is part of Claude’s context which I will share , already is built to direct Claude at producing robust and self-documenting code. As the development has proceeded I have often had to correct Claude to improve the quality, and such findings then found their way into my ‘stable documentation’. In the case of if and else , my instructions before the audit were already that any if should either have an else , or a comment documenting why an ‘else’ is not required here. Example: if EACMP replaceFieldStateValue ordinaryViewFields, EACMP ViewField::CanvasBounds, std::optional