Not parent poster, but I imagine it will be a bit like the horror stories of companies (ab)using spreadsheets in lieu of a proper program or database: They will use an LLM to get half-working stuff "for free" and consider it a bargain, especially if the detectable failures can be spot-fixed by an intern doing data-entry.

I think we'll see it first in internal reporting tools, where the stakeholder tries to explain something very specific they want to see (logical or not) and when it's visibly wrong they can work around it privately.

> Not parent poster, but I imagine it will be a bit like the horror stories of companies (ab)using spreadsheets in lieu of a proper program or database: They will use an LLM to get half-working stuff "for free" and consider it a bargain, especially if the detectable failures can be spot-fixed by an intern doing data-entry.

When I read things like this I really wonder if half of the people on HackerNews have ever held a job in software development (or a job at all to be fair).

None of what you describe is even remotely close to reality.

Stuff that half works gets you fully fired by the client.

If you can't even believe that kludgy-shit exists out there in the world, then it sounds like you've led a sheltered existence climbing within a very large engineering department of a well-funded company.

Do you perhaps have any friends at companies which hired overseas contractors? Or system-admins working at smaller companies or nonprofits? They're more-likely to have fun stories. I myself remember a university department with a master all_students.xls file on a shared drive (with way too many columns and macros in it) that had to be periodically restored from snapshots every time it got corrupted...

Are you sure you read the post you’re quoting correctly? They’re talking about companies that don’t have custom software at all, and cobble together half-working buggy spreadsheets and call the problem solved. Then the developers (either FT or contract) have to come in and build the tool that kills the spreadsheeet, once it gets too unwieldy.

I have seen the above story play out literally dozens of times in my career.

I think a lot of CRUD apps will disappear. A lot of the infrastructure may also be done by AI instead of some dude writing tons of YAML code.

The infrastructure is not a 'some dude writing tons of YAML code'.

CRUD apps should already be disappearing. You should be using a framework that auto-generates the boilerplate stuff.

> I think a lot of CRUD apps will disappear

How does that make any sense? How is AI, and especially GenAI, something that is by definition fallible, better in ANY way than current frameworks that allow you to write CRUD applications deterministically with basically one line of code per endpoint (if that)?

Recovering enterprise SaaS PM here. I don't necessarily know that a lot of enterprise SaaS will disappear, but I do think that a lot of the companies that build it will go out of business as their customers start to build more of their internal systems with LLMs vs. buy from an existing vendor. This is probably more true at the SMB level for now than actual enterprise, both for technical and internal politics reasons, but I expect it to spread.

As a direct example from myself, I now acquire and run small e-commerce brands. When I decided to move my inventory management from Google Sheets into an actual application, I looked at vendors but ultimately just decided to build my own. My coding skills are pretty minimal, but sufficient that I was able to produce what I needed with the help of LLMs. It has the advantages of being cheaper than buying and also purpose-built to my needs.

So yeah, basically the tl;dr is that for internal tools, I believe that LLMs giving non-developers sufficient coding skills will shift the build vs. buy calculus squarely in the direction of build, with the logical follow-on effects to companies trying to sell internal tools software.

Long-time enterprise SaaS PM here, and sorry, this does not make any sense. The SMB segment is likely to be the least exposed to AI, and software, and the concept of DIY software through AI.

As you visualize whole swaths of human workers getting automated away, also visualize the nitty gritty of day-to-day work with AI. If it gets something wrong, it will say "I apologize" until you, dear user, are blue in the face. If an actual person tried to do the same, the blueness would instead be on their, not your, face. Therein lies the value of a human worker. The big question, I think, is going to be: is that value commensurate to what we're making on our paycheck right now?

> If it gets something wrong, it will say "I apologize" until you, dear user, are blue in the face. If an actual person tried to do the same, the blueness would instead be on their, not your, face. Therein lies the value of a human worker.

The value of a human worker is in a more meaningful apology? I think the relevant question here is who's going to make more mistakes, not who's going to be responsible when they happen. A good human is better than AI today, but that's not going to last long.

> go out of business as their customers start to build more of their internal systems with LLMs vs. buy from an existing vendor.

there is going to be so much money to make as a consultant fixing these setups, I can't wait!

There is absolutely going to be a golden window of opportunity in which a person who understands LLMs can sell zero-effort, custom-crafted software to SMBs at the most insane margins of any business ever.

For trivial setups this might work, but for anything sufficiently complex that actually hits on real complexity in the domain, it's hard to see any LLM doing an adequate job. Especially if the person driving it doesn't know what they don't know about the domain.

> For trivial setups this might work, but for anything sufficiently complex that actually hits on real complexity in the domain, it's hard to see any LLM doing an adequate job.

I mostly agree with this for now, but obviously LLMs will continue to improve and be able to handle greater and greater complexity without issue.

> Especially if the person driving it doesn't know what they don't know about the domain.

Sure, but if the person driving it doesn't know what they're doing, they're also likely to do a poor job buying a solution (getting something that doesn't have all the features they need, selecting something needlessly complex, overpaying, etc.). Whether you're building or buying a piece of enterprise software, you want the person doing so to have plenty of domain expertise.

Amazing to see this comment downvoted. You're spot on, and I even think the feasible use cases will quickly move from internal tools to real line of business software. People are in denial or really have no idea what's coming.