Feed

Pi is written by Mario Zechner and unlike Peter, who aims for "sci-fi with a touch of madness," Mario is very grounded. Despite the differences in approach, both OpenClaw and Pi follow the same idea: LLMs are really good at writing and running code, so embrace this.

I think the upshot of all of this is that there is a lot of value to actively managing your agents' vibes and feelings, not just treating them as text-generation robots. The models aren't alive, but thinking of them as having feelings, rather than just next-token-prediction engines can help you nudge their mental states into a better place. I think you'll like the results.

As a business school professor, I think many people have the skills they need, or can learn them, in order to work with AI agents - they are management 101 skills. If you can explain what you need, give effective feedback, and design ways of evaluating work, you are going to be able to work with agents. In many ways, at least in your area of expertise, it is much easier than trying to design clever prompts to help you get work done, as it is more like working with people. At the same time, management has always assumed scarcity: you delegate because you can't do everything yourself, and because talent is limited and expensive. AI changes the equation. Now the "talent" is abundant and cheap. What's scarce is knowing what to ask for.

My bet is that most parts of cyberoffense and cyberdefense are going to move to running at "machine speed", where humans get taken out of most of the critical loops. This will both increase the frequency of hacking attacks while also dramatically scaling up the effectiveness of any individual human defender or attacker (as they will be scaled by AI systems which work for them). The true wildcard question is whether this turns out to be offense- or defense-dominant – my guess is we're heading for an era of offense-dominance as it'll take a while for defenses to get deployed.

With general intelligence, you can go a layer deeper: you can accelerate the acceleration. You don't just write the prompt that fixes the code; you build the evaluation pipeline that automatically optimizes the prompts. You stop working on the work, and start working on the optimization of the work. You shift from First-Order execution (doing the thing), to Second-Order automation (improving the system), to Third-Order meta-optimization (automating the improvement of the system). AI eats the lower derivatives, constantly pushing you up the stack to become the architect of the machine that builds the machine.

You can't leave anything on the table. This is Amdahl's Law for AI transformation: as the "core" work approaches zero duration, the "trivial" manual steps you ignored—the 10-minute deploy, the manual data entry on a UI, the waiting for CI—become the entire bottleneck. The speed of your system is no longer determined by how fast you code, but by the one thing you didn't automate5. If an agent can fix a bug in 5 minutes but it takes 3 days for Security to review the text or 2 days for Design to approve the padding, the organization has become the bug. You need to treat organizational latency with the same severity you treat server latency.

I'm still skeptical of vibecoding in general. As I mentioned above, I would not trust my vibecoding enough to make these into products. If something goes wrong, I don't know how to fix it. Maybe my LLM friends can, but I don't know. But vibecoding is 100% viable for personal stuff like this: we now have apps on demand.

I expect that the following is going to get worse before it gets better.

Many of us got hit by the agent coding addiction. It feels good, we barely sleep, we build amazing things. Every once in a while that interaction involves other humans, and all of a sudden we get a reality check that maybe we overdid it. The most obvious example of this is the massive degradation of quality of issue reports and pull requests. As a maintainer many PRs now look like an insult to one's time, but when one pushes back, the other person does not see what they did wrong. They thought they helped and contributed and get agitated when you close it down.

I often feel like this as well. I think however that the truth is that what we now consider code quality isn't as important as we think it is.

Or maybe some of us are genuinely losing the plot, and we won't know which camp we're in until we look back. All I know is that when I watch someone at 3am, running their tenth parallel agent session, telling me they've never been more productive — in that moment I don't see productivity. I see someone who might need to step away from the machine for a bit. And I wonder how often that someone is me.

I'm more worried about the need to step away from the computer. Not because of the code quality issue but more from the addiction part of it. So far there is always some new feature, some new tool or some new idea. The kind of thought process it takes to dream up what to do is less daunting than writing the code by hand. I personally have to make myself stop. I don't really get worn out working this way. I get sleepy.

1994: The web browser Netscape Navigator introduces encrypted HTTPS (HTTP over SSL) protocol that shows a warning when used, so people can make an informed decision to be secure or not by doing their own research.

The world is going to look a lot like Core Wars – millions of AI agents will be competing against one another in a variety of domains, ranging from cybersecurity to economics, and will be optimizing themselves in relation to achieving certain competitive criteria. The result will be sustained, broad evolution of AI systems and the software harnesses and tooling they use to get stuff done. This means that along with human developers and potential AI-designed improvements, we'll also see AI systems improve from this kind of broad competitive pressure.

Jobs go away, but humans don't: Another way to put this is, when a task gets automated it's not like the company in question suddenly fires all the people doing that job. Consider ATMs and banking – yes, the 'job' of doling out cash rapidly transitioned from people to machines, but it's not like the company fired all tellers – rather, the companies and the tellers transitioned the work to something else: "Under a separable task model, this [widespread deployment of ATMs doing cash-handling tasks] should have produced sharp displacement," they write. "Yet teller employment did not collapse; rather, the occupation shifted toward "relationship banking" and higher-value customer interaction".