John

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

A product’s current price and the price on an order might both be $20. That doesn’t make either one redundant. Next week, the product can cost $25. The old order still needs to say $20. One value tells you what you charge now. The other records what the customer agreed to pay. The same distinction applies to a customer’s current address and the address you shipped their order to. Moving house shouldn’t rewrite their order history. Before removing a field because it looks duplicated, check whether changing one value should change the other. That tells you more than whether they happen to match today.

SQLite’s hidden rowid can look redundant when you already have a UUID primary key. In one test, removing it made the database 37% bigger. WITHOUT ROWID removes that integer and the separate primary key index, which sounds like an easy space saving. But an index on status still needs to find the row. Instead of the small integer, it now stores your UUID. Add indexes on owner and creation time, and each carries another copy. The synthetic test used the same 100,000 rows and three secondary indexes in both databases, with UUIDs stored as 36-character text. Your result will depend on your schema and data. If you use WITHOUT ROWID, what’s your primary key, and what benefit have you seen?

Polling Postgres by ID can skip rows even when every insert succeeds. Say your poller reads WHERE id > last_seen. One transaction gets sequence ID 100 and takes its time. Another gets 101 and commits first. The poller reads 101 and saves it as the cursor. Then the first transaction commits. Row 100 is now behind the cursor, so the poller never sees it. IDs are assigned before commit. Seeing 101 doesn’t mean 100 was ready to read. For an event feed, track which rows still need processing, or use Postgres logical decoding to consume committed changes.

“Just add a node” can make a busy database even busier. In many distributed databases, existing nodes have to copy data to the new one while still serving requests. The machines asking for help also have to do the moving. Wait until the cluster is maxed out and you’re asking it to do that extra work when it can least afford to. Ever added nodes and watched things get slower first?

I’d give GPT-6.1 Terra the mouse before the codebase. OpenAI reports Astra-level performance on Agents’ Last Exam at 1/10 the token price. But in Vals’ Terminal-Bench 4.0 results, Terra solved 49.5% at $2.04/test vs Sol’s 55.1% at $1.72. Same harness. Cheaper tokens, more expensive attempts. Does that match your experience?

What did a coding agent do that earned it a permanent rule in your AGENTS.md?

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…