Code profiling tools are everything now.

When I was staring at Thaura writing code, it was doing some wild tricks with python and grep and other unix tools that I’d never seen before.

So I told it to write tools to do simple kinds of code analysis, to help map out and index the code. I also wrote scoreboard database tools, to keep track of work to do, and work completed. I had it put the code analysis info into the database, too.

I also asked it to tell me about all the PHP static analysis tools, and enlisted them all into the programming process: linters, code stylers, static type analysis.

The LLM can use these tools the way we use them, to understand the code, and to demonstrate that code conforms to some idea of “order”.

The LLM also uses them as a kind of debugging aid, or a pre-run tester.

I also leaned on Playwright and the old reliable PHPUnit.

Illusions of Complete Coverage, and “AI Psychosis”

The problem with these code analysis tools is: they don’t enforce writing good code as much as assist with it. They mainly help when the code is big enough to forget parts of it.

They give you the illusion of total control, when you’re just keeping things together.

Likewise, the LLM will appear to be making great, sweeping changes over the code, but touching only a fraction of it, leaving lots of code untouched, and report back with a chat message that it did a lot of work.

The LLM straight up bullshitted the boss!

I totally fell for it.

The problems would trigger errors and warnings, and then the LLM would look at the errant code, and go fix it, with some chatter about how it was still doing the old thing, when it should be doing the new thing.

Then it was fixed, passed the test, looks good in the analysis tools, and the LLM moved on, and I moved on.

The post Thaura: Porting Legacy PHP5 and PHP7 Project to PHP8 Part 5 first appeared on 🍙.

Continuing the series, more info about altering project internals.

I think of this like a caterpillar going into a cocoon, having enzymes totally disintegrate its guts, and then produce a butterfly, which will go out and mate with other butterfiles. It’s a metamorphosis. Except, with this software, you don’t see any visible changes once it’s changed.

So that’s not a good analogy.

Maybe it’s more like an electric car, which looks as ugly as the gasoline cars, or even worse, but has completely different insides. It’s better on the inside.

Another bad analogy.

It’s like you shoved a seed into a pile of manure, and it’s started to grow, but you still can’t see the plant. It just looks like a pile of shit. But there’s good stuff in there.

Yes, that’s it.

I’m going to do another release of software.

I’ll just call it r2 or release 2….

Here’s what happened. It took all day. The reasons were noted in the email I sent out, but the actual delays were as follows:

The instructions that the LLM wrote were not easy to understand. In retrospect, I should have just hand-written them.

(Then, those notes could have become part of the LLMs knowledge, and could have influenced it to write better documents.)

Cloning the database was smooth, but getting the live database container updated to a newer version of MariaDB took extra time.

Cloning the release from Git was quick. Moving it into place was quick. (Name the new clone directory blahblah.new, then mv blahblah to blahbla.old, then mv blahblah.new blahblah. Restart Nginx, restart the php container.)

Configuring the Nginx proxy took a LOT of effort, because I did it too soon. The examples the LLM created were wrong, as well, but had enough info that I could make it work.

Reconfiguring the containers to run the app was pretty simple, but I had forgotten that I changed the paths where I wanted the files mounted. This sent me down some rabbitholes related to Nginx config. (I should have held back on changing Nginx.)

Overall, it wasn’t that bad, except for the Nginx configuration.

A New, Nonfunctional API

I made an API to feed the mobile app, and it didn’t work. Digging into the code, was a minor horror. The LLM wrote code well, but the overall “separation of concerns” and keeping the code in the right places, wasn’t so great.

I forget what the fix was, but it eventually worked. It was a combination of fixing some obsolete SQL code, and making an Nginx config.

PHP Attack Scripts

The PHP security hole drama has led to a bit more attack against the sites, particularly scans for remote shells written in PHP.

That just overloads the server, even when the scripts aren’t there.

So I had to do some tricks to detect these requests, and block them. This took a few hours.

Get Rid of phpinfo()

If you’re running PHP in a container, and use .env to pass passwords into your container, it’s critical to find and remove all instances of scripts that use the phpinfo() function.

That function dumps the environment variables to the page, leaking credentials. This command will recursively find the string “phpinfo” in all your files.

grep -r phpinfo *

Archives

One of my big goals was to get the site into shape for archving. This entails being able to easily download the entire site, using tools like wget.

Generating HTML files as final output is one step toward this goal. While archivers handle .php file endings, they like .html more, and with .html, you can view archives with a plain web browser.

With .html files, you can “archive” by copying over all the files. You won’t need all this software to operate the archived site.

Indexes

Generating complete indexes to the news articles and events allows webcrawlers to get at everything.

This is also a risk, because lots of bots are out there scraping the site, and a complete index will potentially increase their downloading, and risk overloading the site.

Page generation helps with this, because serving up a generated HTML page takes a tiny fraction of the resources of running a PHP file. (Example: on an older computer, a very heavy site like WordPress can top out at 30 requests per second, while a similar HTML site can reach into the 10k requests per second.)

Bots I’ve seen scraping the site: Google, Bing, Claude, Baidu, OpenAI, Ahrefs, Yandex.

Twig Templates

To this end, instead of trying to change the page generation within the existing code, I had the LLM add Twig. It seemed to know more about Twig than Blade, so I went with Twig.

The LLM set up a parallel template structure that copied parts of the existing templates, and then ported the entire site to use it, but didn’t actually remove all of it, because some of the templates we had were full of PHP code.

The Twig templates mixed with the old template system are a mess; they’re completely enmeshed, to replicate the old site.

Eventually, almost the entire site will be generated with Twig.

Eventually, this will be replaced with new layouts that aren’t mixed with the old code.

I suspect I’m going to need to start the process by hand, writing my own templates.

Order and Memory Capacity

This did get me thinking about the issue of why we think some code is well organized, and some code is not.

Part of it is our limited capacity to comprehend large, complicated systems.

To handle big systems, we use structures, like lists, hierarchies, “black boxing”, making things modular, and using repetitive patterns.

The LLM, unlike people, has a different kind of “memory” or “attention” or capacity to deal with large amounts of information. So, while the code looks like a mess to me, it still makes sense to the LLM.

Here’s some computer code that vibe coding produced:

function rotated(p){ // rotate cells 90deg clockwise, re-normalize to 0
  const maxX = Math.max(...p.cells.map(c=>c.x));
  const cells = p.cells.map(c=>({x:c.y, y:maxX-c.x, ch:c.ch}));
  const minX = Math.min(...cells.map(c=>c.x)), minY = Math.min(...cells.map(c=>c.y));
  return cells.map(c=>({x:c.x-minX, y:c.y-minY, ch:c.ch}));
}

function rotated(p){ // rotate cells 90deg clockwise, re-normalize to 0
  const maxX = Math.max(...p.cells.map(c=>c.x));
  const cells = p.cells.map(c=>({x:c.y, y:maxX-c.x, ch:c.ch}));
  const minX = Math.min(...cells.map(c=>c.x)), minY = Math.min(...cells.map(c=>c.y));
  return cells.map(c=>({x:c.x-minX, y:c.y-minY, ch:c.ch}));
}

Almost any programmer has written code like that, but how many enjoy reading code like that.

Conversely, computer code is extremely brittle. A single character out of place, and parts may break. The LLM can write code, but more importantly, it can transform vague instructions and turn them into concrete goals, like people can. So it’s like a programming language that’s a human language.

The challenge is to get the LLM to conform to (the declining) human need to keep code organized, for human comprehension.

The post Thaura: Porting Legacy PHP5 and PHP7 Project to PHP8 Part 4 first appeared on 🍙.

Continuing the series, more info about altering project internals.

I got so tired that I stopped blogging. A note to myself read:

The main big issues I’ve hit this time are refactoring introducing bugs bug repairs introducing bugs incomplete testing of outputs database export and import problems.

Refactoring Introducing Bugs

Initially, I wasn’t that aggressive about testing. I just used URLs and GET to test a list of pages, and told the bot to read the logs. It would find errors and warnings, and fix them.

Then, I got hit with a bunch of uncaught bugs.

One of them was a bug that I knew we corrected before.

So I decided that whenever I found a bug, I wanted a test generated that would prevent that bug from reappearing.

I’m guessing that a bug reappeared because the code was being refactored.

Refactoring is basically building a new code structure, and then copying your old code into it. When it copied the code, it wrote the bug back into existence.

Bug Fixing Revealing Bugs or Introducing Bugs

This isn’t an LLM issue per-se, but in dynamic languages, fixing a bug might reveal other bugs that, until then, were not found, because the first bug killed the program.

An automated test case helps with these.

Incomplete Testing of Outputs

I wish I could remember the situation, but Thaura did a big batch of changes, but it wasn’t testing the output. It just did the modifications.

Some early modifications had automated tests, and it used those to fine tune it’s behavior, but then, it just abandoned testing.

It seemed to be working so fast, so I asked if it was checking outputs. It wasn’t.

So, it’s good to ask the bot what it did. You can read it, and determine if the bot failed to do something. You can find tune its behavior.

Database Import and Export Problems

Initially, I tried to do a mysqldump from MySQL 5.7 and load it into MariaDB 11. It didn’t work, but I expected that. Not only that, but the data needed a lot of manual cleanup.

So I used an intermediate format, JSON, to dump the data, and load it in. That worked extremely well.

Then, I thought I could dump from the dev database and load it into the production database, like this:

No such luck.

They were both MariaDB 11, and the same point version, but different releases, and in slightly different operating systems (Alpine Linux vs. whatever MariaDB’s Docker package uses).

So I had Thaura write a filter to allow the dump to work, mainly by stripping some comments, like this:

(Claude screwed up the diagram. The first dump is a MySQL dump.)

Obviously, I should have focused on defining an intermediate data dump format that would work for us.

This isn’t a PHP porting issue, but it could come up.

The post Thaura: Porting Legacy PHP5 and PHP7 Project to PHP8 Part 3 first appeared on 🍙.

Last time it was about updating code. Now it’s about altering project internals.

Mid-Project Legacy

A long time ago, I decided that the old style include(‘foo_class.inc’) was annoying, and the new style autoloader classes with use \Foo; were nicer.

So I did a simple thing: copy them all into a namespace, and then convert them to PSR-4 compatible classes (aka, autoloading classes).

I left the old files around, just in case they were still being used. The project never completed, and maybe around 10 classes were converted, and many were not.

I told the LLM to fix this, and make everything into a PSR-4 compatible class. It decided which version was good, and which was not and possible merges.

This is mind-blowing to me, that the program can do this.

The process took a day, due to pauses and usage limits, and I’m still not sure it’s OK.

The goal here was to allow static code checking tools like Psalm to do better code analysis.

So far, no real new code

I’m just writing this to make a weird point: I haven’t asked the LLM to write new code. It’s refactoring.

It’s making old code conform to newer programming standards.

It’s removing code, too.

Some Removals

Reporting bad posts – a system similar to Digg, where the community can moderate. It stopped being useful when people gamed it or it didn’t instantly mod someone down.

Spam trapping – I had a bunch of filters, some quite nice, but it was out of date.

IP logging and redirecting – this is still important, but the site’s implementation was pretty annoying, so it goes.

DIY captcha – I wrote it because there weren’t many options I liked. Now, it’s not that relevant because there are packages for captchas.

Themes – again, not super popular, and it was done in a annoying way, with GET parameters.

These removals aren’t all because the feature was bad, but it was just out of date, or should be replaced. Removing them helped reduce the code size.

Improving Debugging

After telling Thaura to do something a certain way, over and over, it starts to do it, automatically, and even expand on it.

I told it to use the static analysis and dependency databases a couple times, and it figured out how to use them.

I told it to always do static analysis and check dependencies, and it would do both, with the tools, and on its own.

So every change is checked with these tools, and also with the Playwright integration tests against some URLs. These can trigger warnings in the logs, so I have it read the logs and debug error and warning messages.

The post Thaura: Porting Legacy PHP5 and PHP7 Project to PHP8 Part 2 first appeared on 🍙.

This document describes how I’m porting a legacy PHP codebase to PHP8.5. The security crisis of October 2026 required porting everything on a legacy website to PHP8, the only version that’s getting updated now. This document is in flux and will change as the port progresses.

The legacy code was running on two containers, behind a nginx reverse proxy, that directed most of the traffic to he PHP7 version of the code, but ran some very old code in PHP5.

The goal was to port code to PHP8, and implement a new app stack that’s nginx + php-fpm + php8.5.

The TL;DR:

• Lean on code linters first.
• Create infrastructure to organize the process of fixing individual files, to get them to compile. Don’t bother to fix the logic at this time.
• Tell the LLM to log changes.
• Build up the new codebase from the old (the LLM made this decision), linting the old PHP7 code mostly.
• Build up the new deployment environment by using the old config files.

The general progression of the work:

1. Download all the old code into a project.
   1. Make a git repo, and add lines to README to use it. (Helps the LLM undo things and see history.)
   2. Include relevant config files. (Teaches context. LLM should know all the parts, rather than assume anything.)
   3. Create careful database dumps, by table rather than the entire db. I had an old archiving tool for this, and used it. Download into repo.
   4. Write notes about the current architecture, project folder layout, db version.
   5. Tell the LLM to log changes to a changelog.
2. Update the code so it compiles.
   1. Use static code linters, stylers, deprecated code scanners, etc. to test the code. (Do not rely on the LLM’s reasoning. Ask it to recommend tools, and install them. Then, you need to configure them to work with your file layout, include paths, etc.)
   2. Let the LLM plan and make the code changes.
   3. Let the LLM guess about which files, and which versions, would need to be ported.
   4. The LLM had trouble running a batch script to do the tool calls, so I told it to make another batcher script to run the script over around 20 files. The LLM tells me to run it when it’s changed.
   5. Made mid-project decision to use a SQLite scoreboard to track the state of each file. Updated scripts to update the scoreboard. This makes the batching partially obsolete.
3. Make a Docker dev environment similar to the deployment goal. Use this to do the runtime integration tests.
   1. Playwright for integration testing.
   2. PHPUnit or similar for unit or function testing.

The llm

I’m using Thaura Pro. The pro is that it’s pretty cheap at $15 a month. The problem is that you can use it only 5 hours at a time, and then you have to take a break. I really don’t mind this.

The tool execution limit will trigger every 15 minutes or so, and require a button click.

Static Checkers

Linters and static code checkers run on the desktop computer to produce reports about code problems. These help you analyze lots of code without burning tokens (or dealing with the indeterminacy of LLMs).

The LLM should write the config files for these tools, so it can adjust them as it runs.

I started with report text files, and a batch file to produce them, but eventually added a sqlite based scoreboard to track work progress. The linting can happen in parallel with the LLM coding.

Coding is “slow”, at maybe 1 minute per file. That’s many multiples of how fast I code, but there is still some waiting. The LLM works in batches of 5-10 files.

A batch checker script, over time, became a kind of scratchpad for the next 10 to 20 files to test. Due to a security issue, I had to run this manually.

What’s nice about the scoreboard and the report.txt sidecars is that I can work in parallel with the LLM. I just write tools (by hand, or by LLM), use other LLMs to set up Docker, edit the README and other notes.

Even this static analysis phase is full of constant changes and improvements.

The Port Environment

The initial environment is a directory that looks like this:

src/
     db/ -- legacy data
     apache/ -- legacy config
     nginx/ -- legacy config
     php5/ -- legacy code
     php7/ -- legacy code
     php8/ -- ported code, goes into git repo
         sitename/ -- not the actual sitename
             local/ -- caches and local code
             public/ -- website root
             shared/ -- project-wide code libraries
bin/ -- scripts and tools to help with coding, goes in repo
docker/ -- configs and tools for docker containers, goes in repo
legacy-data/ -- not the actual name, but things like generated files, temp files, uploads, were downloaded into here, as samples. The entire site was not copied.

The main tools (at thist time) are syntax checkers, linters, like ‘php -l’, phpstan, psalm, phpcs. Helper scripts run the tools, load configs, query the scoreboard, etc.

Thaura can also run these tools individually.

Changes are logged in these places: CHANGELOG.txt, somescript.php.report.txt sidecars that record the output of the syntax checkers (so the LLM doesn’t need to run them individually), the git commits, and I write some changes into README.txt and then tell Thaura to read it. I think Thara also keeps a todo file on its server.

Legacy configs help a lot, explaining how the actual live app works. Porting proceeds breadth-first, and based on what’s exposed through these configs, particularly the nginx reverse proxy, which forwards traffic to two different PHP containers, depending on the URI.

The new config is much simpler, because it’s a single codebase. The old configs help the port avoid porting stray PHP files here and there, by identifying what is exposed to the world.

Early on, the LLM is just guessing which files are dependencies. This will come out in the wash and rinse as the code is executed.

Code Fixing

The first goal was to get all the code compiling. I didn’t care if it had some warnings, and I didn’t care if it even ran correctly.

This took over a day, but eventually finished.

Initially, I thought the next step would be to write tests, like TDD, but, instead, the LLM was going into actual debugging, so I went along.

This is almost like the opposite of TDD, and more like interactive programming with an interpreter.

I’d give it a URL, and tell it to fix it, by figuring out which files get loaded, and checking the work from the URL down to the libraries. It required checking dependencies.

Tests

So I did around 10 or 15 of these debugging excursions, and it got better at it over time.

Next, I told it to create Playwright tests for a bunch of the URLs, and some new ones.

More on this later.

Database Tables

During debugging, it would sometimes hit missing database tables. This could cause the LLM to go on a pointless debugging excursion, or try to recreate the table.

I’d have to stop it, ssh into the server, alter the table dumping script, exit ssh, and then do an rsync to copy the new table dumps.

The LLM created a couple utilities to upload the tables into the local DB.

MySQL 5.7 to MariaDB Migration

Initially, I thought it would work to use the db dumps to load MariaDB. It seemed like some python scripts could fix them up, since they use roughly the same SQL.

I hadn’t thought about the long term nightmare of migrating from latin1 to utf8, which the site underwent over many years. By and large, the data was ASCII or UTF-8, but many columns were typed as latin1.

So, instead, the LLM offered to fix some of the bad data, and I asked for tools to dump the data to JSON, and load the data from JSON.

The new tables and columns will, eventually, be utf8mb4, or whatever is best for the near future.

The data repair was pretty amazing. It didn’t just fix our internal migration mistakes – it also fixed dirty user input.

I could tell it had the accumulated experience of decades of annoyances people had when migrating to Unicode and UTF8.

Testing URLs

The LLM seemed to be really good at figuring out how a URL maps to a PHP file, and all the PHP files that get involved in producing that URL.

I also taught it how to go into the /admin/ area, with a username and password, and run the page generation code.

The code wasn’t really working, so during this “training”, it was also looking at the code and fixing it until it worked. Mostly, it was configuration issues.

So, now, I could tell it to fix something that involved page generation, and it could “drive” the site to regenerate the page during its debugging.

I settled into using this prompt pattern:

/path/to/url.php -- this page does this, but it's not doing it correctly. Debug it.

I repeated this for all the parts of the admin, including the parts I was hoping to remove.

Then I repeated it for world-facing pages.

I didn’t test if the site could upload files, etc. When I was creating the Playwright tests, it went ahead and wrote tests to do some of that.

So, with this interactive debugging, I suspect I primed the LLM to know how to make the Playwright tests.

Simplification by Replacing Variables with Constants

The site had two config files, and many of the configs were global variables.

Most of these were used like constants. They never changed.

So I told two LLMS to go, one by one, and replace the variable with a constant, if the variable wasn’t ever assigned a value elsewhere in the code.

Every variable is a potential decision point: an if statement, or switch statement, or concatenation in a string that’s a file path, etc.

Replacing variables with constants, when possible, should make debugging easier.

To test it, I used the big test suite in playwright, and told the LLM to run each test individually, and read the logs, fixing any errors or warnings.

Enabling Xdebug

I should have done this from the start, but better late than never. I had it produce dumps about what functions got called, and it also allows the LLM to do debugging.

Scoreboards and Dependencies

I had it create a scoreboard system to see how the code porting and conversion were progressing — the pass/fail status was determined by running static checkers on the code.

Then I created commands to query the scoreboard.

It eventually seemed to use it a little bit. I think doing the scoreboard from the start, could have helped, but, if anything, I got more use out of it than the LLM.

I also had it create a database of dependencies, of what files get included (and what files include a given file).

Tools for OOP in PHP will produce this info, but this codebase is mostly PHP4 style require() and include() based.

Again, I don’t know if the LLM used it, but it would have helped debugging go faster.

This is all debugging infrastructure, ultimately, and it’s good not only for the LLM but for the programmer as well.

Removing Features

The old software had a bunch of features that nobody seems to use anymore.

going forward, i want to do a commit before, and a dev release after, a site feature is removed, so it's easy to go back and undo a bad batch of work. for example, for this round, I'd like to remove code related to themes, theme.php and anything related to it, like CSS files, any gui related to the theme, and logic to switch the theme. Only the default theme should be left. analyze the code, plan the removal, and then remove, and test. then, remove any playwright tests for themes. when it's all good, do a dev release.

going forward, i want to do a commit before, and a dev release after, a site feature is removed, so it's easy to go back and undo a bad batch of work. for example, for this round, I'd like to remove code related to themes, theme.php and anything related to it, like CSS files, any gui related to the theme, and logic to switch the theme. Only the default theme should be left. analyze the code, plan the removal, and then remove, and test. then, remove any playwright tests for themes. when it's all good, do a dev release.

I know the codebase pretty well, so I knew this was a pretty simple change.

Removing features removes files, and removing files reduces the amount of context required to edit the code.

Code that would use the theme variable was also rewritten to simply use the default theme.

(My plan is to re-add features by using external libraries when appropriate.)

Continued in part 2.

The post Thaura: Porting Legacy PHP5 and PHP7 Project to PHP8 Part 1 first appeared on 🍙.

This bot gives advice about how to make layouts in WordPress using the stock tools and features. More on this later, on to the Thaura Projects settings.

Thaura Projects is a feature to allow you to create chatbots (and other interactive tools).

To create a new Project, click on Project in the navigation, and then “+” in the upper right corner.

Fill in the form with:

Then save it, and go to the Project. In the upper right, click the triple-dot menu and Edit.

Add:

This is a screenshot of the dialog box where you paste in the prompts.

The post Thaura & WordPress: layout advice chatbot first appeared on 🍙.

New ways to use old structures to help LLMs write better code. Techniques to reduce token use, reduce context size, reduce errors.

Adapting Traditional OOP Style

Classic object-oriented design — inheritance hierarchies, polymorphic dispatch, encapsulated state — predates LLMs by decades. Much of what made OOP ergonomic for humans (deep class trees, implicit constructor injection, framework-managed lifecycles) introduces exactly the kind of implicit decisions that hurt one-shot generation. The good news: you can keep the spirit of OOP while stripping out the parts that confuse a model.

Inheritance → Composition + Interfaces

Deep extends chains force the model to track overridden methods across multiple files, guess which superclass field is shadowing which, and infer initialization order. Adaptation:

• Prefer interfaces / traits / protocols over base classes. A flat interface PaymentProcessor { process(order: Order): Result } gives the model a complete contract in one place. No diamond problems, no super-call ordering to reason about.
• Use composition for shared behavior. Mixins, embedded structs, or trait implementations (impl Display for MyType) are self-contained blocks the model can generate without knowing the rest of the hierarchy.
• If you must inherit, keep depth ≤ 2. One concrete base + one leaf is manageable; three levels with abstract intermediates start to exceed what the model tracks reliably in a single pass.

Encapsulation → Explicit Data Structures

Private fields with getters/setters hide data flow behind method calls the model must predict. Adaptation:

• Expose plain data structures (structs, records, frozen objects) at boundaries. The model sees the shape directly instead of inferring it from accessor pairs.
• Reserve methods for behavior, not for field access. If a “method” just returns a field, make the field public (or readonly) and delete the getter. Fewer indirection layers means fewer places the model can invent a nonexistent accessor.
• Make mutability intentional and visible. A struct with all-public fields communicates “data container.” A class with private state and mutating methods signals “behavior owner.” Mixing both in one type forces the model to guess the invariant.

Polymorphism → Tagged Unions + Pattern Matching

Runtime dynamic dispatch (obj.handle() where the actual type depends on construction site) requires the model to enumerate every possible subclass. Adaptation:

• Replace runtime polymorphism with sum types + exhaustive match wherever the set of cases is closed. enum Shape { Circle(f64), Rect(f64, f64) } matched in one function is unambiguous; a Shape interface with ten subclasses scattered across modules is not.
• For open-ended extensibility (plugin systems, event handlers), use an explicit registry or visitor pattern rather than relying on the model to discover all overrides. The registry is a single lookup table the model can read.
• Sealed hierarchies beat open ones. If the compiler enforces exhaustiveness (Kotlin sealed, Scala sealed, TypeScript discriminated unions), the model knows the case list is complete. Open hierarchies invite phantom branches.

Dependency Injection → Explicit Constructor Parameters

Frameworks that inject dependencies via annotations, reflection, or container magic hide the dependency graph. The model can’t see what a class actually needs until it reads the DI configuration. Adaptation:

• Pass dependencies through constructors explicitly. fn new(db: &Pool, cache: &Cache) is visible at the call site. @Inject annotations require reading a separate wiring file the model may not have in context.
• Keep constructor arity low (≤ 4). Beyond that, bundle related deps into a config/options struct. Long parameter lists are where models drop arguments or swap types.
• Avoid builder-pattern fluency for core types. Fluent builders (new Widget().red().big().build()) scatter construction logic across chained calls. A single constructor call with a struct literal is easier to generate correctly.

Framework Magic → Plain Entry Points

Spring beans, Rails controllers, Angular decorators, and similar frameworks interpose lifecycle hooks, serialization, and routing logic between your code and its observable behavior. Adaptation:

• Isolate framework glue in thin adapters. Keep business logic in plain functions/classes with no framework annotations. The adapter translates HTTP request → function call → response. The model generates the interesting part (logic) without needing to satisfy framework constraints simultaneously.
• Prefer functional entry points for pure computation. A controller that calls calculate_total(items, discount_code) is testable and generatable independently of the web framework. Embedding that calculation inside a decorated class method couples two concerns the model must get right at once.
• Document the framework contract in the prompt if unavoidable. If the target code must be a Spring @Service or a React component, include one minimal working example in the prompt. One concrete exemplar reduces hallucination more than any amount of prose description.

State Machines → Enum-Driven Flows

Implicit state held in boolean flags (isLoading, hasError, isSubmitted) creates combinatorial explosion the model struggles to navigate. Adaptation:

• Model explicit states as enums. enum CheckoutState { Idle, FillingCart, ValidatingPayment, Processing, Complete(Error?) } makes invalid transitions impossible and gives the model a finite, named space to work in.
• Transition functions take (state, event) → new_state. Pure transition functions are trivially verifiable and easy to generate. Mutating a stateful object’s internal booleans is not.
• Guard clauses over nested conditionals. match state { Idle => ..., Processing => ... } beats four levels of if (flag1 && !flag2 || flag3) that the model must untangle.

Summary Checklist

The overarching principle is the same as the rest of this article: remove implicit decisions. Traditional OOP optimizes for human maintainability in large teams over years — hiding internals, deferring binding, distributing behavior across a hierarchy. LLM one-shot generation optimizes for a different constraint: everything relevant must be visible, local, and unambiguous within a single context window. You don’t abandon OOP thinking; you flatten it so the model doesn’t have to reconstruct the hidden architecture from fragments.

The post Adapting Traditional OOP Style to the LLM World first appeared on 🍙.

A quick-reference list of language features and conventions that make one-shot code generation more reliable. The common thread: predictability. Features that appear frequently in training data, parse unambiguously, and leave few implicit choices produce fewer hallucinations and fewer subtle bugs.

Type System & Static Structure

• Explicit type annotations. Languages with strong static typing (TypeScript, Rust, Go, Java) constrain the solution space dramatically. An annotation like fn process(input: Vec<u8>) -> Result<String, Error> tells the model exactly what goes in and comes out, eliminating an entire class of guessing.
• Algebraic / sum types. Enums, tagged unions, sealed classes, and Result<T, E> force exhaustive handling. The model can’t silently forget a case the way it can with a bare integer or string status code.
• Optionality made explicit. Option<T>, nullable markers, or required-field syntax prevent “did I check for null?” ambiguity from leaking into generated logic.

Naming & Conventions

• Descriptive, conventional identifiers. Names that follow community norms (getUserName, not gn()) match high-frequency patterns in training data. The model essentially autocomplete-s from convention.
• Standard library names used as-is. Reaching for collections.defaultdict instead of inventing a helper keeps the output verifiable and familiar.

Syntax Predictability

• Uniform function/method call syntax. Consistent f(x) across the language means the model rarely fumbles call shapes. Languages mixing macro invocations, operator overloading, and special dispatch forms are harder to get right blind.
• No hidden mutation or side effects baked into syntax. Properties, getters/setters, and overloaded operators introduce behavior the model must infer. Plain functions and plain fields are safer bets.
• Single, obvious control-flow forms. One canonical for x in items: loop beats five dialects. When a language has many ways to express the same thing, the model picks whichever was most frequent in its slice of training data — which may not be your house style.

Module & Import Clarity

• Explicit imports. Languages where every symbol must be imported (Go, ES modules, Rust use) give the model a clear contract. Implicit global namespaces increase the chance of name collisions and wrong-symbol guesses.
• Flat, predictable module paths. Deep dynamic import chains are harder for the model to resolve correctly than shallow, named ones.

Error Handling

• Structured errors over exceptions-as-control-flow. Returning error values or using typed result types is easier for the model to wire up correctly than try/catch ladders with implicit propagation.
• One idiomatic recovery path. If the ecosystem has a single accepted pattern (e.g., Rust’s ? operator), the model converges on it reliably.

Immutability & Data Flow

• Default-immutability languages (Rust ownership, immutable-by-default JS bindings via const discipline, Clojure values) reduce the state-space the model must track. Fewer aliasing surprises mean fewer off-by-one-mutation bugs.
• Pure-function-friendly design. Functions whose output depends only on inputs are trivially composable and easy for the model to reason about step by step.

Formatting & Tokenization Friendliness

• Consistent whitespace-based structure (Python indentation, standard 4-space blocks) maps cleanly onto token boundaries. Irregular formatting or mixed-indentation legacy code increases noise.
• Common delimiters and punctuation. Braces, parentheses, semicolons used uniformly tokenize predictably; exotic delimiter schemes add risk.

Testability Surface

• Small, independently callable units. A language/ecosystem where you can unit-test a function without bootstrapping a framework gives the model a natural stopping point and makes verification cheap.
• Deterministic behavior by default. No hidden randomness, no wall-clock dependence inside core logic — the model can reason about outputs concretely.

Practical Takeaways

Rule of thumb: when choosing a language or refactoring a prompt for better one-shot results, pick the option that leaves the fewest implicit decisions to the model. Every explicit choice you encode in the language itself is a decision the model doesn’t have to guess.

Language Competition

Comparing these languages: JavaScript, TypeScript, Lua, Go, Rust, C++, C, ObjC, Haskell, Elm, Python3, Perl, Perl6, PHP8, Vala, Java, Kotlin, Swift, C#, F#.

The post Language Characteristics that Help LLMs Write Better Code first appeared on 🍙.

I had Thaura read my AGENTS file, and critique it. I made the suggested changed, and also added more advice. Then, I started a fresh session and had it reorganize it.

Here it is as a download (I had trouble pasting it here).

Scoreboard

I used the Free versions in OpenCode, which has some free models included.

Token counts are approximate.

For this round, I used an AGENTS.md file that was improved by asking Thaura to critique it. The critique was based on what happened during the LLMs coding and testing. I made changes, and then asked Thaura to organize it.

I figured this would help Thaura, which was already succeeding at writing the code. It breezed through the task, and appeared to use only a small amount of energy (Thaura converts tokens into energy usage, and said it was like driving under 500 meters).

It also seems to have helped the others as well.

For each build, I asked the agent to critique AGENTS.md, and write the critique to critique.md. Mimo failed to do that, but Ling and Muse Spark did it. So they can compare how their build went, and how the AGENTS.md file helped.

One thing that jumped out was that the LLMs asked for a more determinate test, with more specific layout details. They asked me to be more specific about what I wanted.

Nemotron 3.5

Again, Nemotron had problems.

I told it to read AGENTS.md, and got this:

Theytics motherellsellsamu inells this alongellsells from indigenousellsells Carn shred mill certifiedells

It’s not having a good day.

Eventually, I interrupted it, and the layout was there, but the CSS wasn’t, and the Playwright tests weren’t done. So I gave it the “OK” to complete that. It still didn’t end up working.

Then it said:

It seems port 800 الخارجية-orientedे- extern需-exل-allow-its owners المشاكل mu로서 cơis(),
 lui. ث.
 starken-ise anno (h. (something
 also . ( weiteren
 شركة томnil

Performance Improvements

Ignore the layout1 counts: some of these runs didn’t succeed. So those values aren’t all valid.

The layout2 counts are more valid, because they all produced a reasonable result, excepting Nemotron3.5.

The change from version 3 to version 4 of AGENTS.md was generally saving tokens across three (or four) of the 7 models. AGENTS.md 4 was much longer, and more comprehensive, so it consumed more context, but it prevented the models from making so many errors, and requiring more compile-debug cycles, saving both time and tokens.

Because I can’t see token counts on Thaura, I cannot be certain the count went down, but I know that the “miles driven” metric it provides in its stead plummeted, and it produced the code quickly, and it didn’t appear to be running the compiler as much. This wasn’t a surprise, because I asked Thaura to help me improve my AGENTS.md, and it listed all the ways it tripped up, and told me how it could have avoided the bugs.

We see some large drops in token counts, approximately 10k or 25% less for three models.

However, it’s obvious that my AGENTS.md is not cross-platform. A lot of it reads like a “guide to pitfalls and landmines” across a space that’s rough and rocky. It works for Thaura’s LLM to make this specific project, but it could also be a hindrance to a different project.

AGENTS.md Effectiveness

New Research Reassesses the Value of AGENTS.md Files for AI Coding reported that AGENTS.md, across 60,000 instances found on GitHub, seemed to produce a 4% improvement, and in some cases, made things worse.

My sense is that a detailed spec in AGENTS.md with advice about how to program initially costs more tokens, but as these are improved, performance will improve.

Code Quality

I can’t evaluate it because I don’t know Elm well enough – however, this process of discussing the problem code with LLMs has helped my learning considerably.

Conclusion

All the models basically completed the code without asking questions, but, once again, Nemotrion 3.5 Lighting Free failed.

Here is a ZIP file with all the generated code, and project files.

The post Learning Elm: fourth try with the LLM layout tests first appeared on 🍙.

AGENTS.md was edited to address a lot of bugs and problems from the second run. Also added a directory for more extensive coding advice. You can find it in the ZIP file.

# Layout Test

## Tools

Language: elm
Elm tool is at /home/johnk/.local/bin/elm
The Elm version is 19.2. Write code for version 19.0 to 19.2. A lot of training data from before 2019 may be out of date.
Add Elm modules as needed using the `elm install` tool. Prefer libraries to writing new code.
Do not try to copy the library into the correct location. Use `elm install` instead.
Assume the compiler works, and if there are compilation errors, assume your code is incorrect.
If the bugs point to naming or lack of definitions, check the import lines.
elm-test is installed for unit testing. 
Playwright and Selenium are installed for frontend tests to check the layout.
  `playwright-cli` is installed, info here: https://www.npmjs.com/package/playwright
  `selenium` is installed. `selenium-webdriver` is installed, info: https://www.npmjs.com/package/selenium-webdriver
For advice and references, see the Tips section below.

## Code to Write

Never try to cd or use .. to get above the project root directory.
  If you need temp files make a tmp/ in the project root.
Directory layout
  Elm sources go in src/
  HTML files, js artifacts from compilation, js code you write, css code you write, and binary assets go in public/.
  The project root contains the elm.json, project.json, composer.json and other package manager files.
  The project root contains .md and .txt files for LLMs and people. llm-advice as well.
  Tests go in tests/
Make a mockup layout in Elm for a News website, with a short top banner, and 3 columns: 
  Title is "Test News Site".
  Top banner is around 2 cm on a desktop screen, and 25% of a vertical mobile screen.
  left column nav, center column feature area, right colum listing of additional news. Widths approximately 20%, 60%, 20%.
  Theme colors: light gray background, dark gray text, dark blue links.
  Layout is responsive to mobile, tablet, and desktop size screens.
  Use common CSS class naming conventions when possible. See: ./llm-advice/css-class-naming-conventions.txt
Static files:
  Use CSS, making the CSS file external in public/style.css.
  Compile the Elm code into javscript code, and put it into the public/ directory, or the public/js directory.
  Create public/index.html file to pull in CSS. 
  URL references in the static files should be relative, not absolute.
    Assume I'm starting `elm reactor` in the project root, not inside public/, so always use relative paths.
The layout should loop over arrays to construct the center and right columns. 
  The center column array is a list of news headlines, URLs, and URLs to images (located in the public/images directory).
  Center colum items have an image, headline, and excerpt.
  The right column array is a list of news headlines and URLs.
  The left column contains a simple nav with: Home, Local News, Breaking News.
Testing
  At the very minimum, create a Playwright test to check that the browser can display the layout.
  Often, code compiles and works, but the index.html file has bad URLs that won't load the artifacts.
    Problems include: /main.js - absolute path doesn't work; ../dist/main.js - the http server doesn't allow going up a directory.
    Solution is to use relative paths, and generate artifacts in public/, and then use url: main.js
    Same has happened with CSS files.

## Tips

The following advice below may help avoid getting into endless debugging loops.
Important: the assumption that the tools and compilers are not working often leads to looping over tests that keep failing. This is because you are falling into the compiler developers test code. Assume that the elm compiler is correct. If it keeps failing, stop and tell the user.
Read about shadowing: ./llm-advice/shadowing.txt
Current calling convention in index.html is Elm.Main.init({ node: document.getElementById('the-node-id') })
elm-test Refs: https://elmprogramming.com/easy-to-test.html https://github.com/elm-explorations/test
For advice about v19, see: https://raw.githubusercontent.com/elm/compiler/refs/heads/main/docs/upgrade-instructions/0.19.0.md

# Layout Test

## Tools

Language: elm
Elm tool is at /home/johnk/.local/bin/elm
The Elm version is 19.2. Write code for version 19.0 to 19.2. A lot of training data from before 2019 may be out of date.
Add Elm modules as needed using the `elm install` tool. Prefer libraries to writing new code.
Do not try to copy the library into the correct location. Use `elm install` instead.
Assume the compiler works, and if there are compilation errors, assume your code is incorrect.
If the bugs point to naming or lack of definitions, check the import lines.
elm-test is installed for unit testing. 
Playwright and Selenium are installed for frontend tests to check the layout.
  `playwright-cli` is installed, info here: https://www.npmjs.com/package/playwright
  `selenium` is installed. `selenium-webdriver` is installed, info: https://www.npmjs.com/package/selenium-webdriver
For advice and references, see the Tips section below.

## Code to Write

Never try to cd or use .. to get above the project root directory.
  If you need temp files make a tmp/ in the project root.
Directory layout
  Elm sources go in src/
  HTML files, js artifacts from compilation, js code you write, css code you write, and binary assets go in public/.
  The project root contains the elm.json, project.json, composer.json and other package manager files.
  The project root contains .md and .txt files for LLMs and people. llm-advice as well.
  Tests go in tests/
Make a mockup layout in Elm for a News website, with a short top banner, and 3 columns: 
  Title is "Test News Site".
  Top banner is around 2 cm on a desktop screen, and 25% of a vertical mobile screen.
  left column nav, center column feature area, right colum listing of additional news. Widths approximately 20%, 60%, 20%.
  Theme colors: light gray background, dark gray text, dark blue links.
  Layout is responsive to mobile, tablet, and desktop size screens.
  Use common CSS class naming conventions when possible. See: ./llm-advice/css-class-naming-conventions.txt
Static files:
  Use CSS, making the CSS file external in public/style.css.
  Compile the Elm code into javscript code, and put it into the public/ directory, or the public/js directory.
  Create public/index.html file to pull in CSS. 
  URL references in the static files should be relative, not absolute.
    Assume I'm starting `elm reactor` in the project root, not inside public/, so always use relative paths.
The layout should loop over arrays to construct the center and right columns. 
  The center column array is a list of news headlines, URLs, and URLs to images (located in the public/images directory).
  Center colum items have an image, headline, and excerpt.
  The right column array is a list of news headlines and URLs.
  The left column contains a simple nav with: Home, Local News, Breaking News.
Testing
  At the very minimum, create a Playwright test to check that the browser can display the layout.
  Often, code compiles and works, but the index.html file has bad URLs that won't load the artifacts.
    Problems include: /main.js - absolute path doesn't work; ../dist/main.js - the http server doesn't allow going up a directory.
    Solution is to use relative paths, and generate artifacts in public/, and then use url: main.js
    Same has happened with CSS files.

## Tips

The following advice below may help avoid getting into endless debugging loops.
Important: the assumption that the tools and compilers are not working often leads to looping over tests that keep failing. This is because you are falling into the compiler developers test code. Assume that the elm compiler is correct. If it keeps failing, stop and tell the user.
Read about shadowing: ./llm-advice/shadowing.txt
Current calling convention in index.html is Elm.Main.init({ node: document.getElementById('the-node-id') })
elm-test Refs: https://elmprogramming.com/easy-to-test.html https://github.com/elm-explorations/test
For advice about v19, see: https://raw.githubusercontent.com/elm/compiler/refs/heads/main/docs/upgrade-instructions/0.19.0.md

The file is now 61 lines long.

Scoreboard

I used the Free versions in OpenCode.

The number scores are about how good the layout looks. The first one is scored 5, and subsequent scores are based on how good it looks relative to the first one.

I am not going to try and evaluate the “look” anymore. All the layouts are basically midrange in quality, and all will require work to look nice. Additionally, it’s not like I’ve provided an image of the desired layout, so it seems pointless to compare.

Token counts are approximate.

The commands I used:

read AGENTS.md
build it -- sometimes

I expected token counts to rise as the prompts grew, but that didn’t seem to happen in any appreciable way. Sometimes, the token count decreased. This may be related to my manually setting up and installing as many tools as I thought it’d need. It may be related to specifying things like filenames and locations explicitly.

I told it I would use elm reactor from the project root to view the site, but it seemed like the LLMs preferred to use the http server in Python, and ran it from public/. This could cause it to pass tests that would fail, due to bad paths, if the server ran in the project root.

Adding the requirement to produce a Playwright test helped tremendously.

Time Spent

I didn’t keep good track, but until this round, it was around 2-3 hours per to test and produce each of the last three reports, including changes to the prompt in AGENTS.md, building the projects, and posting it to the site.

As the prompt got longer, the build times grew to several minutes, and sometimes it felt like 30 minutes or more.

This round, Nemotron 3 took over 90 minutes.

Nemotron 3.5 Lighting Free

At 13K tokens, it crashed out:

Let "action: layout main: 56.tabular: "Ginger Analytics summary full não complete complete deployingتهاء kompletFull完成 الكامل midline—:  clauses 3://umé 1 layouts widths, I, kh

Just for giggles, I told it continue. It just spun the spinner several minutes before I quit and restarted.

The second time around, it wanted access to /tmp, and I refused it. Then it got into a death spiral at 45K when it couldn’t figure out how to end a record that starts with ‘{‘ and that contained a literal list, which looks like [ … ], with a matching ‘}’.

Code Quality

I can’t evaluate it because I don’t know Elm well enough – however, this process of discussing the problem code with LLMs has helped my learning considerably.

Conclusion

All the models basically completed the code without asking questions, but, once again, Nemotrion 3.5 Lighting Free failed.

The post Learning Elm: trying different LLMs to make a layout attempt 3 first appeared on 🍙.