I think the worst part is that to the bullshit artists that usually float to the top of any org chart, AI generated docs, and implementation plans, and code is superficially plausible. It's hard to find any particular thing that is wrong with all of it - just a general vibe of verbosity. I am observing entire engineering departments drowning in AI generated RFCs and TDDs and thousand plus word Jira tickets and PR reviews and feedback to the PRs. All just Claude talking to itself via various meat-based secretaries.

Meanwhile, as far as leadership is concerned, they don't really understand what is being delivered they just know there's a lot of it. So they're happy - for now.

I think a lot of shops are going to have to go through a couple years of Github-style "why the fuck is our service always down?" before they put 2 and 2 together.

There are deterministically computable metrics for cognitive complexity and readability[0].

They’re not perfect by any means — and I suspect they’re already included in the RL process for coding evals, and have been for some time. I do think we’ll see ongoing improvement in this area though.

[0] (pdf warning) https://www.sonarsource.com/docs/CognitiveComplexity.pdf

I don't think these comparisons between AI generated code and an idealised version of the code are productive. We have to compare with code that exists in the real world, so AI against human, and not only that, good AI generated code with good human written code, as well as AI slop with human slop.

I think if we did that we'd see that on average the code written by humans are less legible, parts of the intention will live forever in the mind of the developer at time of writing, and more prone to complexity build-up over time, simply because there wasn't time and incentive to go back and refactor code that works, apparently.

Now with AI sure you produce a lot more complexity, more than the human prompter could write by himself, but complexity can be managed with the same workflow that created it, by analysing and removing code paths, changing code architecture, replacing reimplementation with consolidated libs etc...

It's a matter of knowing how to use the tool and not creating a false sense of nostalgia where we feel like we had it better in the old days, which is not true at all.

> How do you reward human-understandability in benchmarks and unsupervised training?

And to answer this, there is no replacement for humans immersed in their world yet, so we need developers with with good understanding of the domain and that are able to write good descriptive prose in order to steer agents into producing acceptable code.

Same way you do with humans.

Set acceptable review standards, outline appropriate frameworking, document approaches, test standards, documentation standards and overall just set good examples in both context and the codebase.

If your codebase is slop it's because you approved it.

[dead]

Yeah but only _you_ know what to do when your code breaks, ha ha.

Especially if they can use code you submitted as an excuse

[dead]

There is an in between here that developers seem to keep forgetting: Design the software architecture yourself — do some whiteboarding, figure out your abstractions and your UML, then write that in your prompt for the LLM to implement through a plan.

Velocity stays high. Cognitive overhead remains low. You know enough of your architecture from the “unit” level to see how the pieces work meaning you can still work fast and understand it without hating the quality it produces. This has worked wonders for my company; I’ve managed to personally write tools that are barely distinguishable from what I’d write by hand, and I’m confident enough to discuss its architecture from top to bottom. If the LLM ever produces a unit with a poor implementation, I just rewrite that unit.

Basically: do the “engineering” part of software engineering instead of throwing LLMs at the wall until code sticks. It doesn’t take much time to come up with a good design, compared to repeatedly iterating on a bad design and maintaining it for years to come.

LLMs suck at design, and that’s why they lead to this bad code. But if a human spends an hour to build nice SOLID abstractions, and tell the LLM each responsibility — they are pretty good at using and wiring these parts together.

My company recently had to cut back our usage to effectively nothing and I get to code by hand again. I'm going to appreciate it while I can. The AI just wasn't providing enough value for us

> I've also tried to understand the code that AI writes, but it's often insane and untangling it would slow me down

I hear that a lot, but it is very different from my experience using Claude Code every day. The code it generates is pretty much what I would have written myself. My colleagues have always said my code is easy to read and understand, so hopefully it is not just because my code is insane too :)

So I wonder: how are you using LLMs?

Some guy posted that project like a week ago on HN, no joke. Circle has been circled.

I honestly have a vision of a database of .md files that fully describes an application in human-readable, (ok, engineer-readable), text. Making a change is committing a change to the human-readable text, and then AI comes and figures out the rest and/or suggests edits to the human-readable text. (Or asks questions.)

My tiny two pet projects I keep developing with LLMs taught me how useful TDD is - I'm not a software engineer so I've been never formally introduced to these, but now I learn the best practices.

So in consequence I have less bugs in this code than what I could achieve myself, and as a second outcome of these is a solid workspace templates that make it faster and easier to get another small thing up to speed, the way that's good and "me". And the very short leash, sandbox and hooks make sure I learn a lot in the process too.

This is exactly how AI should be used when coding. "Agentic" AI produces garbage code. The entire codebase should never be accessible to the context (even if parts at a time, if the agent chooses the parts). And the entire codebase should never be write accessible. Only limited scope writes, human read, and approved.

You wouldn't be the first person to eventually conclude that C is just a very fancy macro assembler.

But AI generated code is much like every other generated code: it is more voluminous and rather less elegant than what you'd write as a person. And here too there is a link with assembly: early compilers routinely put out absolutely terrible assembly by assembly programmers' standards of the day. And then they got better. To the point that today it takes some pretty rare niches that it pays off to break out the assembler and roll your own.

I expect AI generated code to develop in the same way, and the way to get them to improve is to hold generated code to high standards. The problem is the perverse incentive: generated code of low quality will eventually result in many more tokens burned than a one-shot piece of perfect and elegant code. Here you can draw a link with medicine...

> Analogously, people can write in assembly, but can you write in assembly when the codebase is frequently altered by someone with an optimizing compiler?

Yes. There's an interface boundary in the form of function prototypes and ABI rules. To the optimizing compiler, your assembly code is undistinguishable from separately compiled high-level code, and to your assembly code, the compiler output is undistinguishable from separately assembled low-level code.

One problem with LLMs, is that they don't respect these boundaries like an optimizing compiler would.

> can you write in assembly when the codebase is frequently altered by someone with an optimizing compiler

This itself is quite normal (e.g. we have .S files and .c files and link them together), but I suppose a more accurate analogy would be that someone is dumping their optimising compiler output directly into your .S files.

Maybe what we need is better ways to partition the slop-code and the not-slop code.

Sounds like you just don't like the phrase 'higher level'. To most people this is synonymous to 'powerful abstractions' and 'more ergonomic abstractions' in the sense that they allow us to think "at a higher level" - map instead of loop, objects instead of memory addresses and size, modules instead of gotos.

My father-in-law has (among other things) done a fair amount of editing or proofreading prose, mostly on paper with red and blue pens. He says that when the page looks like it's covered in blood, that means it was good writing. For bad writing, it's so bad that you can't really work with it.

I would not want to take a block of text written by AI and try to edit it to sound human. It's too hard to fix. (And I suspect this is why people don't - they just paste the AI output.)

I think the same may be true of AI code. You're not going to fix it. You can't edit it to be the code you would write. All you can do is re-prompt to try to get the AI to fix it.

> I've never been the kind of coder

Looks like you were never really a coder, to be honest.

>> I've never been the kind of coder >Looks like you were never really a coder, to be honest.

I do not understand the bitterness here at all. AI is just a tool you can use for better or worse.

I learnt basic programming at an old age of 10 and 6502 assembler 2 years later from (paper)books.

There was no Internet and I dreamed of one day owning a magical software program called Macro Assembler so I could use labels and advanced loops in assembler programs instead of tediously translating examples from the book or magazines using a pencil and paper into assembly without such features.

The AI today is like that Macro Assembler for me back then. You, a human, are simply moved one layer of abstraction higher.

Did I enjoy writing that assembler back then when the goal was to complete a calculation in the time it took the crt tube's electron gun to draw one line on the screen? Sure. Would I want to write accounting software in it? Hell no.

There have been very crappy coders and great coders before and after AI. Just like almost no one writes assembler anymore, almost no one will write normal code in the age of AI. But knowledge of it, how it should be written is still going to be important.

Your value as a human is in the architecture of the software and choices that influence it's entire functioning. In maintainability, scalability and resilience present in your design from day 1 not added a year later.

You know how much slop and crappy work I saw before AI? A lot.

Is this a bot, or real..?

Way to completely miss the point of the article.

A big difference with libraries is that (hopefully) a whole lot of other people have used that same library the same way you are going to use it for the same purpose you are using it for. All the significant bugs hopefully were found by them and the library was fixed.

That usually makes it safe to use even if you have no idea how it does things inside.

With AI code there is a very good chance you are the first person to ever use that code.

I've inherited plenty of code bases. AI generated code is a special kind of foobar. With a code base inherited from a human you can at least be assured at least one human has understood each portion for a brief period. With agentic slop all bets are off.

IMO human-verifying will always be a must, no matter how good the LLMs get. If I'm shipping code that I don't understand and it ends up having major problems, I'm still the one who's responsible for it, not the LLM.

Where it really shines for me is when the best solution is explicit and obvious code, but really tedious to write. Now I'll choose to have AI write it instead of me, where before I might have tried to write a bad abstraction. Things like generating a TypedDict for a JSON A document I'm returning as a convenience from a postgres query.

What do you say to your boss if they ask why your colleague is producing 10-100x the kloc as you?

I also review all of my AI-generated code. I feel that it’s disrespectful to my teammates to send unverified slop for review.

I’ve noticed that while my coding skills have very noticeably atrophied (to the point I am consciously scheduling time to manually code, just for practice), my ability to read and comprehend code quickly has actually improved quite dramatically.

I notice style inconsistencies and semantic errors far more quickly and consistently when reviewing both human- and LLM-generated code, as compared to a year ago. Cognitive tradeoff hypothesis and all that…

That's not too different for crediting e.g. a typewriter as the tool used to author the text. That is, not ridiculous, but not new.

I don't see how that allegory relates. Understanding software is something that comes from education, time and experience. It can't he withheld to the same extent that it can't be magically imbued. AI can't give you that, because it doesn't have it to give.

Natural language can be ambiguous, though.

"The system should email the customer when their subscription renews."

When? Which timezone? What should we email them? Which email address (the customer changed their email 10 minutes ago, the address at time of the charge?)

I can look at a page of code and answer those questions pretty quickly.

You could write all of those in plain English, but then there are more tiny flaws in the ambiguous language. Maybe we could standardize the language in some way. To reduce ambiguity we start using keywords. When we want to refer to the same thing twice we create a variable or a type. Two things must interleave, let's create concurrency primitives. To check that the prompt is correct, we can write a test for it.

And maybe we DO end up with a different format of prompting that supplies this, but at some point we are still giving directions to computers. If those directions are lossy, the system runs differently every time (which I've noticed is bad for building good software).

How can you scrutinize something you don't understand?