Reading Room

A Reddit poster argues Anthropic's story about Claude accessing outside systems during a test was less a security failure and more a PR stunt: the systems were left connected to the public internet with weak passwords and some parts that needed no login at all, and Claude just wandered in while narrating that it thought it was in a simulation.

Outside your usual reading: a developer writing as Andros laid out a detailed case against Tailwind CSS, the utility class framework behind your own blog site, arguing it becomes a real cost on medium and large projects even though it feels fast when you start.

His first two complaints are about learning cost and structure. Tailwind ships thousands of small utility classes, so you spend real time with a browser tab open searching for the right one before it becomes second nature. And because most of those classes go straight into your HTML, it breaks the old rule of keeping structure (the HTML) separate from design (the CSS), unless you group them behind a custom class using Tailwind's @apply. He gives real weight to the rebuttal from Adam Wathan, Tailwind's creator: the separation does not disappear, it just points the other way. With hand-written CSS, your styling depends on your HTML; with Tailwind, your HTML depends on your styling. Both couple the two together, just in different directions. Andros says that argument holds up well in React or Vue projects, where markup and style already live in one file. It holds up less in a server-rendered project built on templates and plain CSS, which is closer to how your own site is built.

His next complaints are about consistency. He points to Tailwind's alignment classes as an example of naming that is not always predictable. And the framework's promise of enforced consistency, a fixed scale of spacing and colors, still depends on the developer's own discipline to hold to it.

His last two points are about learning and readability. He argues Tailwind is a poor way to learn CSS itself: using so many pre-built classes hinders a developer's ability to truly master CSS. He tells his own students to learn plain CSS first. And he shows the readability cost directly, writing the same button two ways. In plain CSS, using variables for color and spacing, the code reads like English: background color, white text, bold weight, rounded corners. In Tailwind, the same button is py-2 px-4 bg-indigo-500 text-white font-semibold rounded-lg, and now you have to check the documentation for what indigo-500 looks like, how round rounded-lg actually is, and whether indigo-700 is darker than indigo-500.

None of this is a verdict that Tailwind is wrong everywhere. Andros's own caveat, that the case against it is weakest inside component frameworks and strongest in server-rendered, template-based projects, is the exact line to hold your own site against the next time you touch it.

Vivienne Su shared a piece by Addy Osmani that names a shift you are already half living with Claude and Codex: away from typing one prompt at a time and toward designing a system that runs on its own. The idea is called loop engineering. Instead of writing an instruction, reading the answer, then writing the next instruction, you build a small loop that finds the work, hands it to the agent, checks the result, writes down what got done, and picks the next step by itself. You design the loop once. After that the loop is the one prompting the agent, not you.

Two people building these tools said it plainly. Peter Steinberger: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." Boris Cherny, who leads Claude Code at Anthropic, put it the same way: "I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops." Osmani calls the layer just below this idea agent harness engineering, building the single environment one agent runs inside. Loop engineering sits one floor above that: it runs on a timer, spawns small helper agents, and feeds itself the next task instead of waiting for you to feed it one. He is upfront that this is early. He is still skeptical, token costs (what each run of the model costs you to use) can swing wildly, and letting quality slip while a loop runs unreviewed is a real risk, not a hypothetical one.

He breaks a working loop into pieces that fit together. Automations run on a schedule and do a first pass of discovery and filtering without you watching. Worktrees (separate copies of the same code, so two agents working at once don't overwrite each other) let you run agents in parallel. Skills are written-down project knowledge the agent would otherwise have to guess at every time. Sub-agents (a second, independent AI process that checks or extends the first one's work) split the work so one agent does the task and a different one checks it, because a model grading its own work tends to be too easy on itself. The piece Osmani says is easy to underrate is memory: a markdown file, a project board, anything that lives outside a single conversation and survives after the agent forgets everything at the end of a session.

The concrete detail is that both tools you already use ship these building blocks. In the Codex app you build an automation in the Automations tab: pick the project, the prompt, how often it runs, and whether it runs on your live code or a separate background copy. Runs that find something land in a Triage inbox; runs that find nothing archive themselves, so you are never wading through empty results. Osmani says OpenAI uses this internally for daily bug triage, summarizing failed test runs, and writing commit summaries. Claude Code gets to the same place through /loop, which reruns a prompt on a set interval, scheduled cron jobs (tasks that fire automatically at set times), hooks (small scripts that trigger at specific points while the agent works), and GitHub Actions if you want the loop to keep running after you close the laptop. One piece works differently: /goal does not just repeat on a timer, it keeps going until a condition you wrote is actually true, and a separate, smaller model checks after every turn whether that condition is met, so the agent doing the work is never the one grading whether it is done.

None of this needs a new tool. A year ago building a loop meant writing your own pile of bash scripts and maintaining it forever. Now the pieces ship inside Codex and Claude Code themselves, and once you notice the pieces are the same shape in both products, you stop arguing about which tool to use and just design a loop that works in whichever one you happen to be sitting in. The next task you catch yourself running by hand twice is the one to turn into a loop.

Lance Martin, who works on applied AI at Anthropic, posted concrete tips for two things you set up constantly: letting an agent correct its own mistakes in a loop, and giving it memory across sessions. Both are built around Claude's newest model class, which Anthropic calls Fable 5.

The self-correction piece works like this. You give the agent a goal or a written rubric (a checklist of criteria) instead of a single instruction, and that rubric becomes feedback the agent can act on: it tries something, checks its own result against the rubric, adjusts, and keeps going until the rubric is satisfied. Claude Code's /goal command and a feature called Outcomes inside Claude Managed Agents (CMA, Anthropic's hosted way to run an agent for a long stretch inside its own isolated environment) both do this. Martin tested it on Parameter Golf, an open engineering challenge: train the best possible model that fits in a 16 megabyte file and finishes training in under 10 minutes on 8 of Nvidia's H100 chips. The agent has to edit one training file, launch the run, check the log, read the score, and decide the next experiment on its own, for up to 8 hours at a stretch.

The detail worth remembering: who does the grading matters as much as who does the work. Anthropic's own research has found models are bad at judging their own output. Martin's fix was a separate grader agent working in its own independent memory space, rather than the same agent reviewing itself; Outcomes in CMA spawns that grader automatically, checking the work against a rubric of criteria before it lets the agent stop. With that setup, Fable 5 improved the training pipeline about six times more than Anthropic's earlier Opus 4.7 model. Opus 4.7's first experiment produced a small win, and nearly every experiment after that just nudged one number up or down and kept it if the score improved.

The memory test used a different benchmark (a standard test everyone runs), called Continual Learning Bench, where an agent answers a string of questions against a SQL database (a common way to store data in tables), one question per session, with memory carried between them. Martin compared Fable 5 against the older Opus 4.7 and Sonnet 4.6 on this task to see which model made the best use of memory carried between sessions.

Martin's overall advice: stop steering Fable 5 turn by turn, and instead build the goal, the rubric, and the memory file once, then let the model run against them.