Hacker News Reader

Comment by ivolimmen | Hacker News Reader

> Organizations are using agentic coding tools to build software in-house in lieu of purchasing it. Nearly a third of respondents (32 percent) report that their organizations have decided against buying one or more software products or features because they could be built internally with agentic coding tools.

People think they can do it themself... kind of like how everyone build their own database using Microsoft Access in the 90's. When all software developers needed to repair all the issues...

View on HN

I am at a point in my career where I'm figuring out where I want to spend the last 15 years of it. I don't want to work in corporate for a long stretch of it. It seems to me, being a consultant to fix all those messes could be a good seam of code face to get stuck into...

It's going to be a horrible job though, the equivalent of fixing Y2K bugs in Cobol code except with code bases that even more vast and unintelligible.

The LLMs are pretty good at helping with that though.

I want to believe this is witty sarcasm, given the topic, but you never know these days.

No, it's been my experience asking LLMs to explain complicated code to me. They can do a pretty good job of it. You can also ask them to write a bunch of tests and then rip out the old implementation and fix it with a new one. LLMs aren't perfect but they are really good at understanding and writing code.

It depends on what one's idea of an implementation is and what one's expectations are.

If an implementation is "a black box that works," absolutely, LLMs are fine. They can create complex programs in full.

But if one expects a tight implementation... it's a horror. LLMs vastly overengineer code (I believe they're intentionally designed to do so). I really struggle to make LLMs generate lean code.

In the best case, they generate bloated designs (in terms of complexity, not necessarily performance), but in the worst case, they generate gaps in the specification. And even in the first case - cognitive load is a problem also for LLMs, not just for humans (although obviously at a larger scale).

I think LLMs are essentially modern compilers, with similar problems, but designed more like "deoptimizing compilers" than optimizing ones. :)

In this subthread we’re talking about being paid to untangle LLM slop, and you come in to say “LLMs are good for that.” Come on man, be serious.

It's right though.

There exists no evidence that manually trying to fix or rewrite the system is going to be more efficient today.

And if AI improves even half as fast as it did over the last year, all bets are off for what 2028 will look like.

It will be messes of python scripts running on some ancient version of python that you have to switch between scripts. All in a folder on some laptop with an outdated OS that you cannot update or everything will break. Business logic obviously not documented anywhere, just mountains and mountains of slop readmes that might be accurate, but also might not be.

Yeah, unreasonable deadlines (these are the norm) spent trying to untangle a mass of overly verbose spaghetti code, and chances are there is no budget for you to do it properly, they contracted you only for a ‘bugfix’. It’s just more technical debt on top of technical debt.

No, thank you. I’ll leave the underpaid disinfestation job to someone else.

The best fun is when you’ll be called in not to untangle the LLM mess, but to build new features on top of its nonsense architecture and API design, but expected to do it by hand because they have lost confidence in AI.

You will be able to easily rewrite with better technical decisions with the assistance of LLMs in that case.

Also the Y2K folks made bank IIRC.

Our company offered all programmers $1000 to spend the night in the office. But they sent us home around 4am.

The same time many of the overnight jobs started up :-)

Fortunately we had zero issues.

These days ppl often (usually?) simply ask an LLM to replce something rather than debugging it (or if they ask the LLM to debug they get a different snarl of code).

So rather than debug a steaming pile of code you might be be able to treat it as a greenfield opportunity.

On the other hand, if you let in-house devs own your enterprise software, in many places it's going to be months of meetings to get the smallest change implemented.

Plenty of companies run most of their internal operations on Excel and Access for exactly this reason. And most developers barely know anything about databases anyway.

Are you implying that getting $MEGASaaS to implement a feature for you is faster than doing it in-house? Because that is absolutely not the norm.

All my software development friends know how to use databases. I am interested in what kind of developers you know that don't...

Except that isn't how it played out. Most of the Access DBs, spreadsheets, and even SharePoint, Notes, and early Salesforce apps worked just fine without any help from devs. Yes, the devs got called in when those solutions needed to scale beyond a single department, but most of them never did.

It is far more plausible that we'll see that pattern again - small, department-level vibe coded apps will be around. And things that need to scale bigger will need professionals.

We can do it ourselves. Simple custom tools are so much more effective than a conglomeration of general purpose ones. I've been ripping out SaaS offerings left and right, it's great.

"decided against buying one or more software products or features"

I suspect the "or features" there is doing a lot of work.

Reply on news.ycombinator.com