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, 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 #7. Some basic explanations about my setup are in Lab Note #1. Some basic technical notes (on tokens, context) are in Lab Note #5.
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.
The actual application build I used as a testbed for testing how far I could get with building an LLM-generated application is a portable, data-driven, visual, business-landscape modelling application. The main reasons for this choice were:
- Modelling grammars like ArchiMate, BPMN, can be complicated. Add to this that I want the grammars to be defined as loadable data — so it is easy to add your own if need be — the engine on the inside becomes very complex code;
- Graphics is hard on LLMs, after all they cannot really ‘see’ (yes, I know, there are ways around this, but they are limited);
- And finally: I can use this myself (even if I will share this as open source as soon as I feel it is polished enough).
I am not going to explain it all here (the manuals alone run at ~8k lines, so you can guess there is some stuff to discover), at this stage I am going to present a teaser of what the application is capable of now. The teasers (one macOS, one Windows) are speed-runs of a set of 25 tests of the manual user interface, so they are not created as showcases but as checks. In total the project has 131 tests as it stands today.
Yes, I am taking ‘serious’ in ‘serious coding’ seriously.
One important point I have to make: The app itself has no knowledge of any grammar, except a very basic one that is integrated with the code (base grammar and C++ code change in sync in support of some fundamental capabilities) and that has inheritable parts for other grammars. I do not claim that the grammars I ship with this app are ArchiMate ® or BPMN™ compliant. But I can tell you that my Alike32 grammar and Alike40 grammars can import and export ArchiMate Open Exchange files and BPMN files.
Some other noteworthy requirements are:
- It has a separation of the logic of visual modelling and the presentation. Most of the actual work done — also on views, note — is independent of the actual presentation layer. Basically this enable one to add different frontends (e.g. Web, mobile, command line/batch), embed the logic in other systems, create servers, etc. One frontend is delivered (desktop) for multiple OS’s (macOS, Windows, Linux, the latter one is in the project setup stage) and one backend: files. Note that the system is such that landscapes can work fully in memory, and a future collaboration between multiple instances is foreseen by having one server-frontend act as a server for all different concurrent clients.
- It should be maintainable by humans, that is: understandable code that is robust under change;
- The visualisations must be the best there can be. The exported output (e.g. PDF) should be impeccable (or I cannot use it for my book). The visualisations must be on par with my batch process that uses LuaMetaTeX (LMTX) to produce the best graphical output I can make (see here).
- It should perform well. Landscapes with 200k elements and relations, views with 300 elements and relations, should perform snappily (they do…);
Quiz for those that model regularly: Spot the capabilities
I am going to turn this post into a quiz of sorts. From watching a video (either one), can you spot what the capabilities are? If so, add them in the comments and I’ll react. Which capabilities surprise you the most? For some capabilities, you probably need to go frame by frame. And can you spot details I still need to improve?
The videos show everything what is happening, except for the main menu actions (which it informs about instead of showing them) as enabling that on especially macOS requires more (complex) development.
Here are the teaser videos (you will need to watch them full screen on a large screen to actually be able to see what is going on):
Previously on the LLM-coding experiment:
• First report: Anthropic/OpenAI may be spending more than $1000 for every $100 you pay them (7 June 2026)
• Lab Note #1: Serious coding with LLMs. Lab notes 2026-09-25: Codex vs Claude Code, Usage Limit Resets (25 September 2026)
• Lab Note #2: Serious coding with LLMs. Lab notes 2026-09-27: Codex succeeds, Claude reviews the result. (27 September 2026)
• Lab Note #3: Serious coding with LLMs. Lab notes 2026-10-01: Codex and Claude generate a shared analysis (1 October 2026)
• Lab Note #4: Serious coding with LLMs. Lab notes 2026-10-13: Codex vs Claude on the same coding task. (13 October 2026)
• Lab Note #5: Serious coding with LLMs. Lab notes 2026-10-21: The throttling of subscriptions by OpenAI and Anthropic is really happening. (21 Oct 2026)
Lab Note #6: Serious coding with LLMs. Lab notes 2026-10-27: A code audit of LLM-generated code: improving from ‘sludge’ to ‘vakwerk’. (27 Oct 2026)
Subscribe? I don’t know if I am going to publish the appearance of new notes every time everywhere (it is a drag), so best to keep up to date with my observations and analysis on the Information Revolution is to subscribe (top right). You’ll get an email whenever I publish. These Lab Note are on a pretty high frequency schedule so far, but normally I haven’t been doing more than 1-2 a month.
(I also like to be read. Share?)
[You do not have my permission to use any content on this site for training a Generative AI (or any comparable use), unless you can guarantee your system never misrepresents my content and provides a proper reference (URL) to the original in its output. If you want to use it in any other way, you need my explicit permission]
