Hacker News Reader

Comment by cgearhart | Hacker News Reader

I’m starting to realize that LLMs are really good at building low-stakes projects. Your questions mostly presume that the stakes are higher. The software will last a long time; the requirements will evolve; we can’t tolerate mistakes; etc.

The trick to getting good at using LLMs for software is to learn how to make _all_ projects low-stakes.

View on HN

You don't need LLM for that. You make _all_ projects low-stakes by working on green field project using (insert buzzword soup of the day) and leaving for a new green field opportunity (that requires experience with buzzword soup of the day) before the project ships.

No, what you’re describing still requires you to do some actual work, and also, while you work there, there is still some level of accountability. A much, much better grift is coaching.

Like, an AI coaching session for executives at the yearly executive retreat. You show up, spend a few hours going through some nonsense slides ChatGPT put together for you, you charge an eye watering fee for it, HR or whoever organizes it will gladly pay for it because it will make them look all cutting edge in front of the CEO, by the next day everyone will forget about it. No accountability at all!

In the LLM world you never get a chance to get paid to work on those greenfield projects because the person with the idea is churning the prototyping and discovery work themselves.

If you want to get paid to work on software, you get involved after its found success and the stakes get higher.

(Which assumes there are still significant areas where economies of scale reward that vs everybody just having their own DIY version of everything.)

Or economies of liability and buck passing. I suspect managers and businesses will still want to be in the game of "not my fault, supplier is working on it, we can sue them if they don't meet SLA".

You've got to be the person with the idea. I'm currently doing that. I spent the past year working on a frustrating project where everybody else did everything wrong, so now I'm building it on my own, hoping to sell it to them. (No idea if that will work)

This is really insightful, but I think it also extends to making the project either low stakes or low complexity. I have this lurking feeling that the preferable architecture for software will change as a result of LLMs because they're good at working on low complexity modular components more than they are on high complexity million-line code bases.

You'll just shift complexity to the orchestration of the modular components.

Monoliths vs micro-services.

There's some truth here. But in carefully orchestrated scenarios (the minority, to be sure), it can work surprisingly well, I think.

They aren't necessarily as great at building low-complexity high-modularity components, though. ;)

Unless you know enough to tell them to! And keep them honest about it...

If there's a viable way to make all projects low-stakes we'd have done it. Consider this: microservices.

> The trick to getting good at using LLMs for software is to learn how to make _all_ projects low-stakes.

this doesn't really work in the real world. There are many things that actually matter, engineering is fundamentally about handling them.

But not all projects can be low stakes. None of the important ones are.

Reply on news.ycombinator.com