> What are the exact "currently established methodologies" you're talking about that cannot be replaced by LLMs + a harness today, just as some examples? You're probably right that those exists, but I'm curious to hear what you think would be the most difficult to replace today.

I was explaining [0] under another post that programming is mostly translation works. You take a specs and you formalize it using code, like going from sketch to a proper engineering drawing. Software design is more creative, where you take a problem and then comes up with a solution (creating the specs). Software Engineering is ensuring that those two are done well enough while consuming the least resources.

So a program is always a formal system. It's also static. It will be executed by a computer which will actually have a tangible effect in the real world. That effect is what's valuable. The program is the seed which let us control that effect. Aka it's the map that let us plan the journey, but it's not the territory that we will have to travel in.

The issue I keep pointing in most of my comment is thinking that the map is the territory. That the novel are the words and not the story so we need more words. Or that the code is more important than the user' workflows, se we are adding more buggy code, while not ensuring that the workflows are undisturbed.

> Nowadays, my entire home-lab is configured with Nix and almost everything except my workstation and some random stuff, runs NixOS. Everything is hosted on a local Forgejo instance, which also has it's own (custom "written" of course) agent acting on issues and PRs, and I have my harness basically maintain my entire home lab at this point.

It's also highlighted here where you focus more on the process than the output here. The goal is to have a working homelab. NixOS managing it is only the process (accidental complexity). If it's where truly about the goal and not NixOS and using AI, by this point, adding new nodes (software, devices,...) should be as easy as selecting it and adding it to the current system, like a strategy game.

You can see that philosophy in OpenBSD, where the focus is to have a working OS, not to work on developing an OS. A lot of software are done and it's mostly just bug fixing every once in a while. You can also see the same attitude in industrial engineering where you develop a solution and then use it for years. You don't spend all your time tweaking it and thus disturbing the production flow.

So yes, when I see a LLM methodology, it's mostly about the work itself, not the output of the work. There is no definition of done or even the idea of having one. It's work for the purpose of working.

[0] https://news.ycombinator.com/item?id=49157720

Don't be a meat proxy