[jimbo808]

I have read this same comment so many times in various forms. I know many of them are shill accounts/bots, but many are real. I think there are a few things at play that make people feel this way. Even if you're in a CRUD shop with low standards for reliability/scale/performance/efficiency, a person who isn't an experienced engineer could not make the LLM do your job. LLMs have a perfect combination of traits that cause people to overestimate their utility. The biggest one I think is that their utility is super front-loaded.

If a task before would take you ten hours to think through the thing, translate that into an implementation approach, implement it, and test it, and at the end of the ten hours you're 100% there and you've got a good implementation which you understand and can explain to colleagues in detail later if needed. Your code was written by a human expert with intention, and you reviewed it as you wrote it and as you planned the work out.

With an LLM, you spend the same amount of time figuring out what you're going to do, plus more time writing detailed prompts and making the requisite files and context available for the LLM, then you press a button and tada, five minutes later you have a whole bunch of code. And it sorta seems to work. This gives you a big burst of dopamine due to the randomness of the result. So now, with your dopamine levels high and your work seemingly basically done, your brain registers that work as having been done in those five minutes.

But you now (if you're doing work people are willing to pay you for), you probably have to actually verify that it didn't break things or cause huge security holes, and clean up the redundant code and other exceedingly verbose garbage it generated. This is not the same process as verifying your own code. First, LLM output is meant to look as correct as possible, and it will do some REALLY incorrect things that no sane person would do that are not easy to spot in the same way you'd spot them if it were human-written. You also don't really know what all of this shit is - it almost always has a ton of redundant code, or just exceedingly verbose nonsense that ends up being technical debt and more tokens in the context for the next session. So now you have to carefully review it. You have to test things you wouldn't have had to test, with much more care, and you have to look for things that are hard to spot, like redundant code or regressions with other features it shouldn't have touched. And you have to actually make sure it did what you told it to, because sometimes it says it did, and it just didn't. This is a whole process. You're far from done here, and this (to me at least) can only be done by a professional. It's not hard - it's tedious and boring, but it does require your learned expertise.

[ash-b-dev]

I think a lot of the proliferation of AI as a self-coding agent has been driven by devs who haven’t written much meaningful code, so whatever the LLM spits out looks great to them because it runs. People don’t actually read the AI’s code unless something breaks.

[likium]

So set up e2e tests and make sure it does things you said you wanted. Just like how you use a library or database. Trust, but verify. Only if it breaks do you have to peak under the covers.

Sadly people do not care about redundant and verbose code. If that was a concern, we wouldn't have 100+mb of apps, nor 5mb web app bundles. Multibillion b2b apps shipping a 10mb json file just for searching emojis and no one blinks an eye.

[skydhash]

The effort to set up e2e tests can be more than just writing the thing. Especially for UI as computers just does not interpret things as humans do (spatial relation, overflow, low to no contrast between elements).

[torginus]

I just wanna make the point that I've grown to dislike the term 'CRUD' especially as a disparaging remark against some software. Every web application I've worked on featured a database, that you could usually query or change through a web interface, but that was an easy and small part of the whole thing it did.

Is a webshop a CRUD app? Is an employee shift tracking site? I could go on, but I feel 'CRUD' app is about as meaningful a moniker as 'desktop app'

[jimbo808]

It's a pretty easy category to identify, some warning signs:

- You rarely write loops at work

- Every performance issue is either too many trips to the database or to some server

- You can write O(n^n) functions and nobody will ever notice

- The hardest technical problem anyone can remember was an N+1 query and it stuck around for like a year before enough people complained and you added an index

- You don't really ever have to make difficult engineering decisions, but if you do, you can make the wrong one most of the time and it'll be fine

- Nobody in the shop could explain: lock convoying, GC pauses, noisy neighbors, cache eviction cascades, one hot shard, correlating traces with scheduler behavior, connection pool saturation, thread starvation, backpressure propagation across multiple services, etc

I spent a few years in shops like this, if this is you, you must fight the urge to get comfortable because the vibe coders are coming for you.

[eitally]

There are exceptions to what I'm about to say, but it is largely the rule.

The thing a lot of people who haven't lived it don't seem to recognize is that enterprise software is usually buggy and brittle, and that's both expected and accepted because most IT organizations have never paid for top technical talent. If you're creating apps for back office use, or even supply chain and sometimes customer facing stuff, frequently 95% availability is good enough, and things that only work about 90-95% of the time without bugs is also good enough. There's such an ingrained mentality in big business that "internal tools suck" that even if AI-generated tools also suck similarly it's still going to be good enough for most use cases.

It's important for readers in a place like HN to realize that the majority of software in the world is not created in our tech bubble, and most apps only have an audience ranging from dozens to several thousands of users.

[jimbo808]

Internal tools do suck as far as usability, but you can bet your ass they work if they're doing things that matter to the business, which is most of them. Almost every enterprise system hooks into the finance/accounting pipeline to varying degrees. If these systems do not work at your company I'd like to know which company you work at and whether they're publicly traded.

[abracadaniel]

A potential difference I see is that when internal tools break, you generally have people with a full mental model of the tool who can take manual intervention. Of course, that fails when you lay off the only people with that knowledge, which leads to the cycle of “let’s just rewrite it, the old code is awful”. With AI it seems like your starting point is that failure mode of a lack of knowledge and a mental model of the tool.