link-

AI is a polymath’s wet dream

There’s no torture like this torture.

For anyone spending their weekend patching their homelabs, VPSs, or anything self-hosted

$> tmux new -s copilot-patching

CTRL+b c

New window for each VM / VPS

SSH into your VMs and PVEs in each window

Then ask your agent to use the copilot-patching tmux session to do the upgrades, cleanups, hardening of your setup, fixing your firewall settings.

You're welcome.

We've entered the phase of AI writing code that I can barely understand.

The worst part is that even if I align with the model on a methodology, the agentic harnesses are fully encapsulating the intermediary steps needed to make sure the model & agent stay on track.

I often find myself needing to have elaborate "debriefings" after the fact to force the agent to reveal "how" it went about its work, and for the past several weeks those haven't ended well.

I've been experiencing:

- Misalignment on intentions that were never part of the context, because I'll always have context that is just not written anywhere.

- Assumptions made by the models in the intermediary steps that were never shared with me, but the model assumed they were OK.

- Exaggerating or diminishing information so that the agent can reach its objective and terminate its task; there is definitely some bias towards "finishing" work.

- Elaborate use of tools that I didn't sanction myself. For example, one model decided to load GiBs of data into a local sqlite instance to run some queries on it and remove duplicates.

The people building demoware, prototypes, throwaway apps, self-hosted solutions will most likely not experience these issues. The tasks are most likely simple, isolated, and straightforward.

The engineers running large, mission- or business-critical systems (distributed or otherwise), building on top of years of embedded institutional knowledge, mistakes are not acceptable.

I don't have solutions to these problems. I'm currently experimenting with:

1. Forcing the models to use simple language, not to invent jargon especially that's not provided as context.

2. Forcing the models to maintain an evidence trail especially when they are running data analysis work for me.

3. To do a step-by-step walkthrough of their method and to demonstrate with evidence the outcomes they're presenting to me.

4. To maintain artifacts of the input and output so that I can review on a need basis.

This is a dangerous phase. The cutting edge models are very good at making you "believe they're trustworthy."

I often find them using unnecessarily complicated language, which can evoke in the reader a sense of trust in the outcome. Do not fall for this trap.

Verify.

Reviewing pull requests you don't even understand isn't going to save you.

I wonder how Go would be like without garbage collection and explicit memory management capabilities 🤔