Links/#ai-agents×/8 entries

I can now hand much of the mechanical work to an AI coding tool, then spend my time fixing the interesting parts.

This has been my experience with vibe coding too. On the surface, my coding agents can produce incredible apps very quickly. Once I start actually trying to use them, there are endless paper cuts to fix.

Programming becomes part of using a computer, whether the user calls it programming or not.

This does seem true. Not everyone will become a "programmer" in this sense, but many many more people will, the same way many people use spreadsheets or other similar tools to get their work done.

Traditionally, the software industry has optimized for products that can support large audiences: companies, engineering teams, sales organizations, and lots of customers who, in aggregate, will pay enough to justify building the product. That makes sense when software is expensive to build.

This is a really interesting way of putting it. Finding people to pay for your software is always the challenge.

Finding someone to write and maintain a narrow program used to be the primary bottleneck. Now, the challenge is recognizing when a “throwaway” tool has stopped being throwaway.

This is a great way to frame all of the ad-hoc development happening now. LLMs writing code is cool and fast for sure, but it can be very very annoying when you need the software produced this way to actually work.

Before building your next program, I recommend you ask three questions:

1. Does anyone else depend on it?

2. Can it change or expose important data?

3. Would work stop if it disappeared tomorrow?

If the answer to all three is no, treat it like an experiment, not a product. Build it quickly, skip the formal engineering process, and expect to delete it.

If the answer is yes, add only the structure you really need. Give it an owner, list its connections, limit its credentials, and make failures visible. Then, have a plan for how it gets repaired, replaced, or retired.

The amount of engineering process should follow the consequences. A disposable tool can stay disposable. A tool people depend on needs an owner, tighter access, and a plan for keeping it working.

I really love this framework, I think more people should adopt it. These are very sensible guidelines for vibe coding.

This was a great piece about what’s going on with fly.io. It’s by far my favourite way to deploy my apps these days, and I hope they make it.

I’m going to overshare some more in a second, but I won’t leave you hanging. So: we’ve raised a bunch more money. We’re launching a new iteration of Sprites, and focusing the company on them and the problem they solve. And I’m tagging in Scott Johnston as CEO.

Sounds like a lot of big changes all at once! Sometimes that goes really well for companies, sometimes poorly. It’ll be an interesting year for anyone working at fly either way.

Everybody forgets that before Dan Bricklin invented the spreadsheet, every “Excel document” in the world was a computer program, built by a computer programmer. In just a matter of years, every business professional became a programmer, using the world’s most important programming language, spreadsheet formulas. AI is like that, but bigger. Almost anybody will probably be able to build almost any kind of computer program.

I think this is an interesting way to think about software and what’s happening to the industry. It does seem true on some level. The average professional is very likely going to be able to solve their own problems with vibe coded apps in the near future. But I think “almost anybody” is a stretch. Software people forget how non-technical the average person is. The average normal person has no clue how to use a spreadsheet still today.

More importantly, SBD enables drive forking: you can create a template Sprite, and then efficiently clone millions of times.

This is really cool. This would effectively allow you to checkpoint not just code but an agent's environment already set up along with a particular version of your code.. that could be really powerful.

The other big new thing in Sprites is Connectors. Connectors build on work we did to secure our core platform: they let Sprites make authenticated requests to other systems, without giving agents anything useful to exfiltrate. Connectors have fun security properties, but are also much more pleasant to use than manually managing accounts and API keys.

This is also really cool! The other annoying thing with running agents on VPSs right now is auth.. it’s risky and a huge maintenance burden to have keys fanned out as prolifically as your agents. The desire to have fully functional throwaway environments is just fundamentally at odds with the need to sometimes have secrets on them. Issuing ad hoc secrets per env at agent scale just isn’t feasible. This seems like a potentially great solution.

I could write this post without pissing anybody off, but I don’t know how to do that and still have it be worth reading.

I can appreciate the honesty. And this was a great read.

Five of the most dangerous words in startups are “¿Por qué no los dos?”. We do one thing or the other. We don’t limp in on both.

This is vague about what the future of fly’s now-legacy business looks like, and pretty explicit that they’re all in on sprites. I do think people will still need an easy way to deploy all their little vibe coded apps though. I hope they keep fly up and running too. We’ll see.

I was excited to see that this is the first module in a new Coursera course I'm doing. I've long thought that ethics are missing from software development, and I think it's more important than ever to care about the consequences of what we're doing and building in this age of AI. This course on building agents literally opens with this statement:

This module is for professionals and data scientists aiming to build responsible AI.

I'm really heartened to see that building responsibly is becoming a legitimate concern, at least in some corners of the industry.

By bridging theory and practice, the program empowers you to lead initiatives that prioritize accountability, ensuring your AI systems deliver immense value without compromising integrity or public trust.

I'm looking forward to this.

To understand what a swarm of tens of thousands of automated actions did…

This is a really interesting preview into the scale and type of attacks that are bound to become more common in this age of ai.

Thanks to this approach, we were able to do in hours what would usually take days, and match the adversary's speed.

Useful perspective, if you’re not already using AI to secure production, you’ll have to start. It makes sense that there would be no way for a team of unassisted humans to keep up with the sheer scale of a frontier-model-driven attack.

When we started the log analysis, we first used frontier models behind commercial APIs. This did not work: the analysis requires submitting large volumes of real attack commands, exploit payloads, and C2 artifacts, and these requests were blocked by the providers' safety guardrails, which cannot distinguish an incident responder from an attacker. We ran the forensic analysis instead on GLM 5.2, an open-weight model, on our own infrastructure.

This is the inevitable result of the so called “guardrails” frontier labs have placed on their models. It’s also a bit egregious that they themselves are free to let their most powerful models run in the wild with no such guardrails in place. I don’t think we want to live in a world where the people currently deciding who has access to these tools are the ones who currently do.

This experience points to a gap worth planning for. We do not know which model powered the attacker's agents, whether a jailbroken hosted model or an unrestricted open-weight one; either way, the attacker was bound by no usage policy, while our own forensic work was blocked by the guardrails of the hosted models we first tried. The practical lesson for defenders: have a capable model you can run on your own infrastructure vetted and ready before an incident, both to avoid guardrail lockout and to keep attacker data and credentials from leaving your environment.

This is an extremely important takeaway. If your plan for responding to these incidents is to use a frontier LLM via their commercial API, you are screwed.

I really love seeing more and more serious engineering being put into making LLMs actually work in production. They’re too cool a tool not to use or integrate into consumed software, but nobody actually wants more shitty chat bots. Making them work reliably to actually make software better requires structure and effort, and this is one cool way of thinking about it I hadn’t come across before.

Without additional artifacts beyond what human-driven CD requires, agent-generated code accumulates drift and technical debt faster than teams can detect it.

This is undeniably true at this point and it’s cool to see frameworks and systems emerging for addressing it. This is the first time I’d heard of “agentic CD” and it’s super interesting!

This really hit home for me. Lately I've been feeling very overwhelmed and bored at work, feeling like I'm just drowning in AI slop and cannot possibly keep up. AI-generated PRs are flying through our previously robust process, production problems are way up, most of what I read day to day is not AI-generated, and it's frankly exhausting.

It feels like something has shifted just in the last few months. I'm not sure if it actually has, or if my organization has just taken up AI to a new extent recently, but somehow the day to day enjoyment I used to get out of programming has mostly disappeared. I've been reflecting on why that is and what I might need to change going forward, but I'm not sure what that is yet. For now I enjoy lamenting the old way of doing things with other old fogeys around the internet.

This was a great read, an interesting takeaway is that we should be thinking about interacting with APIs differently when writing "agents" (I like Simon Willison's definition of "agent" as an LLM that runs "tools in a loop to achieve a goal").

Normally a human user of an API knows exactly what they want and makes a specific request for it. LLMs have no idea what they're looking for (they should have some means of validating or benchmarking the responses they get, but that's another too-often-ignored problem for another day), so they need to be able to iterate faster. Instead of sending a single (AI-generated) request, getting some (AI-generated) response, checking it, then repeating, we should be sending multiple requests and evaluating multiple responses in parallel before converging on the "best" answer. This means adding much faster and more robust support for branching queries and rollbacks, since in the world of agents these are extremely common compared to the rare cases they're needed during human interaction.