Hacker News Reader

Comment by joshuahutt | Hacker News Reader

I feel the same way.

I think the immediate future is bright. Some will try to cram this technology into enterprise. It will do well. Those jobs will die. Others will leverage it alongside the more creative engineering tasks—they will thrive.

Eventually, what we call software will change from what it is today into something much more accessible to these types of tools. The plateau we've landed on is just a compromise between the technology, economies, and culture of its time.

As this type of tech pervades our everyday lives, much of the widespread need for specialized software will evaporate. The remaining work will be in the corners or the edges of what's possible—highly technical or vertically integrated work (particularly, hardware-integrated stuff), as well as platform engineering to sustain the new paradigm.

View on HN

> Eventually, what we call software will change from what it is today into something much more accessible to these types of tools.

That's a very good point. There's that tongue-in-check assertion that Java as a language isn't a human-facing but rather a tool-facing programming language. And now I'm wondering, what would a high-level language that is actually designed from the ground up for manipulation by AIs rather than humans look like. And in contrast, I think that the human-facing interface to it might end up much more visual and graph-oriented, possibly similar to Unreal Engine's blueprints.

Good question.

I expect that we're moving into a phase of AIs talking to AIs, and initially it'll be wasteful (because it'll be mostly English), but eventually, they'll derive their own language and seamlessly upgrade protocols when they determine they're talking to an AI. No clue how that will come about or what that language will look like, but honestly, it's kind of exciting.

Really interesting to think about how they might handle context, as well. Even though we have much bigger context windows (and they'll only get larger), context management is still a resource-management issue, which we'll probably continue to refine, as well. Imagine different strategies for managing both what is brought into the context of each request, as well as what form it could take (level of detail, additional references or commentary on it, etc). Things could get really unreadable even in English, and still be very interpretable for an LLM.

W.r.t. the graph-oriented interfaces, are you thinking something like Node-RED [1]? I'm seeing more and more people mention having LLMs produce non-text or structured outputs, like JSON, UI, and other things. Easy to imagine an LLM that wires together various open-source platforms, on-demand. Something like Node-RED for pipelines/functions, some UI tools for visualization/interactivity, other platforms for messaging, etc...

[1] https://nodered.org/

Reply on news.ycombinator.com