My general principal is the cost of deleting code should be as low as possible and that includes the entire application as long as the data is around and easy to repurpose then the program itself should be as deletable as possible
It lacks a critical self, but the weights are there for in context learning and nudging behaviour. It's goal is to complete whatever task is given. You need to make sure the outcome you want is clearly defined.
You don't need elaborate prompts, just a few lines
"All code must have corresponding tests written ahead of time to prove the code meets the specification" is sufficient for most use cases. Prose can help nudge it more if it isn't adhearing consistently.
The better way to do this is give them each an inbox and outbox folder and a user account on a Unix machine.
They can write to their outbox, have it be sent to the other's inbox. A watcher can watch for new messages in the inbox and trigger the other agent to read it. You can have the thread Id of the messages correspond to the session id.
We don't need to reinvent things that Unix provides.
This website and article promote the destruction of property. If you disagree with something, you can engage civily, encourage people to vote with you, run for elections. Violence is not the answer.
Banks didn't do this before 2018 as aggressively. Reputational stuff is always been there and chargebacks have always been there. This law is why they've been so aggressive over the last few years. There's nothing else that has changed
The best way to prompt an LLM is to describe the outcome you want, that's it. They are trained as task completers. A clear outcome is way better than a process.
If the LLM fails, either you didn't describe your outcome sufficiently or is misinterpreted what you said or it couldn't do it (rare).
Common errors should be encoded as context for future similar tasks, don't bloat skills with stuff that isn't shown to be necessary.
LLMs don't care about mcp vs CLI. CLIs enable LLMs to fetch/mutate data and build scripts with the same program. I think of it like a Linux dev in a box. Sometimes you want to just call a tool, sometimes you want to write a small program that calls that tool instead.
MCPs are basically just JSON-rpc. The benefit is that if you have applications that require an API key, you can build a server to control access (especially for enterprise). It's the same as REST apis, except by following a specific convention we can take advantage of generic tools (like the one I built) and means you don't need to rely on poor documentations to connect or train a model to use your very specific CLI.
How many kernel devs does the world need? A dozen or two?
It will be the same with software. AI will be writing and consuming most software. We will be utilizing experiences built on top of that, probably generated in real time for hyper personalization. Every app on your phone will be replaced by one app. (Except maybe games, at least for a short while longer).
Everyone's treating writing code as this reverent thing. No one wrote code 100 years ago. Very few today write assembly. It will become lost because the economic neccesity is gone.
It's the end of an era, but also the beginning of a new one. Building agentic systems is really hard, a hard enough problem that we need a ton of people building those systems. AI hardware devices have barely been registered, we need engineers who can build and integrate all sorts of systems.
Engineering as a discipline will be the last job to be automated, since who do you think is going to build all the worlds automation?
Every problem you described is solvable and while it may not be solved right now or even in 6 months it'll probably be solved within 18 months. It's just scaling and tuning the models
I deleted vscode and replaced with a hyper personal dashboard that combines information from everywhere.
I have a news feed, work tab for managing issues/PRs, markdown editor with folders, calendar, AI powered buttons all over the place (I click a button, it does something interesting with Claude code I can't do programmatically).
Why don't I share it? Because it's highly personal, others would find it doesn't fit their own workflow.
One craft is automated and a new one is just beginning.
Building AI agents is really fun and the problem of having them be reliable adaptable efficient is actually really challenging and I'm having a lot of fun with it trying to figure it out.
To me it's a lot like factorio or my personal favorite Dyson sphere program where at first you do everything by hand and then you automate and then you automate the automation.
For the first time in human history we can automate intelligence with a computer but just because we can automate it doesn't mean all the good automation is good and we need engineers who can figure out how to automate it reliably scale it deploy it maintain it.
And yes eventually we will automate the automation too.
Unregulate the insurance industries problem solved. Let people actually buy insurance for it's intended purpose. No insurance company would pay these rates willingly, they do it because of all the regulations. They aren't allowed to profit normally, so they find ways around it. Just let them operate normally, like all sorts of other insurance programs.
My trading agent builds its own models, does backtesting, builds tools for real time analysis and trading. I wrote zero of the code, i haven't even seen the code. The only thing I make sure is that it's continuously self improving (since I haven't been able to figure out how to automate that yet).