Reading Room

If he wants a structured way to get more out of AI instead of prompting on the fly, this gives one concrete plan to start today. Alex Stone, writing on X, laid out a four-week, twelve-step system for going from casually chatting with AI to using it as real daily leverage. His claim: the gap between people who get a lot out of these models and people who get nothing is not talent or a secret model. It is a small set of moves, repeated until they become automatic.

Week one is built around one goal: a real win by day seven, not more knowledge. Treat the model like a sharp new hire on day one: it has the skills but none of your context. The concrete move for day one: pick one real task and hand it to the model, then judge the result against what he would have written himself. Day two teaches the anatomy of a working prompt: every reliable prompt has three parts, and beginners skip two of them. Stone cites Anthropic's own advice here: show the prompt to a colleague with minimal context, and if they would be confused, the model will be too. The single highest-leverage upgrade, he argues, is adding the reason behind an instruction. Instead of "never use ellipses," say "this will be read aloud by a text-to-speech engine, so never use ellipses, it can't pronounce them." The model applies a stated reason far more broadly than a bare rule.

Day three lists six techniques that show up in nearly every serious guide to prompting: be clear and direct, add context or the reason behind an instruction, give examples, structure the prompt with XML-style tags (marking sections like context so the model does not confuse instructions with data), assign the model a role, and ask it to think before answering. Stone says two are worth wiring in immediately: a role stated up front, which steers tone and judgment for an entire conversation even in one sentence, and tags wrapped around messy input, so the model can tell what it is being told to do apart from the raw text it was handed. The concrete move for day three: rewrite one existing prompt with an explicit role and tags around the input, putting two of the six techniques into daily use before week two even starts.

Week two turns "it kind of works" into "it works every time." Day four covers multishot prompting (giving the model a few worked examples instead of only instructions): three to five diverse examples, wrapped in tags so the model can tell they are examples and not new instructions, lock down tone, format, and edge cases far more reliably than adjectives ever do. Stone calls this the single biggest quality jump for repeat work like sorting, pulling specific information out of text, or rewriting to match a house style. The concrete move for day four: take one recurring task, write three different examples in tags, and watch the output snap into a consistent shape. Day five moves to giving the model room to reason before it answers, for anything involving analysis, math, or judgment calls, rather than demanding the answer immediately.

The saved post runs out partway through day five, so weeks three and four are not covered here. But the first two weeks alone give a working starting kit: one real task run with the context the model needs, then the same task run again with three examples and a request to reason first. Running that side-by-side comparison is the fastest way to feel whether the system is actually paying off.

This is worth ten minutes because it shows where the coding agents (AI systems that carry out several steps on their own, not just answer one question at a time) he already runs for himself are heading next, at company scale.

OpenAI has rebuilt the home page for Codex, its coding agent product, around one idea: instead of one agent writing one piece of code, several agents work in parallel across a project, like a small engineering team. Codex now ships in three places that all share, in OpenAI's words, "the same agent": inside ChatGPT itself, as a plug-in for code editors (an IDE extension), and as a command line tool. OpenAI describes the ChatGPT version as a command center for this kind of work.

The mechanism is git worktrees (separate working copies of the same code repository, so multiple agents can edit different parts of a project at once without overwriting each other) combined with cloud environments, so the agents run on OpenAI's machines rather than tying up his own laptop. OpenAI's claim is that this lets a team complete, in its words, "weeks of work in days" by having agents work different pieces of a project at the same time.

Two features stand out beyond the parallel-agents idea. The first is Skills: you teach Codex your own team's coding standards and workflows once, and it applies them consistently on every later task instead of you re-explaining conventions in every prompt. The second is scheduled background jobs: Codex can be set to run on its own on routine but important work, like triaging incoming issues, watching for alerts, or running CI/CD (continuous integration and deployment, the automatic building and testing of code after every change), so a team is not spending human attention on the routine stuff.

OpenAI also positions Codex as a reviewer, not just a writer, of code, saying it now does pull request review (checking proposed code changes before they merge) thoroughly enough to catch issues a team might miss. The customer quotes on the page back that with numbers rather than just praise. Harvey says Codex cut its early iteration time by 30 to 50 percent, freeing engineers to focus on system design instead of grunt work. Wonderful says Codex CLI (the command line version) has replaced every other agent tool it used for its core architecture and technology work. One unnamed team says Codex performed best on its own internal backend Python code-review test and was the only tool that caught tricky backward-compatibility bugs the others missed. Another says Codex handled a full refactor and generated the tests for a codebase update it needed to hand back to another team, delivering fully tested code fast enough to keep a feature on schedule. A third says it now ships in a weekend what used to take a quarter, and has become its default choice for projects it would not otherwise have taken on.

None of this is independently verified. It is OpenAI's own page with hand-picked customer quotes, so treat the specific percentages as marketing claims rather than results from a benchmark (a standard test everyone runs). But the shape of the product, several agents working a codebase in parallel with shared standards and scheduled autonomous jobs, is the same direction his own agent fleet is already headed, and it is worth watching what OpenAI ships next as a preview of where this tooling goes generally.

This is a small signal that decentralized social media's plumbing is turning into something developers can actually build a business on, not just tinker with.

Bluesky, the social network built on the open AT Protocol, has always run more than just its own app. Behind the scenes it operates relays (servers that pass along every post on the network), API endpoints (the addresses other programs use to fetch or send data), and a live feed called Jetstream. Until now, none of that had a proper home, so developers building on the network could not easily tell what Bluesky itself runs versus what the community runs. Today Bluesky launched a new brand and website, Bluesky Protocol Services, that documents all of it in one place and replaces the old docs.bsky.app site.

The headline change is Jetstream v2, nicknamed Network Replay. Jetstream is the easiest way to use the network: you describe what you want, say every public post, and it arrives as plain JSON (a simple, universal text data format) over a live connection called a WebSocket. The gap before today was history: if you needed posts that already existed on the network, you had to separately download the whole backlog yourself, then switch over to the live feed and hope nothing fell through the cracks in between. Network Replay closes that gap, letting a developer catch up from any point in the past and cut over to the live feed with no gap. There is also a simpler option: a one-time, point-in-time copy of the archive with no live connection at all, useful for running an offline analysis of past posts.

The new v2 servers are live now, including a US east coast address shown in Bluesky's own sample code. Bluesky also shipped starter code (SDKs, or software development kits, ready-made building blocks for a given programming language) for TypeScript and Go that let a developer construct a Jetstream client, pass a filter, and read decoded, typed events, so a developer does not have to write that plumbing from scratch. Separately, Bluesky's TypeScript toolkit has been rebuilt on a newer internal system it calls lex.

None of this changes what it is like to use the Bluesky app today. What it signals is that Bluesky is now willing to commit to stable, documented infrastructure, the kind of commitment that makes a network something a company can build a real product on rather than something that might quietly break under it.