Ai

Uncle Bob — author of Clean Code, author of Clean Architecture, the man behind the SOLID principles — doesn’t read the code his agents write. Bob writes: “I’m considerably older than you. I started programming in the late ’60s. My current strategy is to not read the code written by my agents. It’s the only way to actually benefit from their throughput. Instead, I surround the agents with extreme constraints: unit tests, Gherkin tests, QA procedures, quality metrics, mutation testing, test coverage, and a bunch of others. In the end, I’m very confident in the code they produce, because it had to pass through all of my constraints and tests.” https://x.com/unclebobmartin/status/2080257779395154409 ...

Mitchell tweeted something simple: “I READ CODE…” And that was it. The internet, Twitter especially, was not ready for such a radical statement. Every time I hear something like “Claude wrote all of this, I don’t understand how it works,” I draw one conclusion: this person is incapable of debugging, full stop. If you can’t debug code, you don’t really own it. And if you don’t own it, nobody who cares about reliability or stability can trust you as a vendor. ...

Jarred Sumner, creator of Bun — the JavaScript runtime that Anthropic bought, that just got rewritten from Zig to Rust, and that Claude Code happens to run on, so it’s a safe bet you already have it on your machine — wrote a post about why they moved to Rust. https://bun.com/blog/bun-in-rust Short version: the runtime got 10% smaller, starts 10% faster, and “seems” to have no memory leaks, even though the codebase now has 13,000 unsafe calls in it. Jarred is happy regardless, and says he rewrote the whole thing in 11 days with early access to the Fable model — that is, with a pile of free tokens. Tokenmaxxing, senior-engineer style. He points out the original runtime took a year to write, barely leaving the house, so delegating a rewrite like this to AI is a genuine win. Great post. Everyone should write one of these after a big migration. But then — ...

Recently I pushed code to production without reading it. Looked at the title. Looked at the description. Asked an AI agent to review it. The agent wrote something or other. Out of the corner of my eye I caught a green emoji — click, click — and the request flew off to prod. It was a planned trick, to be fair. I know the codebase by heart, there are plenty of tests. A kind of Russian roulette: where you used to switch off a data center and watch what fell over, now you commit with your eyes closed. And if it falls over, you say it was a planned stress test of the AI pipeline. ...

Who even counts tokens? Who counts the number of servers? Who counts the seconds per request? Who counts anything anymore? If it doesn’t matter how much you pay Anthropic or OpenAI for tokens, if it doesn’t matter how many instances are running on Amazon, if it doesn’t matter that an Azure function cold-starts for 10 seconds every single time — then the programmer probably doesn’t particularly matter either. Replaced one with another. The other with a third. Fired the third. Hired a freelancer with a Max subscription to Claude Code. It doesn’t matter whether the freelancer holds one job or ten. Doesn’t matter if they’re frontend or backend. Doesn’t matter the language, the framework. Only the subscription matters. ...

If developers already have their silver bullet — TypeScript — then managers have just found a new favorite: the AI-Native Team. It’s this idea that a small team can be as productive as a big team. Sounds like something you’ve heard before? Well, here’s the important addendum: as productive as a team of 50 people. So not even a team anymore — a whole organization. A department. The Builders The AI-Native Team doesn’t write code itself. It manages agents. It sets up agent factories for developing and delivering code. ...

I have a colleague who seems to have lost his mind on the AI wave. Before this he was an average engineer. He built good tools. Sometimes cool engineering decisions, sometimes not so much. All as usual. An engineer like any other. He played politics very well. Got promoted to Staff. Sat in meetings, aligned, synced, did his soft-skill things. All good. Then AI coding arrived And he probably decided: here’s my chance to level up the hardcore skills. Now I don’t need to negotiate. I don’t need to sit in meetings, or write design docs. I don’t need other people at all anymore. I can do everything myself. ...

The morning starts with going through the logs — the errors that piled up overnight. Nothing complicated. You read the errors, you go into the code, you see why a wrong parameter came in here, and over there why a parameter is missing instead. You commit. Note to self: check again in a couple of hours. At the meeting you describe what you spent your time on — and the response is an idea. Maybe you need a skill? Look: Claude Code will do all of this for you, and you just review the merge requests. We schedule the skill with cron and that’s it. ...

A bug comes in from users. Your program crashes with an error at some indeterminate moment, for unclear reasons. (Are there ever any other kind?) It’s serious. Lots of users complaining. It’s urgent — every engineer drops what they’re doing and piles onto the task. What’s the CPU doing? Which processes are running? Are there logs? Are there repro steps? What about the dump? Etc. The war room Only they’re not exchanging files anymore. They’re exchanging prompts. ...

A task’s status updates itself, automatically, from the pull request. Sprints have been replaced by an optional weekly call. There’s no sprint planning either — you have an LLM generate a one-page design doc for the feature, and that’s the whole ceremony. Agents work the codebase autonomously. They write the tests. They review the code. They open small pull requests and merge them. Programmers are involved only in the big architectural decisions, the designs, and in giving feedback to the agents. ...