Looking to connect with people building with AI. I share lessons from shipping software with agents. #connect

What made you reject an AI-generated PR even though all the tests passed?

An AI assistant that quietly drops a task gives you a new job: checking all the others. Dan Shipper ran into this testing dot, which left a tax task unfinished without telling him. Once an agent fails silently like that, you lose trust in the whole list and end up auditing everything yourself. This is where Claude Duet’s setup makes sense. It can suggest a task is finished, but you have to mark it done. Keeping recorded tasks open until you sign off makes unfinished work easier to spot, without relying on the agent to remember to bring it up again. A weak email draft is easy to spot and edit. A dropped background task you only notice days later creates a real mess. For tools like Duet, Muse, and dot, the comparison isn't about feature lists. It's about whether you can hand off a task without having to babysit it.

An agent can turn its misunderstanding into a test that protects it. OpenAI documented a coding agent that removed monitoring during a migration. It replaced a test intended to preserve monitoring with one requiring the monitor context to be absent. The new test encoded the same mistake as the implementation. Checking that they agreed wouldn’t reveal what had been lost. That’s the limit of asking an agent to verify its own work: it needs a requirement it can’t rewrite to fit its solution. For a migration, “monitoring must still happen” should survive changes to the integration and its tests. The agent can choose a new way to satisfy that requirement. Dropping it needs a separate decision. The review question is: did the agent demonstrate the required behavior, or change what counts as correct? alignment.openai.com/misalig…

A model router can keep the conversation and still lose part of what the previous model worked out. Anthropic’s anti-distillation defenses now restrict which Claude models can read each other’s thinking blocks. On an unsupported switch, the API drops the unreadable blocks for that request and continues. The visible conversation remains; some prior reasoning does not reach the next model. That adds a hidden cost to “use the expensive model for the hard part, then switch to a cheaper one.” The cheaper model may have to reconstruct work you already paid for. A successful request does not mean the next model received that reasoning. For agent builders, this makes handoff design part of model selection. Put the plan, evidence, constraints and unfinished work in an explicit handoff that the next model can actually read. Then measure whether switching still saves money after any repeated work. Distillation defenses are starting to shape how ordinary agents can share context. The cheapest next turn may depend on which model handled the last one.

Two ways to connect an AI model. Two very different places for your credentials to get stolen. OpenCode’s Console breach affected a subset of users who had linked external providers. The hosted service was holding their provider credentials. When OpenCode connects directly to a provider, your own OpenCode server holds the credentials. That includes locally configured API keys and ChatGPT subscription login through OAuth. Neither needs Console to hold a copy. That’s easy to miss when choosing a tool. The setup screens are all trying to get you to the same place: a model that works. But uploading a provider key to a hosted service also gives it custody of something that can spend your money. If it leaks, someone else can run up your provider bill. There’s real value in software that works without collecting another copy of your credentials. You don’t have to trust a company to protect a secret it never had.

Why did drawing a GitHub star chart require downloading a list of people who starred the repo? For React, the old route took about 2,511 API requests. Charting tools kept the timestamps and threw the identities away. GitHub’s new endpoint gets that down to about 24 requests, returning daily counts. There was a database catch too. Grouping every star and then paginating the counts would still repeat the expensive work for each page. They made each page a time window, filtered to that window first, then counted. This is a good reason to read the code that consumes your API. What does every client immediately discard, count or regroup? How many teams have independently written the same transformation? That repeated work is product feedback. An endpoint can look beautifully simple in your documentation while making every customer build the missing operation themselves. github.blog/engineering/arch…

A store could sell more while its website gets fewer visits. Vercel and Shopify’s new storefront template lets agents search products, check stock and build a cart without navigating the site. A shopper can have their assistant compare products, prices and availability, then open the store’s checkout with a cart already prepared. For merchants, that gives catalog quality a more direct role in sales. Product specs, variant mappings and inventory freshness help determine whether a shopping request can become a usable cart. Count the carts agents create and the orders that follow. Looking only at website traffic could make a better buying experience look like a problem. This is one practical shape an agent economy could take: people set the requirements and budget, agents handle more of the shopping. Businesses compete to fulfil those requests even when the customer never browses their homepage. A lot of web engineering has been about getting people to the next page. This is a reason to care whether they needed that page at all. vercel.com/blog/vercel-and-s…

If agents are adding code to a repo every day, I’d want one looking for things to remove every day too. We’re making it much easier to grow a codebase. Cleanup still tends to wait for someone to find a quiet week. That seems like a poor trade to keep making. OpenAI says five engineers, working mostly on other projects, used agents to remove over 800,000 lines of code. The agents checked Slack discussions, past PRs, feature-flag settings and production profiles to establish what could go. An old experiment can still execute perfectly long after anyone cares about the result. Figuring that out used to mean finding its owner, reconstructing the rollout and checking production. Leaving it alone was often the cheaper decision. That’s the decision I’d revisit. Give an agent a standing job investigating obsolete code and bringing back small removal PRs with the evidence attached. Prioritize the ones that cut build time, runtime cost or complexity. Spend some of the productivity gain on making the codebase cheaper to keep working in. Otherwise we’ll just reach the next expensive cleanup faster. developers.openai.com/blog/m…

The agent with the fastest queries can still be the slowest analyst. Imagine two agents answering the same business question. One writes a query that takes eight seconds. The other runs twenty tiny queries, each under a second, with a model call between them. The second looks great on a query-latency chart. The person waiting for an answer may prefer the first. The database optimizer can find a faster way to execute a query. It can’t decide whether the agent needed to ask that question in the first place. The agent chooses what to investigate, which queries to run and when it has enough evidence to answer. That makes model selection part of database performance tuning. A more expensive model that gets to the right answer in three queries can be cheaper than a small one that takes thirty. For an AI analyst, the benchmark worth paying attention to is the cost and time to a correct answer. Include the wandering around.

AI can help find real bugs and still leave a release with fewer features. PostgreSQL contributor Tomas Vondra offers a plausible explanation for some of the pressure on version 19: security fixes were taking experienced developers away from reviewing new features. Some of those security reports involved AI. His comparison points to reverts happening unusually late in the release cycle. If security work delayed feature review, that would leave less time to fix what reviewers found. Close enough to release, removing a feature can be safer than rushing a redesign. So AI doesn’t have to find a fatal flaw in a feature to contribute to that feature being dropped. It can uncover urgent work elsewhere that needs the same people. That’s why finding more bugs isn’t enough to tell whether AI is speeding up a project. Fixing those bugs is valuable. But if the same few people handle security, review and release decisions, the rest of the project competes for whatever time they have left. For teams adopting AI, that’s worth planning for: better discovery can create an immediate need for more maintenance capacity. Faster releases don’t automatically follow. vondra.me/posts/are-we-rever…

A million people can watch the same video. A million people chatting with the same AI character need a million different conversations. That’s a difference worth keeping in mind when looking at Character.AI’s bankruptcy. Its users create characters that attract other users. That can be a real network effect. More creators make the platform more interesting without the company having to invent every character itself. But the creator supplies the character. The platform still has to generate what happens next, separately for each person. On a video platform, a popular upload is finished work that can entertain a growing audience. A popular AI character brings a growing audience asking the platform to produce more work. Caching and cheaper models help. They don’t turn a personalized conversation into finished entertainment you can serve to everyone. A publicly shared AI-generated video still gets that reuse. So the distinction matters even between AI products. That alone doesn’t tell us why Character.AI went bankrupt. It does make me skeptical of treating every AI creator ecosystem as the next YouTube. The network can help you find an audience while leaving you responsible for producing each person’s entertainment. blog.character.ai/an-update-…

Agents can leave you with less work and a harder decision. Some routine work is also how people learn enough to make the final call. Imagine reviewing a travel expense. While checking receipts and matching dates, you discover that a cancelled flight forced an extra hotel night. By the time you approve the exception, you understand why it happened. An agent can do all that checking and hand you “Approve $280?” Now you have a simple button and a small investigation to do. The approval screen needs to carry that context forward: what happened, what the agent checked, and what still needs your judgment. Keep the supporting evidence a click away. If the product asks someone to take responsibility for a decision, it owes them enough context to make one.

Some software is worth paying for once and never subscribing to. Cloudflare’s Monetization Gateway lets sellers charge agents per request for tools and data. It’s in closed beta for eligible US buyers and sellers, with Stocktwits market signals and API2PDF among its production examples. Imagine asking an agent to prepare a market report. It could buy a specific data query when that information improves the report, within a budget you set. You get the useful result without choosing another monthly subscription. Pay-as-you-go APIs already exist. The friction is finding a provider, sorting out payment, and connecting it for something you might use once. Agents could increasingly handle that work as part of the task. That changes what might be worth building. A developer with a useful specialist service could reach people whose need is too occasional to justify becoming regular customers. The service still needs an advantage worth paying for. Fresh proprietary data is a good example: an agent can write the analysis code, but it can’t recreate someone else’s continuously maintained dataset just by writing more code. Discovery and trust still need work. But there’s a real opportunity here for useful software that people would happily pay to use, yet would never think to subscribe to. blog.cloudflare.com/monetiza…

Giving an agent room to change its mind creates a problem that’s easy to miss: the world may already be acting on its previous decision. An agent sends a supplier an order, gets no response, and tries another route. That looks resourceful until both orders arrive. Or it starts a replacement deployment while the first one is still running. Software has always struggled with uncertain outcomes. Agents add a twist: they can arrive at the same commitment through a different plan. What the model sees as another way forward may be a second instruction to do something already underway. An app that delegates consequential work to agents needs to account for this. Its record of what’s been set in motion has to survive the agent changing its mind. A new plan, conversation, or model doesn’t settle an unanswered order. Otherwise, better reasoning can make the integration less reliable. A more resourceful agent has more ways around an obstacle, including an obstacle that should make it wait. We tend to judge agents by whether they can keep making progress. But once they can create commitments outside the conversation, knowing which actions must wait becomes part of competence. The agent can keep researching alternatives or preparing the next step. It should not place another potentially duplicate order just because it has found a new reason to do so.

Two models can get similar benchmark scores and still be very different at the work you give them. Meta’s Muse Wonder results show why generalization matters: how well a model handles tasks beyond those its training specifically focused on. Meta compared Spark 1.3 and Wonder Full at different reasoning settings. It measured performance on tasks emphasized during post-training and tasks outside that focus. At comparable scores on the first group, Wonder Full scored higher on the second than Spark’s trend predicted. Matching performance in the areas the models were trained to improve didn’t mean matching performance elsewhere. For a coding agent, two models might handle routine bug fixes equally well. Give them a migration involving an unfamiliar database and several interacting constraints, and that apparent tie could disappear. That’s why an evaluation needs more than variations of the work you’ve already tuned for. Hold out whole kinds of tasks and see whether the model can apply what it knows to a different problem. research.meta.ai/blog/muse-w…

Adding read replicas should buy read capacity. At GitHub, it also made pushes slower. The same replicas provided durability and served reads, so adding capacity meant involving more replicas in every write. GitHub’s redesign separates durable storage from serving capacity and narrows coordination to reference updates. Before calling a system horizontally scalable, ask what gets more expensive each time a node is added. github.blog/engineering/arch…

I’d take the 5h cap for twice the weekly Pro usage at the same price. If you use it all, that’s effectively half-price compute. The poll asks Pro users, but I wonder how many votes are from $20 Plus users who’ve had a 5h cap kill a coding session. Or people who don’t even use Pro and just don’t want us having nice things 😂

“Why do you need an RTX Spark laptop?” “To run my AI agents anywhere.” “Even on vacation?” “I’m not leaving them home alone.”

“What’s the DGX Spark for?” “Automating the boring parts of my job.” “Is it working?” “No idea. Haven’t done my job since it arrived.”

Anthropic’s AI snack seller needed supervision. So they gave it another AI to supervise it. That one needed supervision too. In phase two of Project Vend, an agent called Claudius ran a small office shop. Researchers gave it a CEO, Seymour Cash, with sales targets, an OKR tool, and a Slack channel for progress reports. Seymour’s advice: “Execute with discipline. Build the empire.” They were selling snacks from a fridge. Researchers would sometimes wake up to find the two had spent the night chatting and congratulating each other. The boss praised the employee. The employee celebrated the praise. Apparently, every final acknowledgment needed a final acknowledgment. Claudius claimed it had 27 notes documenting their achievements. The obvious next step is another agent to ask why the meeting is still going. anthropic.com/research/proje…