I think complex systems will still turn into a big ball of mud and AI agents will get just as bogged down as humans when dealing with it. And even though re-build from scratch is cheaper than ever, it can't possibly be done cheaply while also remembering the millions+ of specific characteristics that users will have come to rely on.

Maybe if you pushed spec-driven development to the absolute extreme, but i don't think pushing it that far is easy/cheap. Just as the effort to go from 90% unit test coverage to 100% is hard and possibly not worth it, I expect a similar barrier around extreme spec-driven.

Clarification: I'm advocating clean code in the generic sense, not Uncle Bob's definition.

I mean, "tapestry" is a great word for something that is interconnected. Why not use it?

Most of the dev teams I've ever encountered who said they were "doing REST" were not actually following HATEOAS. Per a strict reading of Roy Fielding, he would consider that "not really REST." (Now don't get distracted, I don't want to wade into that whole purist debate).

The reason many did not do HATEOAS is that it requires the API client to be smart and adaptive. It would discover "ok, what can i do next", apply logic to it, and choose the next step. But many shops were on tight time commitments and it was much simpler to just think of REST as "json over http with consistent url patterns."

The cool thing is: With an LLM in the mix, HATEOAS is unchained. An LLM can do exactly what a "dumb" api client cannot: ask "what can i do next", and then use _inference_ to understand those options and select one.

Comments URL: https://news.ycombinator.com/item?id=47263179

Points: 3

# Comments: 1

I don't quite follow but I'd love to hear more about that.

Rust is great, but there's no need to manage memory manually if you don't need to.

So for general mainstream languages, that leaves ... Python. Sure, it's ok but Go has strong typing from the start, not bolted on with warts.

(I realized how incredibly subjective this comment turned out to be after I had written it. Apologies if I omitted or slighted your fave. This is pretty much how I see it).

They would get amazing amounts done, but no one else could understand the internals because they were so uniquely shaped by the inner nuances of one mind.

Google generates a lot of revenue per employee not because the employees are good (though many of them are of course), but because they own the front door to the web. And the Knight Capital story has many nuances left out by that summary.

In both cases the author needed a hard hitting but terse example. But as I said, both the claims are true, so in the voice of the courtroom judge, "I'll allow it."

The "is this cloud or not" debate in the piece makes perfect sense. Who cares whether Hetzner is defined as "the cloud" or not? The point is, he left AWS without going to Azure or some other obvious cloud vendor. He took a step towards more hands on management. And he saved a ton of money.

I found myself astounded, struck speechless, and moved to tears. I was in awe.

Gaudi is someone we software engineers should revere. He made things precisely and powerfully functional while also making them beautiful.

Do not miss seeing Sagrada Familia if you ever get the chance.