Weeknote

Highlights of the Week

How Claude Code Works in Large Codebases: Best Practices and Where to Start

Some maybe surprising things here about how to use Claude Code with larger codebases that I hadn’t known before.

Hooks make the setup self-improving. Most teams think of hooks as scripts that prevent Claude from doing something wrong, but their more valuable use is continuous improvement. A stop hook can reflect on what happened during a session and propose CLAUDE.md updates while the context is fresh. A start hook can load team-specific context dynamically so every developer gets the right setup for their module without manual configuration. For automated checks like linting and formatting, hooks enforce the rules deterministically and produce more consistent results than relying on Claude to remember

Initializing in subdirectories, not at the repo root. Claude works best when it’s scoped to the part of the codebase that’s actually relevant to the task. In monorepos, this can feel counterintuitive because tooling often assumes root access, but Claude automatically walks up the directory tree and loads every CLAUDE.md file it finds along the way, so root-level context is never lost.

The Question I Ask Myself at the End of Every Day

Billy Oppenhiemer

That’s the question you want to consider. Not, what does the perfect, optimal, most ideal version of this look like? But, How much progress could I make if I made just a small positive contribution each day over the course of an entire life?

[In one of his most famous letters

Highlights of the Week

Maybe You’re Not Actually Trying

https://usefulfictions.substack.com/p/maybe-youre-not-actually-trying

One of the interesting things about all of this is that there was nothing particularly inventive about the strategies my husband deployed. They were more or less exactly the strategies I would have come up with if I’d been put in charge of a similar situation in someone else’s life. Why did it take another person getting involved for me to realize I wasn’t Actually Trying? I think what happened is this: When the stalker entered my life, I was at a low point in personal capacity — broke, alone, addled, etc. My approach towards him at that point (ignore, hoping he’d stop) was the only one that seemed available given my spiritual and psychological resources at the time. But my orientation to the problem became fixed in time at that point of low agency, and it never occurred to me to revisit it as my capacity for action increased. I think we are all like this. People are not just high-agency or low-agency in a global sense, across their entire lives. Instead, people are selectively agentic.

Let’s say that life is divided up into three theaters: work, relationships with others (all kinds) and relationship to self (physical health, introspection, emotional development, all of it). I think it’s the rule, rather than the exception, that people are stuck at an earlier stage of development in at least one area. There is one theater of life where they’re not Actually Trying — where they’re approaching serious problems

Highlights of the Week

The Middle Loop

http://annievella.com/posts/the-middle-loop/

It occurred to me that we often refer to “loops” in software development - the inner loop and the outer loop: • The inner loop is where the craft lives: write code, build, run, test, debug. Tight, fast, local. This is what TDD and better IDEs optimised. • The outer loop is the broader cycle: commit, code review, CI, deploy, monitor, feedback. This is what DevOps and CI/CD optimised. What if supervisory engineering work lives in a new loop between these two loops? AI is increasingly automating the inner loop - the code generation, the build-test cycle, the debugging. But someone still has to direct that work, evaluate the output, and correct what’s wrong. That feels like a new loop, the middle loop, a layer where engineers supervise AI doing what they used to do by hand.

I’m not convinced about this but it is a different way of thinking about it. Nobody knows though as evident in the next one.

Finding Comfort in the Uncertainty

https://annievella.com/posts/finding-comfort-in-the-uncertainty/

I walked into that room expecting to learn from people who were further ahead. People who’d cracked the code on how to adopt AI at scale, how to restructure teams around it, how to make it work. Some of the sharpest minds in the software industry were sitting around those tables. And nobody has it all figured out. There is more uncertainty than certainty. About how to use AI well, what it’s really doing to productivity, how roles are shifting, what the impact

Highlights of the Week

AI 101: What Is a Token (And Why It Runs AI)?

https://www.turingpost.com/p/token

English is often tokenized into words and subword pieces, because spaces clearly separate words and longer terms can be broken into reusable chunks. Chinese works differently: words are not separated by spaces, and single characters often already carry meaning, so tokenization tends to stay closer to the character level. That is one reason the same sentence can produce a very different token count in English and Chinese.

I’d never really thought about this before but it makes sense.

Cybersecurity Looks Like Proof of Work Now

https://simonwillison.net/2026/Apr/14/cybersecurity-proof-of-work/

If Mythos continues to find exploits so long as you keep throwing money at it, security is reduced to a brutally simple equation: to harden a system you need to spend more tokens discovering exploits than attackers will spend exploiting them. An interesting result of this is that open source libraries become more valuable, since the tokens spent securing them can be shared across all of their users. This directly counters the idea that the low cost of vibe-coding up a replacement for an open source library makes those open source projects less attractive.

There’s conflicting opinions on this but directionally it makes sense that more mature systems will be more battle tested for bugs and vulnerabilities - sort of like how it is at the moment then just a bit more turbocharged by AI.

Good and Bad Harness Engineering

https://danielmiessler.com/blog/good-and-bad-harness-engineering

Bitter Lesson Engineering comes from Richard Sutton’s “Bitter Lesson” essay, and it means ensuring that you’re not

Highlights of the Week

Hackernews Thread

And he said something then that I will never forget and which absolutely blew my mind because no one had ever said anything like it to me before: “I don’t think being good at things is the point of doing them. I think you’ve got all these wonderful experiences with different skills, and that all teaches you things and makes you an interesting person, no matter how well you do them.”

I came across this thread the other day about hobbies and while a lot of the ones in it have no interest to me, this quote really did strike me. It is more about the journey rather than the destination. The whole point of a hobby or doing most things is to do the thing and get the experience. It is not about ticking off a box, or trying to get to be the best of the best in the world or doing something nobody else has ever done. More it is about collecting these experiences and skills to mould yourself to be a different kind of person. The one you want to be and it all adds up to make you an interesting person. So just explore the world, in time or space or knowledge.

Nobody Is Coming to Save Your Career

Growth didn’t happen until I deliberately stepped out of the comfortable work and took on something that was bigger than my capabilities. That only happened after I rocked the boat a bit. That’s when the trajectory

Highlights of the Week

How Microsoft Vaporized a Trillion Dollars

https://isolveproblems.substack.com/p/how-microsoft-vaporized-a-trillion-2f5

Moreover, the code was leaking cached entries and even entire caches due to misunderstood memory ownership rules, and suffered from a large number of crashes, in the order of 300,000 to 500,000 crashes per month for the WireServer web server alone across the fleet. New code was throwing C++ exceptions in a codebase that was originally exception-free. The team had coding guidelines in direct contradiction of those of the larger organization, and their testing practices didn’t include long-running tests, so they missed memory leaks and other defects. The team had reached a point where it was too risky to make any code refactoring or engineering improvements. I submitted several bug fixes and refactoring, notably using smart pointers, but they were rejected for fear of breaking something. This further illustrates the pervasive gap in technical leadership throughout the organization.

There’s a few articles I read lately about internal MS practices being a mess. I understand large organisations are all unique in their own way and it never flows as well as it could, but this seems another level through it all.

Agent Responsibly

https://vercel.com/blog/agent-responsibly

There is a fundamental difference between relying on AI and leveraging it. • Relying means assuming that if the agent wrote it and the tests pass, it’s ready to ship. The author never builds a mental model of the change. The result is massive PRs full of hidden assumptions that are impossible to review because neither the author nor the reviewer has a clear

Highlights of the Week

You Will Know Nothing and Be Happy

https://seattledataguy.substack.com/p/you-will-know-nothing-and-be-happy

But there’s a difference between using AI to accelerate your thinking and using AI to replace your thinking!

Previously we built up our mental maps of how things work by writing code. However now that has changed and we need to figure out what the new thing is.

Production Is Where the Rigor Goes

https://www.honeycomb.io/blog/production-is-where-the-rigor-goes

The notes describe five destinations where rigor is already moving to: • Upstream to specification review • Into test suites as first-class artifacts • Into type systems and constraints • Into risk mapping • Into continuous comprehension All of these are great and exciting. Beefing up your pre-production test quality, capturing intent in specification docs, separating specs from constraints, revisiting the jobs to be done by code review, yes yes yes, all of that. Yes please. But where is production on that list? If control is supposed to be moving “closer to reality,” what is closer to reality than your production systems? Production is reality! Reality is production!

Observability has always been a bit of an afterthought at most companies, just like documentation, but new AI systems can make it so much more useful that everyone might start actually caring about them again. Just writing tests and docs for your code is never going to replicate the messy realities of production system so instead we need to be able to see what is going on there and use that as context for the AI to build

Highlights of the Week

AI Should Help Us Produce Better Code - Agentic Engineering Patterns - Simon Willison’s Weblog

https://simonwillison.net/guides/agentic-engineering-patterns/better-code/

I like to think about shipping better code in terms of technical debt. We take on technical debt as the result of trade-offs: doing things “the right way” would take too long, so we work within the time constraints we are under and cross our fingers that our project will survive long enough to pay down the debt later on.

AI tools will allow us to do things differently and one outcome of code becoming much cheaper to write is old tech debt now becomes doable at a fraction of the old cost. So refactoring or code smells can be fixed now without having to try sneak it in to the sprint.

Every Layer of Review Makes You 10x Slower

https://apenwarr.ca/log/20260316

Every layer of approval makes a process 10x slower I know what you’re thinking. Come on, 10x? That’s a lot. It’s unfathomable. Surely we’re exaggerating. Nope. Just to be clear, we’re counting “wall clock time” here rather than effort. Almost all the extra time is spent sitting and waiting. Look: • Code a simple bug fix 30 minutes • Get it code reviewed by the peer next to you 300 minutes → 5 hours → half a day • Get a design doc approved by your architects team first 50 hours → about a week • Get it on some other team’s calendar to do all that (for example, if a customer requests

Intro

Highlights of the Week

Zen of AI Coding

https://nonstructured.com/zen-of-ai-coding/

The cost of changing your mind is lower than it has ever been. Architectural decisions that once felt permanent are now provisional. You chose React. Two months later, you regret it. Ask an agent to rewrite the project. Making imperfect decisions is no longer fatal. In fact, it can be productive. A flawed reference implementation provides better context than a pristine specification. Agents reason more effectively from concrete artifacts than from abstract intent. Rapid iteration is now the default mode.

Building for Trillions of Agents

https://x.com/levie/status/2030714592238956960/?rw_tt_thread=True

Just as designing for users meant putting yourself in their shoes when building software, the same is true when thinking about what agents will run into. For instance, Jared Friedman at YCombinator put everyone on notice: “Even the best developer tools mostly still don’t let you sign up for an account via API. This is a big miss in the claude code age because it means that claude can’t sign up on its own. Putting all your account management functions in your API should be tablestakes now." If an agent can’t easily sign up for your service and starting using it, you’re basically dead to agents.

We’re definitely going to see new forms of companies the next while but what they’ll be is another thing. This is and interesting idea where they could be ones that are more focused on agents and enabling agents than people. The agents are customers not people. For example Ramp released agent cards recently where you give

Intro

Another week of AI things. Not as much here this time but there’s still a lot happening.

Highlights of the Week

My (Hypothetical) SRECon26 Keynote

https://charitydotwtf.substack.com/p/my-hypothetical-srecon26-keynote

If I was giving the keynote at SRECon 2026, I would ditch the begrudging stance. I would start by acknowledging that AI is radically changing the way we build software. It’s here, it’s happening, and it is coming for us all.

It is very, very hard to adjust to change that is being forced on you. So please don’t wait for it to be forced on you. Swim out to meet it. Find your way in, find something to get excited about.

The Edge of Mathematics - The Atlantic

https://www.theatlantic.com/technology/2026/02/ai-math-terrance-tao/686107/

Tao has long been intrigued by, but reserved about, what AI tools can do for his field. The first time we spoke, in the fall of 2024, Tao had likened chatbots to “mediocre, but not completely incompetent” graduate students. About six months later, he told me the models had gotten better “at certain types of high-level math reasoning,” but lacked creativity and made subtle mistakes. But during our most recent conversation, he was more bullish. AI may not be on the cusp of solving all of the world’s great math problems, but chatbots are at the point where they can collaborate with human mathematicians. In the process, he said, the technology is opening up a different “way of doing mathematics.”

Time and time again people have dismissed all AI as being not that great only to revisit it months down the line