The Abstraction Rises

> like putting lipstick on a pig.

More like building a house in a bottomless swamp. The moment you finish it starts sinking, so you build a new floor, but it just makes it heavier, and speed up the sinking speed.

Bro it's fine everyone's doing it get to the program. We all just need to use multiple agents with memory and skills and orchestrate them, connect them to ticketing systems with workload federation and let them create lambdas to push artifacts from a CI that has audit logs and snyk scanning, let them spin up a few kubernetes clusters per commit, then write the test suites with headless chrome and simulated agents that run A/B testing with multiple backups, regional HA, SSO, vertical and horizontal autoscaling, otel agents that rewrite what they collect based on other agentic processes that also run via lambdas that monitor datadog and splunk and sentry, automated PRs and red teaming. If you don't think about all of that even when you sleep do you even care about the customer?

I think a reasonable and sensible goal is for us to not mix the accidental and the essential. If we let AI handle what's accidental (as in not central to the solution of the essential problem) developers can focus on the essential only. The current threat is that both types become intertwingled in a code-base, sometimes irreparably.

Fortran made that distinction clear. The compiler handled the accidental complexity of converting instructions to code, but never really obscured the boundary.

Take VB as an example from wayback. For the purposes of presenting a simple data-entry dialog, it removed the accidental complexity of dealing with Windows' message loop and resource files etc., which was painful. The essential complexity was in what the system did with the data. I suppose that the AI steering that needs to happen is to direct the essential down the essential path, and the accidental down the accidental path, and let a dev handle the former and the agent handle the latter (after all, it's accidental).

But, that'll take judgement - deciding in which camp each artifact exists and how it's managed. It might be a whole field of study, but it won't be new.

We need a better term. There's nothing accidental about having to smack the parrot until it delivers an acceptable squawk.

I've definitely noticed an uptick in output from "non-developers" specifically in game modding circles. It started when ChatGPT came out and people were copy-pasting code from it into files without knowing how to check if they actually were even in the proper file format for games to recognize, and but with tools like Claude the floor has risen to the point where most vibe-coded mods are at least loadable by games and most tooling people are writing will at least compile.

The thing that took me by surprise is that despite a huge amount of noise, there's a non-zero number of instances where the output has ended up being quite high quality. There's someone who by their own account had no development experience before AI tooling has started doing some incredible work on mod management on Linux, and from using some of the tools they've made so far, it's way higher quality than pretty much any other native Linux tooling for managing mods I've seen so far. I ended up chatting with them a bit after I got enough use out of what they made that it seemed worth subscribing to their Patreon, and they've spent a lot of time on improving their coding skills because they can tell how much it helps them even if they're utilizing the AI tooling for a lot of it. This specific developer is probably an outlier in terms of how well they're able to identify and focus on what ends up impacting the user experience (both in terms of features and willingness to spend quite a lot of effort tracking down and fixing even small bugs), but it seems like they might have never gone down this path in the first place without AI tooling.

I think the ratio of developers compared to "regular" users is still probably fairly small, so the number of people who have never had any reason to want or need a Github is still way higher than the number of people who already have accounts. I'm not trying to say that this won't cause some amount of friction in how development works or that there won't be a lot of slop out there that might make it hard to find the higher quality output, but I suspect that trying to fight against the trend is going to be a losing battle, and that "solving" it will end up requiring better ways to select which software that we want to use rather than limiting the amount of it that gets written and published. Writing software has continued to get more accessible over time; early computers weren't something you could have at home and work on stuff in your spare time on, and I'm sure that the the volume of low-quality software increased when that barrier was eliminated, but the volume of high quality software increased as well, and in the decades since then we've come up with all sorts of new ways to search for and distribute software that makes more of it available to everyone. At least right now, this is starting to look like a similar shift in how much more software is going to be produced, and although a lot of it might be bad, I'm not convinced that there won't also be some potential benefits to having a lot more people willing to try it out themselves. Trying to reap those benefits requires at least some amount of acceptance though, and I think the focus needs to be on the quality of the output independent of the process rather than on the process itself.

The bar for what we consider acceptable software shouldn't be lowered, but the litmus test that it needs to be written by a "real" developer is not necessarily going to be as accurate as those of us in the old guard would like. Yes, there will likely be problems down the line for someone who only wants to vibe and not understand what's actually going on with the code itself, but I've also worked with fantastic engineers who only have vague ideas about how a compiler works or what a CPU is actually is doing under the hood because it turns out that sometimes (not always!) that's not required knowledge to be able to write software that's actually useful. What they've all had in common is that they genuinely care about the quality of what they produce, so they focused on what the actual experience and then figured out what they needed to learn to improve that rather than starting from the bottom up.

StrongDM is doing it. In fact, their Attractor agentic loop, which generates, tests, and deploys code written as specs, has been released—as a spec, not code. Their installation instructions are pretty much "feed this into your LLM". They are building out not only complete applications, but test harnesses for those applications that clone popular web apps like Slack and JIRA, with no humans in the loop beyond writing the initial spec and giving final approval to deploy.

We're witnessing a "horses to automobile" moment in software development. Programming, as a professional discipline, is going to be over in a year or two on the outside. We're getting the "end of software engineering in six months" before we're getting a real "year of the Linux desktop". Or GTA VI.

Fortran is about numerical programming without having to deal with explicit addresses. Symbolic programming is something like lisp.

Llms do not manipulate symbols according to rules, they predict tokens, or arbitrary glyphs in human parlance, based on statistical rules.

The essential complexity isn't solvable by computer systems. That was the point Fred Brooks was making.

You can reduce it by process re-engineering, by changing the requirements, by managing expectations. But not by programming.

If we get an LLM to manage the rest of the organisation, then conceivably we could get it to reduce the essential complexity of the programming task. But that's putting the cart before the horse - getting an LLM to rearrange the organisation processes so that it has less complexity to deal with when coding seems like a bad deal.

And complexity is one of the things we're still not seeing much improvement in LLMs managing. The common experience from people using LLM coding agents is that simple systems become easy, but complex systems will still cause problems with LLM usage. LLMs are not coping well with complexity. That may change, of course, but that's the situation now.

Why? What is compelling about it?