Sure, if it is just about installing a package. But installing a program, reading documentation, then configuring the right settings, confirming it is doing what you want it to do, find out that's something wrong, going back to the docs... all of that can be automated.
And it's not just about installing, it's also about fixing issues. I had an intermittent DNS issue that I was not able to track down, and I didn't have enough time to dedicate myself to instrumenting my devices to chase it. I dropped a single line to an agent. It quickly wrote a test script, kept monitoring, when the problem manifested it tracked it down to a wrong IPV6 DNS config, crafted the pull request to fix it on my router (I have the homelab configured via gitops, local gitea).
I was also playing a windows game on linux and I had a weird mouse issue. Reading forums and bug trackers didn't do the trick and I threw the towel. I asked the agent. It grabbed the system (and game) logs, and figured out a fix. In a couple of minutes.
I would eventually find those issues, given enough time. But I don't have to anymore.
> But installing a program, reading documentation, then configuring the right settings, confirming it is doing what you want it to do, find out that's something wrong, going back to the docs... all of that can be automated.
It certainly can be automated. What you gain in productivity you loose in proficiency and self-reliance since you're depending on others, an artificial 'other' in this case but it is more or less like asking your nerdy friend to install that Linux thing for you. When it breaks you'll have to ask that nerdy friend again, or that agent again in this case. When the agent is unavailable it is just as if the nerdy friend went on holiday leaving you to fend for yourself.
You may be OK with this dependency but it is good to realise it exists. Could you still fix things after having used agents for a few months or years? Probably not, at least not without you needing to read all that documentation, try and test, fail, go back to the documentation and try again until you get it to work.
> an artificial 'other' in this case but it is more or less like asking your nerdy friend to install that Linux thing for you. When it breaks you'll have to ask that nerdy friend again
It's either asking that nerdy friend again, 2 years from now when it breaks. Just like you would your own documentation and/or SO or Google. Zero difference except one saves you time.
Well, yes, or you make sure you can do that stuff yourself by actually doing it instead of leaving it to an agent. If you have to do it often you can leave some to agents but still do a few yourself so that you keep up to date and also can check whether what the agents do makes sense. You'll still save time, it might not even cost you any real time if you can handle a few cases while the agents take care of the others and you both finish around the same time. The agents may have done 10 times as much work as you did in that time but since you'd otherwise just have been waiting for them to do their thing you're not losing anything while you gain (or keep) experience.
Prompt injection is indeed a thing. You are not paranoid. Even more so if the LLM in question is not very smart (frontier models are better at not falling for prompt injection, but not immune).
I don't think OP literally meant the agent is running as root though. "| bash" shouldn't do anything more than the user the agent is running at can do. The bigger threat is an instruction to "install in the box". Then the agent could reach out to the container and do just that.
And arguably harder to read and maintain other people's software.
Don't get me wrong I'm a macro fan. I've worked with some elegant codebases using metaprogramming but it's been challenging bringing people up to speed with super clear efficient - but novel - code,
Other projects that were just down the line Java boilerplate built on a well understood library worked just as well in other ways.
Personally I think reducing cognitive load is key, I've found people don't have the energy to work with clever code, even if it makes writing it a delight.
... and then llms happened, and I now don't write code at all but closely review a fire hose of mediocrity that gets the job done. I don't want that too magical.
My sleep doctor was skeptical that I had sleep apnea during my initial consult because I indicated I don’t doze off unintentionally, even though I told her I consume 1000mg of caffeine a day to manage the sleepiness. I did tell her I took intentional naps on the weekends.
My sleep study revealed an average of 39 apnea events an hour and now I have a CPAP and am sleeping much better!
> I wonder if this study is missing some quite big issues here.
Definitely seems like a possible "correlation is not causation".
I would find it hard to believe that sleep is somehow biologically harmful.
So, like your example, excessive or unintentionally napping is instead a sign of an underlying issue or poor health. Possibly the body trying to sleep to repair some damage?
> I don't think an LLM should ever be having a two-way conversation with the player. It would be more suited to 2 npcs having conversations amongst themselves. All dialogue delivered to the player should be human written.
I don't agree. All -important- dialogue yes. Background NPC chatter? Even when studios spend a lot of effort crafting multiple lines, pretty soon you have seen them all. They also don't change based on player actions.
When you just need a few parts to be made, it is sometimes very tempting to drop a chest, fill it up with parts, then go do something else, one of the 1000 tasks you have been neglecting.
That's definitely true, but only to a certain point, after a while it becomes too monotonous to dig around in chests building and combining stuff in an ad hoc manner. LLMs have no problem with that kind of repetitive minutia though.
Logistic bots, once they are unlocked, the game becomes trivial.
Once you make a few blueprints, then the real joy of factorio is found. Nothing like splatting down an outpost and watching it sprint into existence as thousands of “agents” build it out.
Really not surprising given the history of sloppy coding, elementary authentication mistakes, outsourced "support", and anecdotal reports of horrid internal culture over the past few years
This scaling approach is unsustainable, it is generating diminishing returns and ballooning costs. It is already blowing up.
reply