HN user
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
Those bills are the reasons banks/credit card companies are pushing this since it holds them liable.
FOSTA-SESTA is the source of this. A well intentioned bill, that, once again, has unintended consequences beyond it's original intention.
Mastercard/Visa/Banks don't want legal liability.
It's because it's a weird mix of subsidies, price controls, regulations and bureaucracy that has completely distorted the market incentives.
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.
Or use both. Remote MCPs are secure, CLI allows for programmatic execution. Use bash to run remote MCPs.
I built this to solve this exact problem. https://github.com/turlockmike/murl
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).
We have 80 engineers.
The way LLMs work, different tokens can activate different parts of the network. I generally have 2-3 different agents review it from different perspectives. I give them identities, like Martin Fowler, or Uncle Bob, or whatever I think is relevant.
The code is still visible if i want to review it.
But since I have a strong rule about always writing unit tests before code, my confidence is a lot higher.
Not a lot of money because I haven't built enough confidence but yes it's the ultimate test of can it do economically useful work
Software engineering is being automated. But building intelligent automation is just starting. AI engineer will be the only job left in the future as long as there are things to automate. It's really all the other jobs that will be automated first before AI engineer.
My advice for juniors is that it's too late to get entry level jobs for software engineering, but AI Automation engineering is just starting. Get a Claude code sub and build whatever you can imagine and focus on improving your own coding agent. Automate one more thing every day.
I don't disagree, aspects of that will be automated, but two things will remain: Intent and Judgement.
Building AI systems will be about determining the right thing to build and ensuring your AI system fully understands it. For example, I have a trading bot that trades. I spent a lot of time on refining the optimization statement for the AI. If you give it the wrong goal or there's any ambiguity, it can go down the wrong path.
On the back end, I then judge the outcomes. As an engineer I can understand if the work it did actually accomplished the outcomes I wanted. In the future it will be applying that judgement to every field out there.
I mostly do this for work. These days I'm mostly building tooling for other devs. Observable memory system for coding, PR automation, CLI apps, dev coding dashboard, email automation. All of it integrating AI at various points (where intelligence is useful). All of that in the last two months alone.
Claude code skills represent a new type of AI native program. Give your agent the file system, let it build tools to sync and manage data.
Isn't this just RSS with extra steps?
This is where you can use adverserial systems.
1. Agent writes a minimal test against a spec. 2. Another agent writes minimal implementation to make test pass only.
Repeat
This is ping pong pair programming.
The role of an engineer is to produce software that probably works. If you are producing more bugs it's because you're skipping provability. AI is also really good at writing tests and doing test-driven development You can get 100% branching coverage. You use a secondary LLM to review the work and make sure everything follows best practices.
LLMs Can accelerate you if you use best practices and focus on provability and quality, but if you produce slop LLMs will help you produce slop faster.