Daniël Franke :panheart:ainmosni@ainmosni.eu
Aug 10, 2026, 12:46 PMEvery time I have to look through LLM generated code, I'm amazed that anybody would prefer fixing that than just writing it themselves.
Replies
Krisisotopp@infosec.exchangeAug 10, 2026, 12:51 PMI had that impression when I read code generated by early C-compilers such as Amiga Aztec C, but that changed radically when I saw the output from Atari Turbo-C.
What I see currently as LLM generated code alternates between the two extremes.
- Daniël Franke :panheart:ainmosni@ainmosni.euAug 10, 2026, 1:12 PM
@isotopp It might improve, but I'm not sure if it'd really get to a dependable state. English is not a great descriptive language for the tasks we want to do in computing, it never has been, and it never will. Hell, we have decades of processes to make sure an actual thinking human understands the specification properly, I don't think these statistical models will rival that any time soon.
I remain sceptical, as I think this will in the end turn out to be an unproductive avenue, as creation of code has never been the bottleneck, and, generating more code, especially the type of code that needs more in-depth review scrutiny, does not solve the actual bottlenecks we have.
That's not to say that I think all AI is bad, I see a lot of value in using adjacent technologies for detection of things in ways that humans are just inherently bad at. Be it as an advanced linter, or as something interpreting medical data and flagging stuff that looks out of the ordinary.
But the current genAI craze is doing so much damage to so many things in our society, that, even if it was fully reliable for code, I wouldn't say it's been worth it.
Aug 10, 2026, 1:40 PM- Krisisotopp@infosec.exchangeAug 10, 2026, 3:57 PM
The image generator application I have generated uses a vite driven typescript application that has tests and everything.
I have zero frontend knowledge (but I can read enough typescript to follow along). This was very enabling.
The python backend is fine (Flask, ruff, ty, pytest, the works).
- Krisisotopp@infosec.exchangeAug 10, 2026, 1:44 PM
English is not a great descriptive language for the tasks we want to do in computing, it never has been, and it never will.
Yet we use this to write specifications, user stories, and tickets. And the outcome of that, from the point of a view of a product manager or product owner, is not reproducible, because the same tasks with the same language when given to two different teams, produce different code, and maybe even different behavior, and that is what we use and have been using, in the last 50 years.
Using a LLM, from the PoV of a PO or PM, makes exactly zero difference.
The LLM workflow that does work mirrors the team workflow pretty much.
- Create a skill repository in the projects git repo. Put skills for test driven development, git-commit and whatever subject matter specific support is needed into the repo so that all team members use identical instructions.
- Create a directory in the repo to hold all LLM instructions, for example
/developmentor something. For each epic put a subdirectory, and inside, create auser-stories.mdwith structured user stories for whatever behavior you want. This file will likely contain garbage and needs multiple reviews from several stakeholders. The more work is done here, the less painfull the end result will be. - Create a
tickets.mdfrom theuser-stories.mdusing the TDD skill. The tickets must be actionable and in implementation order.
Both step 2 and 3 should be done with a high-end model, sol medium or similar.
- Have the model implement the tickets in order, using the TDD skill, and the git commit skill. If the
tickets.mdinstructions are good, this can be done with a cheap model at a high "thinking level" (luna high or xhigh).
The TDD skill will force the model to implement tests, and if the TDD skill is good, will ask the model (already in the tickets planning phase) to identify architectural boundaries, and to specifiy definition-of-done tests that are independent of refactoring - the skill can reference GOOS or other books on the subject matter, the model knows them.
The TDD skill will then force the model to lock the tests and write code until the tests turn green. It is therefore useful to read the tests at least cursory to understand the shape of the API seams and the coverage. This ultimately what drives code quality and overall shape.
This pretty much mirrors the work that a PO or PM with a technical background does when working with a team. And again, from a PO/PM PoV, the results are usually not the worst if compared to team output.
- Daniël Franke :panheart:ainmosni@ainmosni.euAug 10, 2026, 2:48 PM
@isotopp I don't have time to go super in depth, but here's a few observations, and that's ignoring the horrible externalities of LLMs, which should invalidate their use to begin with.
- A healthy product development cycle has information going both ways, the engineering team will have notes on the specifications, will say when things are impractical, will ask for clarification, and will do more than just blindly bash out based on a spec.
- Your flow puts a lot of faith in the models getting a lot of things right, and not just making it look right. Nothing is stopping the models from just creating tests that just return true, and have the end result be just an expensive mock up.
- In tandem with the previous point, you are right that from a non-technical PO/PM PoV this will look exactly the same, as they are not in any position to say that this product is actually good. They can just see that it looks like it does what they told it to do, but they're in no way able to see if the thing is in any way ready to be put live.
- You could pay engineers to check the code, but this is in many ways harder work for the engineers, because reviewing code is just more difficult, as it's very tedious work, and as LLMs make different styles of errors than humans would, it's even harder work. And then you're both paying for the LLM tokens, and for the engineers.
- Krisisotopp@infosec.exchangeAug 10, 2026, 3:47 PM
2 – yes. Review tests. They are actually readable. I just demonstrated that in a real world example to somebody, using their code, in a live coding session.
4 – You can also use the model to explore the codebase. We just did that in that test session, they brought their code, we structured it, and modernized it, adding tests.No, this does not look like code I would have written, but then, compiler generated assembly also does not look like code that I would have written back in the day.
3 – That is the promise of TDD; the tests encode a kind of spec, if it greens the tests, it complies with the spec. It is the tool that PO/PM use to see if the code delivered is valid. So read the tests (and the artifacts that have been used to produce them).
1 – The back channel now looks different, again, if you are willing to spend. Instead of deciding on one implementation, create all of them, then choose the one you like best.The results are good enough. I have half a dozen tools in production that I have created this way, and as a workflow it produces "good enough" code for most general purpose use-cases.
I have had my failures. Numerical code that requires conditioning and makes use of compiler dependent operation order to achieve accurate results is impossible to hand off to a model (A bspline interpolator that needs 1E-14 accuracy to pass and that needed to be ported from Intel to ARM, was an utter failure for the model).
But
- a deploy tool that automates web server config generation for static html, flask and go projects, reverse proxy setups, mod_md integration etc
- a combined python and javascript project that provides a web application to drive image generation
- a simulator for a house battery getting data from influx, running what-if scenarios for various batteries
- a command line tool to download Kobo EPUB and them remove Adobe ADEPT encryption from them
- a command line tool to joinly manage and synchronize my dhcp and unbound configuration files, automatically detecing home ip changes and fixing things
- a reverse engineering of my existing server deployment and generating ansible to reproduce it on a second host
have all worked fine using such a PO/PM workflow with results that, when read, are good enough to pass. In some cases (the ansible, specifically) I had to set boundaries to prevent a complexity explosion (in ansible we use the trifecta, anything else becomes a python cmdline tool that we deploy using the trifecta and then use).
Overall, this is reliable, productive, and if you are willing to spend, very fast. If you are used to PM/PO work, it matches naturally, and covers the expectations you might already have. If you look at it with a software developer mindset it will of course to match, but that is irrelevant in the context of the evaluation.
There is a secondary workflow, that creates code analysis, review and makes change and improvement suggestions that is semi-useful. It requires a lot more energy and very thoughtful selection of the suggestions, but it does surface enough useful stuff so that the workflow has use.
Overall, nobody has to LIKE that. Nobody asked if anybode likes compilers.
The question is, is it useful, and the answer is demonstrably yes.
The next question is, is it financially viable, and that is unclear – there is a market and there are current prices, and at these price levels it is indeed viable.
If the prices were changes to post-bubble pricing, likely not.
On the other hand the entire tech is not a finished product, and there is easily a two orders of magnitude efficiency win possible. If that was realized, what is currently running on an 8-card NVidia cluster will be running on a laptop with 128 GB.
This must happen, in order to become profitable.
This must not happen, in order to not destroy the AIaaS use case.
Hence
- the current cornering of the RAM and Flash markets. You must not be able to casually and at scale build an inference farm.
- the current "my model cybered the solution to a benchmark after breaking the sandbox". The goal is to require use only of checked, centrally run models, cementing AIaaS through regulatory lock-in.