← Back to context

Comment by tripleee

2 days ago

I don't think they're the same. AI code isn't just complex because it's huge.. it's complex because it makes no sense

If you have a large human-written system with a little thought put into it you should be able to find the specific pieces that handle the behavior you want and work on that, and if it's good then changing it should have a small blast radius and be covered with regression tests

In contrast, I've fully vibe coded a 15k line tool for myself with Opus and I have no idea how on earth it's architected after reading through it. It has "tests" but I don't trust them. It's just all over the place with no coherent design to it. It works, but it's making me more and more nervous to change it

You can tell with some of the more recent models that they have been fine-tuned in such a way to produce a lot of descriptions that sound impressive but have no real meaning. In terms of production of semantic text, the recent models are significantly worse than a year ago.

It is not completely useless as a tool but there is still a huge gap in most real-world applications (I work in an org with multiple thousands of devs and I am top 5 AI user consistently, I have used Claude Code since pre-release). If you are building something like an SQL database which has decades of logic tests built by humans then it can work. If you do not have this (i.e. 99.99% of the time) then you still need to be able to issue prompts that give context. And if you start without that context, it will produce shit code in extremely basic scenarios. In particular, humans are far better at producing code that is easy to change (in practice, you need to create unintuitive, non-human rules to govern this i.e. creating many artificial boundaries which would be completely unnecessary for humans).

I am not sure whether the models just capped out in terms of coding or whether they are just trained by people who have never worked on enterprise software but the gap isn't closing. It has just been filled by people who lack the knowledge to identify when they are being bullshitted (the prevalence of consultants suggests that this markets is large).

I have worked on legacy stuff before. In most cases, there is a kernel of reason and logic that can be recovered. I have seen pure AI projects and they are the worst grade of TCS-authored abandonware. They can often do one specific thing but are basically unmaintainable outside of that.

  • > You can tell with some of the more recent models that they have been fine-tuned in such a way to produce a lot of descriptions that sound impressive but have no real meaning. In terms of production of semantic text, the recent models are significantly worse than a year ago.

    I frequently find this in LLM generated comments, both when using an LLM myself or when reviewing code that someone else used an LLM for. I find it is often the most obvious indication that nobody really read through what was generated.

  • Yes, it has become quite common that Claude’s text feedback, e.g. Claude found an issue in the existing code that requires a decision and Claude tries to explain it, it is a paragraph of bullshit words stringed together.

    Then you investigate it and it is often something relatively simple that could have been explained with short sentence.

    • Have you found a way to stop this?

      I used that engineering language skill which is good when it uses it...but it doesn't like to use it.

      ...there are clearly some areas of alignment that they are not looking at.

  • We had one that hallucinated benchmarks, with graphs and everything! (The code didn't actually work.)

I vibecoded a project without looking at the code as an experiment, and I had the same experience as you. It really drives home the point that, left to their own devices, LLMs produce abysmal code.

If you give them no constraints, they’ll produce code that just works, and it’ll look exactly like that.

We already know the solution to this problem. Software engineering. Put the LLM through the same grinder as any software dev and out constraints into place. Tell the LLM that the code design is bad and that it should improve it.

In my case, I had to go through several rounds of refactoring before the code at least resembled a good codebase.

A fun fact is that the refactorings didn’t break any functionality. Only adding new features broke preexisting behavior.

  • I don't think this is the case anymore if you're using the latest expensive models, i.e fable.

I'm trying to learn how to write software with agents where I keep control over the design while yielding control over the implementation.

This is not very different from what already happens to architects that delegate implementation to teams.

The challenge Is to find a way to encode the architecture in a way that both you and the agents can understand and agree on.

I'm still learning how to do this effectively, but my initial experience is quite positive. Not because agents are great but because humans are bad; the degree of coherence I've seen agents following is bigger than many human teams I've led in my career.

My benchmark is a quite big project for which the architecture is already well known, namely the reimplementation of the OpenVMS OS (kernel and user-land). There are many traps and many opportunities for the agents to just go ahead and diverge from the goals, so I found it a good playground toearn how reign them in but let them be effective at "drawing the rest of the owl"

i still havent seen claude write code as bad as legacy spaghetti, but i guess im never quite vibe coding since i usually have an idea of the architecture i want, and that leaks into my prompts about how it should approach the problem and verification of the solution?