What is capability gaslighting? From Maggie Appleton @Mappletons, Design Engineer at GitHub Next: "Models convince you they're so capable because they'll really impress you on one task and then you try them on something else and they fail. You feel like: ‘you kind of gaslit me, imagining that you're this extremely intelligent agent or model and then you fall on your face'. Sometimes they fail, but I haven't totally noticed how badly they've failed because I still have this belief that like, 'oh, but you are a frontier model'. It's such an inconsistent experience and it's so different to working with a human. If you find a human who is really an expert in a topic and you work with them, it's very unusual for them to be inconsistent in their performance. It's very rare for them to suddenly forget all of their expert knowledge on a topic. If they did, you would be very like, are you having a mental breakdown? This is very weird behavior. But this is how models behave every day."

"You have to understand the materials you're building with in any design role. A table designer would not be oblivious to how oak performs in certain contexts or how pine dents in a certain way. If you're designing for the web and you don't understand performance or how your app is fetching data or what if there's race conditions, if you're oblivious to that, you'll end up with bad design solutions and then with really bad relationships to engineers." Maggie Appleton @Mappletons - Design Engineer at GitHub Next

“If you can vertically center a div, you can probably learn assembly”. Casey Muratori, @cmuratori, programmer and performance nerd, on why it’s essential for optimization: “People often ask: assembly language, what would I ever need that for? There's a very good reason for it: everything else that you might use doesn't tell you anything about what the CPU is actually receiving. If I look at a Java program, if I look at a C program, if I look at Haskell, OCaml, Rust, all I'm seeing is input to a compiler. I have no idea what the CPU is actually going to be asked to do. It's not that hard to be able to learn to read assembly language so that you can see very quickly, is the CPU being asked to do the things that I think it should be asked to do. For the vast majority of tasks you might do in optimization, writing it, no. Reading it, essential. In assembly language, maybe there's 20 or 30 instructions you might have to learn total, because most things in legacy assembly, like x64, are hardly ever output by the compiler. So you only need to learn a very small subset that you're going to be seeing in 90% of cases.”

“It comes at a cost”. Tibo @thsottiaux, on tradeoffs of building Codex in the open: #1# - Artificial repo boundaries: “sometimes we have to draw artificial boundaries and work across multiple repos” #2# - People copy unreleased work: “at times we find that others copy exciting work before we have the time to release it. It's just a little bit sad, but also it's part of the game.” #3# - Random contribution tax: “just like everyone else, we are overwhelmed with random contributions and we have to deal with that additional tax. But then that pushes us to also try and solve for it” And the benefits: #1# - There are good contributions, too: “We get a lot of good contributions” #2# - Onboarding is basically done: “they join the Codex team, they've seen the repo before. They've looked at PRs.” #3# - Energy from being in the community: “To me, and to a lot of the team, it brings a lot of energy to be part of the community and be directly contributing. Not just saying that we care about the community, but actually doing things that you can see it's costing us effort. We don't have to do it.”

Codex doesn't lock you into OpenAI models. Tibo @thsottiaux on why: "If you are part of this community and building an excellent coding harness, why would you couple it to your model? That felt quite disappointing, to make that decision. It didn't feel right. And it's open source in the first place. It would have been trivial for anyone to fork it. But then you're encouraging people to go and use that fork, and now suddenly you have overhead and the only reason you have a fork is because you wanted to change 10 lines of code to add support for another model provider. That feels very silly. So why not just support it in the first place? The other thing is we benefit a lot from being able to give optionality. Maybe today you love using OpenAI models and you're super productive with them, but tomorrow there's a new model that comes out and you want to try that. Why force you to completely change your setup just to try a new model? Optionality is very important to companies that we work with. And this is something that we absolutely lean into."

For engineers in NYC next Wednesday: doing an epic whiteboarding session with @turbopuffer From zero to building a v fast database that's also cheap to operate Agents generate more data than before so understanding primitives that are both cheap + fast is v helpful

It's rare to see a non-AI frontier lab build an in-house AI coding tool that works so much better than what frontier labs have to offer. Ramp did this with Inspect: an AI coding harness fully integrated with their systems, running on cloud machines, and being a smash hit inside the company. Ramp basically runs full-blown cloud development environments (CDEs) for agents to build code on, and validate it, and has made this tool "multi-player" by default, with no opt out. We find it likely that the likes of Codex, Claude Code and GitHub Copilot will build similar tooling in a few months' time to what Ramp already has in-place. Deepdive:

An agent can tell you it's correct, not that it's good. @addyosmani, author & director of engineering, on finding your edge over AI coding agents: “I always go back to: what is alpha? My definition of alpha is advantage. What is the current thing that models are not very good at doing? For software engineers, we often say that your alpha is in taste. Are we building the right thing? Is the thing that we are building actually good? Sometimes people will say an agent can tell you if it's good. I push back on that. An agent can tell you if a thing looks correct, if it's matching a spec. It doesn't mean it can tell you what's good. Good can mean good from a user experience perspective, could be delightful, could be something that a person will actually want to come back to. And it is still sufficiently nuanced that it's going to take time for models to catch up to a point where they can replace that fully. We tell people that judgment, verification, all of these other aspects continue to be important. But even if you say, maybe a year or two from now, models will catch up. We still need engineers to be answerable for these systems. That doesn't happen overnight. That happens when you understand a system, people trust you and you have that expertise.”

“If you are working with a coding agent, there are a lot of things that you can do to make sure that the agent is getting better every day and you as an engineer are getting better every day. Can you log your learnings from the session? Can you log any decisions that were made? Any friction that you ran into?” Addy Osmani(@addyosmani), Author and Director of Engineering

What is intentional compaction? @DexHorthy, founder of HumanLayer, explains: “When context is noisy, you deliberately compress the useful parts into a clear markdown artifact, verify it, and then start a fresh conversation. Frequent intentional compaction is the building block for building software with AI. How do we get the most out of today’s models, how do we control what we’re putting into the context window so we get the best results, which means doing as much work as possible in the smart zone, the first hundred thousand tokens. 1. The research step: we go read a bunch of code and turn it into a doc: that’s our compaction. We take that forward. 2. In the next session we read the ticket and the intent and turn that into a design document: here’s the high-level current state, desired end state, and a bunch of design questions. 3. Then you take the research and the design and you do a new session, new context: you’ve compressed the intent, and you’ve compressed the state of the codebase, so you can then do your planning.”

“Which flavor of AI fatigue?” Charity Majors(@mipsytipsy), co-founder and CTO of Honeycomb, on why we should remember that we are in charge: #1# - Slop #2# - Fatigue #3# - Doom trolling: “what the CEO of Anthropic and OpenAI keep doing about, 'Oh my God, this might be the end of blah, blah, blah.'" “I think that a lot of people, their family members are afraid. Always before the history of technology it's been something cool or fun:the iPhone, it'll make your life better. And now it's just like fear. It's pretty crappy. I would repeat my call for us to remember that we are in control. We are in charge. I think the universal nature of the frustration means that this is a great time to propose experiments where we take back control. Maybe you and your team agree we don't actually want any more AI generated PR descriptions. None of us use AI on Wednesdays. Maybe we take a week. Just take control back, try something, propose something.”

What motivates @KentBeck after 40+ years in software? Veteran creator of TDD, XP, JUnit and co-author of the Agile Manifesto, on what drives him to keep going: #1# - He’s not afraid to start new things “If there's a secret sauce to what I'm doing, it's not being afraid to start over. Look on my GitHub, you'll see project 1, project 2, project 3 and so on. I'll push it a certain amount, and then “the genie” runs itself out of options. It can't make further forward progress, and so I'll wipe it away. Start over. I won't try and tweak it." #2# - Coding with the AI “Genie” has brought back Kent’s creative impulse "That creative impulse is what's come back to me with 'the genie'. I can go, I wonder what a B+ tree looks like - and go, oh, here's an alternative, this adaptive radix tree. What does that look like? I can find out. I sit down with the genie, I work it out, and then there's this artifact that wasn't there before. That's there now because of my imagination and my work. I had gotten fed up with the stupid minutiae of programming." #3# - Kent has FORTY years worth of ideas to build out: “I've got 40 years worth of ideas that suddenly are back in play and I'm having so much fun making things that are real.”

How can you a product that is 10x cheaper or 10x faster than what is already out there? @Sirupsen (cofounder and CEO at turbopuffer) used "napkin math" - doing quick calculations to get rough answers - to get here. Full interview from AIE: Deepdive in The Pragmatic Engineer:

“Ward Cunningham didn't let me touch the keyboard for a while”. @KentBeck, industry veteran and creator of XP & TDD, on learning to code with a master programmer: “Ward was always a much better programmer than I was in terms of low level technique. He also had a gift for design at a higher level and a gift, as you see in the wiki, of picking powerful top level goals and then making something that does that. But I was this 24-year-old punk with attitude and he didn't let me touch the keyboard for a while. I could watch him. Eventually I was like, those parentheses don't balance. You need a period here. And I was actually being useful to him. I was absorbing watching a master programmer at work, but I wasn't really driving stuff. I started understanding the low level patterns and then building up to the next level and the next, and then I would say, well, why is this called this and not that? We'd pull out a thesaurus and look it up and find just the right word for things and then continue. And I started making suggestions that he wouldn't understand right away. So I would take the keyboard for a little while, say, lay something like this. He’d say, ‘Oh, I get it. I get it’. And then he'd take the keyboard back. Over the course of a few months, we developed both a programming style where the keyboard was going back and forth where we were talking at multiple levels.”