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

The first China shock came about when they started producing huge volumes of cheap goods. It drove lots of western manufacturers out of business

The second one is now, where they’ve moved up the value chain to be on par or above western manufacturers in terms of complexity and quality. Cars are the obvious example but all through supply chains you can almost guarantee Chinese manufacturers are producing the same thing, but much cheaper. Most western companies simply cannot compete, nor can many Chinese ones with their only ability to stay alive as being as a result of state subsidies.

There’s another I think, though not from China specifically, but with AI and software. It can produce software right now at huge volumes but for now targets the low end. It can write complex codebases but requires plenty of human handholding.

Does the Jevons paradox hold for any of this? The original Jevons found it about coal where as it becomes cheaper we can consume more of it. But the tools to consume more coal are fixed costs, it takes little more to burn more coal once you’ve a furnace built so when the coal gets cheaper it makes lots of sense to keep it fired up with more coal. The new things like sensors or cars or software - are they the same? Can we really use that much more of those? In some cases yes but also the demand has to be there for it. And furthermore whatever is produced needs to be something with a unique

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