Jack Rudenko

Gergely Orosz writes that CTOs are leaving their jobs to build again, often with nothing lined up. I did a smaller version of that this year. In his LDX3 keynote he quotes a CTO who has a whole circle of these "CTO dropouts". With these tools, one person can build much more than a year ago, and people want to be close to that. I didn't quit anything. I'm still co-founder of MadAppGang. But I moved from CTO to Chief AI Officer, because the part of the job I wanted most was the building. My title changed. My calendar didn't get the message. There's a second quote in the same write-up that I recognised even more. Dima Zaytsev from Linear says that with AI he did in an hour what others needed a day for. Now everyone runs parallel agents, and he feels he has more work than before AI. That is my week exactly. There's always another agent waiting for an answer from me, usually the one I forgot about. So the tools gave us more building, and also more work around the building. I'm still deciding if that's a fair trade. Peter Mattis from Cockroach Labs gave the advice I'm keeping. Remind yourself why you got into this in the first place. For me it was building things, and right now I build faster than at any point in 22 years. #AI #Leadership #FutureOfWork

For twenty years my answer to "should we rewrite it?" was no. A big part of MadAppGang's work is rescuing codebases other teams left behind. Clients usually ask for a rewrite. The rewrite usually takes much longer than planned, and the old system keeps running next to it the whole time. Now look at what Gergely Orosz collected for his LDX3 keynote. Anthropic moved Bun from Zig to Rust in 11 days, against an estimate of a year and a half. Uber moved 600,000 tests to JUnit 5 in four months. He calls it a golden age of rewrites, and I can't argue with those numbers. So my answer is changing. But speed was only part of why rewrites failed. The bigger part was that nobody could prove the new system did what the old one did. Agents write the new code fast. They don't know what the old code was quietly doing for a customer in 2014. The rewrites in that list worked because they had existing tests and engineers who knew when the result was wrong. Most legacy systems we inherit come with exactly one test suite. It's called production. So my new answer is still short. Write the tests that pin down today's behaviour first, then ask me again. After that, the rewrite itself might really take weeks. From Gergely Orosz's LDX3 keynote write-up in The Pragmatic Engineer. #AI #AIAgents #SoftwareEngineering

The best prompt word I learned this year comes from a book published in 1999. Matt Pocock noticed something on the Pragmatic Engineer podcast. Agents like to build an app layer by layer. First the whole database, then the whole API, then the whole UI. Each layer looks fine alone, and the bugs live where the layers meet. Then he read The Pragmatic Programmer and found the tracer bullet. The idea is simple. You build one thin path through every layer first, end to end, and make it work. Only then do you fill in the rest. He told the agent to use tracer bullets, and the code got better. Two words carried a whole practice, because the model had read the same books we did. I've been explaining this to junior developers for twenty years. It turns out I just needed them to be language models. The same pattern shows up elsewhere in Gergely Orosz's LDX3 write-up. Jarred Sumner from Bun says they still spend about as much time on tests as on code, only now AI writes both. Old habits like unit tests and planning the architecture first help agents even more than they helped us. None of this is new. So I'm going back to my bookshelf with a different question. Which old terms does a model already understand well enough that one word replaces a page of instructions? I'll test a few of them in MadBench on our own code and share which ones actually move results. #AI #SoftwareEngineering #PromptEngineering

There's a story going around that product managers and designers now ship production code with agents. Gergely Orosz went and checked before his LDX3 keynote. He asked AI labs, startups and bigger companies. He did not find a single company where non-engineers ship to production. He found plenty of prototyping instead. PMs and designers also make bugfixes and small features with their agents, sometimes without realising it was a fix. Then that code lands with engineers, who review it and decide if it goes live. This matches what I see with clients. Anyone can type a feature into an agent now, and I think that's great. But someone still owns it in production. Someone has to know why it broke at 3am, roll it back, and explain it to the customer on Monday. A prototype doesn't have a pager. I actually like this split. More people can show what they want instead of describing it in a meeting. Our engineers get a working example in place of a ticket with three screenshots and the word "similar". The responsibility stayed with engineers, and it got heavier, because much more code now arrives from many more people. I don't expect this to change this year. Agents will get better at writing code much faster than companies get comfortable with who answers for it. From Gergely Orosz's LDX3 keynote write-up in The Pragmatic Engineer. #AI #SoftwareEngineering #ProductManagement

We built our own AI coding harness, and these days I delete more from it than I add. In August Gergely Orosz asked if you can be a serious tech company without one. Looking at his list, the big ones have all answered. Stripe has Minions, Uber has Minion, Spotify has Honk, Dropbox has Nova, Amazon has Kiro and Crew. Judging by the names, a good part of the budget went into naming. Ours is called Magus. Building it was the quick part. Every skill and plugin in it started as a workaround for something an older model couldn't do. Then a new model arrives and the workaround stays. It still loads, still costs tokens, and sometimes makes the agent worse. Nothing in the logs tells you that. We found it out with Mnemex, our context layer. It passed every test we ran on it in isolation. Inside the full agent it added irrelevant context and the results dropped. So now every change to Magus goes through MadBench, on our own code and our own historical PRs. In one recent session that process removed nine skills and three plugins. The agent got better with less. I think most harnesses built this year will quietly grow until nobody knows which part still helps. The ones that stay useful will have an eval next to them from day one. If you built a harness this year, when did you last remove something from it? Inspired by Gergely Orosz's LDX3 keynote write-up in The Pragmatic Engineer. #AI #AIAgents #SoftwareEngineering

If your team still approves every agent PR by hand, I'd like to know how many of those diffs anyone actually read. At LDX3 in New York, Gergely Orosz quoted an engineer from a mid-sized startup. He called it the theatre of reviews. So much code arrives that people take the easy path and stamp everything with LGTM. A room of 2,000 engineering leaders reacted loudly, which tells me they recognised their own teams. Linear shared data that shows where this goes. In May, every PR in their sample had at least one human reviewer. By August, almost one in five was reviewed by bots only. I don't think the fix is asking people to read harder. A person can't read ten times more code, and pretending he can is worse than admitting it. Asking another model to review is not enough on its own either. I trust an LLM checking LLM code the way I trust my kids to mark each other's homework. Charity Majors made the point I agree with most. Ops and QA have shipped code they didn't write and don't understand for decades. They did it with checks they trusted. So on our projects the barrier sits outside the model. The agent clicks through every example, takes screenshots and extracts the data model. Then a plain deterministic diff compares the result with a golden reference in CI, with no LLM in the loop. What does your team trust now, when nobody can read it all? Data and quotes from Gergely Orosz's LDX3 keynote write-up in The Pragmatic Engineer. #AI #AIAgents #SoftwareEngineering

Claude Code and Claudish are not only for developers, designers and product managers. This screenshot shows 18 hours of company gap and demand research for sales and marketing, and none of it was code. The setup is simple enough to copy. I give the same brief to four models from four labs: GPT, Kimi, Grok and Gemini. Each one searches using Firecrawl, Exa, Perplexity and Gemini notebooks. Every source gets a trust level before it counts for anything. Then the claims are checked against Google search and Semrush, and the hype is checked against real traffic. Only after that do the models analyse and write. "And is it better than just googling it, Jack?" you'll ask me. It's a great question, and I have no answer. I tried to build an eval for research quality and ended up needing research on how to evaluate research. What I can judge is the report. It's easy to read, claims come with links, and when two sources disagree, it marks the conflict. Most of the value comes from the multi-model part. One model will take a shortcut or invent a number with full confidence, and the other three were trained differently enough to catch it. The next time a sales meeting ends with "just Google it", I'll show them this screen. #ClaudeCode #AI #marketing #multimodel #claudish

Why pick one model when you can use all of them? That question is one of the ideas behind Magus. Claude Code is the most advanced coding agent I use, and Anthropic models are the best all-rounders. But once you get into details, another model often does a specific job better. OpenAI models write noticeably better frontend React code. Gemini 3.1 Pro was the best model we tested for visual understanding, so it could tell when a design was wrong. Probably Gemini 4 Argon is even better, but I have not verified it yet. The others missed obvious things like font sizes and padding, even with the screenshot right in front of them. So Magus mixes models by skill. Each specialist task goes to whichever model is best at it right now, and when a new model wins an area, we swap it in. Picking one model for everything is like hiring one engineer for the frontend, the backend, the design review, and the coffee machine. Somebody will be disappointed, usually about the coffee (I could not miss my coffee jokes). The chart is one example. For SVG generation, this is the top model I bet you’ve never heard of. I’ll keep posting examples of which model wins in which area. #AI #ClaudeCode #LLM #DeveloperProductivity

Running five startups at once used to be a red flag. With agents doing the work, it might be the smarter bet. I got to this idea from my own development work. Right now I run two to five development tasks in parallel, sometimes on different projects. Each one starts with focused time from me, setting up the harness and writing a clear brief. Then the agent works alone for a day or two, and I validate what comes back. Between those long iterations, my attention goes to the next task. I'm not watching any agent type. So why would a company be different? A startup is also a list of tasks that run for days without a decision. Building, the launch page, outreach, support, then building again. If agents take that work, the founder's real job is deciding and validating. And deciding can switch between companies the same way I switch between tasks. The upside is simple math. Five small experiments in a year give you five rounds of customer feedback instead of one. Market fit mostly depends on how many honest answers you get from customers before the money runs out. So far I run this on code. Companies are the next question, and I suspect the harness matters even more there. Is anyone seeing one-person founders run several startups this way? I'd like to compare notes. #Startup #AI

Claude has no feelings. I still think Anthropic is right to ban people who are rude to it. "Why would you care, Jack? It's software." Good question. I care because I've watched what it does to people. A couple of our engineers, some YouTubers, a few people outside the company. The YouTube ones are fun to watch, I admit. The story goes the same way every time. Someone asks the agent for something, it doesn't deliver, and they ask again, louder. Usually the model wasn't the problem. The missing piece was the human part of the work: what to delegate, how to describe it, and how to check the result. Anthropic Academy has a course on exactly this, the 4D framework. It's very useful for drawing a clear line between what you do and what the model does. I know the temptation. Blaming the model is easier than checking my own part. That's where it becomes destructive. When negative feelings drive the process, the prompts get worse and so does the output. The space for reflection disappears, and with it any chance to analyse and improve. Responsibility moves too. What I write and what context I give is the part I can influence. The model itself is the part I can't change. Putting the blame on the AI puts the case in a state where it can't be fixed. Shouting at a model works about as well as shouting at the printer. It keeps printing at exactly the same speed. We already put guardrails on agents. Turns out people need them too. I support this rule. It helps the humans more than anyone. #claude #AI #anthropic

Buying everyone a Claude subscription does not give you an AI engineering team. We tried. You get one engineer flying and a lot of very expensive autocomplete. The gap between your best AI engineer and the rest of the team is the real problem. The top teams are fighting it right now too. AWS, Spotify, Replit, OpenAI, and the Claude Code team are all building their AI engineering teams as we speak, and they struggle like everyone else. We learned a lot from them, and a lot from our own mistakes. I'm putting their lessons next to ours at AI Engineer Sydney. What worked, what failed, and where all of us are still guessing. 7 to 8 December, Hilton Sydney. Code jackaieng26syd gives you $200 off conference and leadership tickets, and $100 off streaming. Send this to whoever signs your AI invoices. #AI #ClaudeCode #AIEngineering #TechTok #Sydney

Every company I know is trying to build a new AI engineering team right now, and all of them are struggling, including mine. Each one has a few AI champions who look superpowered. The rest of the team is where it falls apart. At 10X Labs, we're 50 engineers on Claude Code, and we're somewhere in the middle of that path. Some things worked. More things didn't. Our first plan was to let the champions lead and let everyone build their own setup. A few months later, every laptop had a different agent, and "the frontend skill" meant something different to each engineer. Our AI champions are great. They're also the reason we had 50 different agents. That's one story among many: AWS, Spotify, Replit, LinkedIn, and even the Claude Code team managed by Boris. We've been collecting the rest from our own teams, from partners, and from other companies trying the same thing. At AI Engineer Sydney, I'll share where we are on the path, what we know so far, and what we still don't. I'll also release the tool we built for the config part as open source on stage. 7 to 8 December, Hilton Sydney. If you're the person who has to make AI work for a whole team, I'd love to have you there. Early bird pricing ends on 9 October. Please use my discount code to get $200 off tickets and 100$ off streaming: jackaieng26syd #cludecode #AI #magus

Opus 5.5 is amazing, but what I found is that the smarter the model is, the less likely it is to follow your instructions. That is a scary progression. #opus5.5 #ai #claudecode

Three weeks ago, I wrote that Fable gives us the same diff as Opus and costs about five times more. This week Anthropic made that post wrong, and I'm happy about it. The new Opus and Fable prices landed, so I opened our model catalog to copy them into MadBench. Screenshot attached; the annotations are mine. I expected the usual small change and a slightly bigger invoice. The input and output rows did move a little, which is roughly what I expected. What I didn't expect was the cached read row, which dropped on both models, and on Fable it dropped hard. "Why do you care about the cache row, Jack?", you'll ask me. Because that row is most of what a coding agent costs us. In a chat, you type a question and the model reads it once. An agent in Magus and other agents works differently. On every turn, it sends the whole conversation again, the system prompt, the CLAUDE.md, every file it opened, and every tool result so far. The model reads the same files over and over, and a cached read is the price of each reread. Like a contractor who rereads the whole brief every morning and bills you for the hour. On our invoices at MadAppGang, the cache already saves 20 to 40%, and in a long Magus session most of the tokens are rereads. So the five times in my Fable post came from the old cache price. I don't know the new gap yet. We're running the same tasks through MadBench again this week, and I'll post both invoices. I have no idea how they did it. My read is that a drop like this takes months of inference work, and this release it got the same effort as making the model smarter. That deserves a thank you, so here it is. #AI #opus5.5 #claudecode

This week I couldn't scroll for ten minutes without an AI influencer calling Jev a revolution. I watched the demos. They showed a problem we solved in 2018. Only now it runs slower and costs more. So what is Jev, really? You give it a piece of text and a question with fixed answers, and it picks one. Is this email urgent, yes or no. Which team gets this ticket: billing or technical? It answers in under half a second. The cost is a fraction of a cent. That's faster and cheaper than ChatGPT or Claude. But that comparison hides the real story. Sorting text into buckets is called classification. In 2018 Google released BERT, a model that reads a sentence and decides which bucket it belongs in. A model like that has been hiding spam from your Gmail inbox for years. BERT is a language model. But it isn't a large one. It's small enough to run on a laptop. Once trained on your data, it answers in about a tenth of a second on a normal CPU. No GPU. No cloud. Jev runs only on TypeSafe's servers, behind a waitlist. Its speed is measured against chat models that were never built to sort tickets. Asking Claude to return the word "billing" is like hiring a lawyer to read a room number off a door. Most of the demos showed Jev solving the same problem BERT was built for. Parallel, a company that runs classifiers at scale, tested this last week. Its own trained models beat Jev on two of three tasks, and at a lower cost. Jev playing Pong at 227 milliseconds per move looks impressive next to Claude Haiku at 2.5 seconds. Then you watch the video below. That’s a small model, not a language model, playing Pac-Man on my slow laptop with no cloud involved. The project I created a couple of years ago. It still has real uses. I described it in the article. linkedin.com/feed/update/urn… #AI #Jev

I’ve got the Threads notification bell turned on for exactly one person, and it is not a client or a boss. It is Boris Cherny. I read everything he posts about Claude Code the way other people follow football. Half of it is jealousy. The man has unlimited tokens. I have a billing alert. Fine, the stalking part is a joke. The next part is not. He wrote that he keeps effort at xhigh for most work, and max for the hard tasks. It is a simple sentence, but it changed how I set up my agents. For a year, I kept picking models. Sonnet here, Opus there, and when the answer was bad, I would just go one model up and pay more. Effort gives you a second question to ask. If the agent had everything it needed and still got the logic wrong, that is the model. If it skipped a file, never ran the tests, or stopped halfway through a refactor, that is effort. Same bad result, different reason. I had been paying for intelligence when what I needed was patience. So now I set two things instead of one: which model, and how hard it works. Then there are subagents. My session runs high, so the small agent that greps a repo and reports back runs high too. It does not get smarter from that. It just costs more to read filenames. We fixed Claude Code by adding this in Claudish, where every agent carries its own effort level. I hope Claude Code does the same, and I do not think anyone will argue with that. Boris, if you are reading this, I am not following you. I am benchmarking. #AI #ClaudeCode #Fable

Writing code was never the job. The fun was, and by that standard, vibe coding is legitimate software development. So I made mine more fun and put Doom inside Claude Code (claudoom; Doom is a trademark). It took two builds to get there. The Claude Code source leaked in March. I found the part that draws the screen, and Doom was running by Sunday. Then I deleted it. My build sat inside a modified copy of Anthropic's source, so handing it to anyone meant handing over their code with my diff on top. It felt like being a kid with a drawing you're proud of and nobody you're allowed to show it to. Then Claude Code shipped custom widgets for plugins. I rewrote the whole thing using the public extension points, so it’s now fully legal and installs with a single command. So what are you supposed to do while AI does your job in front of you? Be sad, be angry, be scared about the next ten years. I went with Doom. Vibe coding, vibe dooming. The next step is letting Claude play Doom instead of me, because I'm lazy and I love doing useless things nobody needs. And I like the idea more than I like aiming. Although if Claude writes the code and plays Doom, I'm just a man watching two windows. It already wrote most of this port, and I don't miss that part at all. Wanting to build something stupid on a Saturday is the piece it has never shown any sign of, and that piece was always the job. I hope that stays broken. #claudcode #doom #AI