Jonas Rohde (@edhor) — Blog

Don't look at unreviewed code

Sat, 25 Jul 2026 00:00:00 GMT

You maybe heard about that “prompts are dead, use loops”, “loops are dead” etc. Things really evolve daily, or it seems to.

Yes, it really makes sense to adapt how you work and how you use these tools, but don’t get distracted by these things. You need to figure out what works best for you, what feels right and how you get the best results for you and the team.

So instead of arguing about the naming… here are the three things I would actually defend:

don’t look at unreviewed code
code → review → code (you can call that a loop)
use an external / different model family for review

The rest of this post is why.

TL;DR

You should be the last reviewer, not the first one
One pass is not a loop → the value sits in the second iteration
Review with a different model family, always with its most intelligent model
Put the review into the prompt as a final step, so it also addresses the findings directly
What you review changes → intent and architecture, not typos

Why you shouldn’t be the first reader

The workflow most people fall into is: prompt, wait, read the diff. That’s the old habit (code appears, a human looks at it) and it wastes the cheapest reviewer you have.

If you are reading code that no model reviewed yet, two things are true at the same time. You are doing work that could have happened before you even came, and you are doing it on a worse draft than the one you could have had. Every finding you catch by hand is a finding a review pass would have caught and fixed while you were doing something else.

And there is a second cost which is maybe even worse. Reading raw agent output pulls you down to the level of typos, missing null checks and style nits… which is exactly the level where you feel productive and contribute the least. You are the one with the context nobody else has: is this even the right thing to build? Spending that on mechanical review is the real waste.

One pass is not a loop

“Code → review → code” looks trivial written down, but the shape I see most of the time is code → review → human reads the review. That’s not a loop, that’s a report.

The value sits in the second iteration. A review that produces findings nobody acts on cost you tokens and produced a document. A review whose findings go straight back to the agent that wrote the code produces a better artifact. And it’s fast, because that agent still has the full context of why it did what it did.

This is also where the tempting mistake is: making the loop longer instead of tighter. Three review passes on a bad plan is still a bad plan. The loop fixes execution quality, not direction.

The key move: a different model family

This is the one I would push the hardest, and it’s the cheapest change on the list.

Let your code be reviewed by an external agent or subagent from a different model family, and always use the most intelligent model of it. If one family wrote it, another family reviews it.

The reason is blind spots. A model is the least likely to catch exactly the failure modes it is prone to itself: same training, same habits, same confident wrong turns. Ask a model to review its own output and you get a competent sounding pass that systematically misses the category of mistake it just made. Ask a different family and the disagreements get interesting immediately, because they come from a different idea of what good code even looks like.

And use the strong model here, not the cheap one. Review is judgment work → it’s the wrong place to save money, and it’s where a more capable model pays for itself the most directly.

Put it into the prompt

The mechanical part that makes this actually stick: integrate that in your prompt directly as a final step, so it’s also addressing possible findings, even before you look at the code the first time.

Not as a separate command you remember to run afterwards. As part of the task itself.

The point is not automation for the sake of it. The point is that no human decision should sit between “code written” and “code reviewed”… because that’s exactly the decision that gets skipped when you’re busy, which is when you need it the most.

What kind of review

“Review this code” is a weak prompt and the reviews you get back show it. What works much better for me is steering the review to one specific lens at a time. Three that earn their place:

a rigor pass for quality and maintainability → the thermo-nuclear-code-review skill is a very sophisticated steering for exactly that, I really like it
a simplification pass → a completely different concern from correctness, and generic review prompts nearly never surface it on their own. ponytail is a super nice one and also includes hooks if you want to integrate it even further
a bug hunt before CI → if you have a review bot in your pipeline: running the same kind of check locally means you find things inside the loop instead of waiting for a pipeline round-trip

Take those as examples for the categories, not as a shopping list. The tools will change. The useful part is that separate lenses give you better findings than one review prompt that has to do everything at once.

What’s left for you

None of this takes you out of the process. It moves you.

You stop reviewing on the level of “this should be a const” and start reviewing on the level of “this solves the wrong problem”, “this shouldn’t be a new abstraction”, “this contradicts a decision we made for a reason”. That’s the review only you can do.

It also changes what review structurally is: continuous, inside the loop, happening while the work happens. Instead of a handoff at the end to a colleague who has to context-switch into a 40 file diff. I think that shift takes the whole pull request ceremony with it eventually, but that’s a separate argument.

For now, just don’t be the first one to read it.

I'm not the expert, and that's the point

Sat, 25 Jul 2026 00:00:00 GMT

In the last months some people asked me for advice regarding AI and agentic coding. They wanted to know things like: how to use these agents, my experiences, best practices, which model to use etc.

That actually increased in the last weeks, so I asked them if it would be helpful to have a summary of things going on in that field on a regular basis. They agreed. This blog is the public part of that.

So before anything else, let me say what you are actually getting here… because I think the framing matters more than the content that follows it.

TL;DR

I am not the expert on this, and I don’t think anybody is yet
“Then just write it by hand” is fair today and still misses where this goes → if the results are bad it’s most likely misusage
What I’m really bad at: slowing down, recapping, evaluating
Not every generated line needs to be a pull request
Expect field reports with a date on them, not tutorials

Far away from being the expert

Let me get that out of the way first.

I am far away from being the expert on agentic coding, or having a perfect workflow, or getting mergeable code one-shotted. Or maybe even reaching the point where I get code out of the models which is on the same quality as I would get if I did it by hand all the time.

That’s not me being humble as a rhetoric move. This whole thing is maybe two years old in the current form and it changes monthly. Everybody presenting a finished methodology is really just presenting a snapshot.

”Then just write it by hand”

Maybe you think exactly that… and yes, maybe it would actually be faster and maybe the results would be even better. I really get that and see the point at the current state today.

But I think we need to get over it: these frontier models can write fully functional code on nearly the same level most of us can deliver. If the results are bad, it’s most likely a misusage, wrong/missing/polluted context or anything else.

That’s basically the reason I write any of this down. It moves the question from “can it do this?” to “what did I actually give it?” → and the second one you can do something about. When a model produces garbage out of a codebase where the truth is not findable, or out of a session that already rotted, that’s not the limit of the model, that’s what you gave it.

And that’s also happening to me… regularly. The reframe doesn’t make me better at this, it just points me at the part I can fix.

What I’m really bad at

I want to see what’s working, what’s not working, which model is good at which things or not… and to be honest… I am not good at evaluation at the moment. I am bad at slowing down, recapping and adapting, maybe because of my ADHD, but that is something I need to get better at.

I think this is the underrated skill in the whole field. Not prompting, not picking tools. Evaluation. Actually noticing which of the twelve things you changed last week made anything better, instead of collecting habits that felt good in the moment. Most of us (definitely me) are running on vibes and call it experience.

Writing this on a schedule is my fix for that. It forces the recap I normally skip, and it puts a date on everything so I can be visibly wrong later. That’s a feature, not a bug. A workflow I described in March that I silently dropped by July is more useful to you than a polished guide pretending it never happened.

Not everything has to be a pull request

To be clear, I don’t say each generated LOC needs to be for a pull request trying to get merged into production. If you don’t feel comfortable using it for production work, use it for prototypes, use it for getting ideas, use it for battle testing your solutions or stuff like that.

And that’s not the consolation prize, that’s how you build the feeling for when it is ready for the production work. You can’t get that from reading about it, only from watching these tools succeed and fail on problems you understand well enough to grade yourself.

We are all over the place

Look around any engineering team right now and the spread is huge. Some of us are creating a hell lot of tokens, some of us nearly nothing. Same tools, same access, completely different usage.

I don’t think that’s a discipline problem, and treating it like one is how you get a mandate nobody follows. It’s an information problem. The people on the low end mostly never saw what the setup looks like when it works, and the people on the high end nearly never write down what they changed.

We can and we should learn from each other here, and also make the environment better for ourselves and also for our agents, because it turns out that’s the same work.

The thing that really pushed me

What really impressed me lately was not an engineering team at all. It was seeing people with no engineering background (marketing people) writing their own skills and plugins, experimenting with it, using MCPs in different tools, automating stuff. It’s really crazy, and it moved faster than most engineering adoption I’ve seen.

Think about that for a second, because I find it the most interesting data point in this whole discussion: the group with the least attachment to writing code by hand moved the fastest. That’s not a coincidence, and it’s uncomfortable if your professional identity sits on the craft → which is a post of its own.

It really inspired me to also go more in that direction, be even more engaged, share more. This is part of that.

What to expect here

Field reports, not tutorials. Things I tried, with a date on them, in the state I really found them, including the parts that didn’t work.

And the obvious one, which I mean seriously: don’t copy any of it blindly. Take the observation, leave the config → there is a whole post about that.

Actually I don’t really know where to start with all of this. I have so much to share but don’t want to overload you, so I just start where we are now and go one topic at a time :D

Orchestrate, don't operate

Sat, 25 Jul 2026 00:00:00 GMT

Every now and then a model shows up that is not just a better version of the last one. A new generation of model, a new type of model, with a whole new level of taste and capabilities. But it is expensive: expensive to run and expensive to use.

And then nearly everybody does the same thing, me included: you run it exactly like you ran the one before. Same prompts, same single-agent loop, same habits… and a bill that shows up without any of the value the model was supposed to give you.

The fix is not rationing it. The fix is putting it into a different seat.

TL;DR

Don’t run a new top model like you ran the old one → same usage, way more cost, similar output
Its value is taste and orchestration, not throughput
Let it plan, write the subagent prompts, read the results and decide what to redo → let cheaper models search, read and type
Run it on medium or at the very most high (the levels above burn your tokens in seconds)
If your tasks are already well defined, you are the orchestrator → skip the layer

The trap

The failure mode is sneaky because nothing looks wrong. You give the best model a task, it does the whole thing itself: greps the repo, reads twenty files, writes the boilerplate, runs the tests, fixes the lint… and the result is good.

It’s just that most of those steps produced output you can’t tell apart from what a model at a fraction of the price would have produced. And you paid the premium rate for all of them.

Searching a codebase is not a task that rewards taste. Reading a file isn’t. Writing the fifteenth similar handler isn’t. The expensive model is not better at any of that in a way you can measure. It’s better at deciding which files matter, whether that fifteenth handler should exist at all, and whether the result is actually right.

So you paid for judgment and used it for searching and typing.

Put it in the orchestrator seat

The pattern: the strongest model you have holds the goal, writes the prompts for the agents doing the work, reads what comes back, and decides what to accept, redo or throw away. It doesn’t do the work itself.

Concretely that means telling it to:

use cheaper models for helper tasks → searching, reading, mechanical implementation with a clear spec. This is the single biggest cost cut available
run on medium or at the very most high → the levels above burn your tokens in seconds and in my experience nearly never change the decision it ends up with
also use external agents → if you have more than one agent CLI around, let it drive them non-interactively as workers. That’s also the natural place for a review from a different model family
look at the results, not just delegate → this is what makes it orchestration instead of a routing table

That last one is really the whole thing. The value is that it looks at the subagents and their results and steers them, killing a bad approach after one round instead of five.

The word I keep coming back to, as weird or humanized as it sounds, is advisor. Orchestrator and advisor: it plans, it delegates, it judges, it advises. It doesn’t type.

The important part: tell it explicitly

Here is the thing nobody tells you and which cost me real money to learn.

Left alone, a capable model will helpfully do the work itself. That’s what it’s trained for: you gave it a task, it completes the task. It will not spontaneously decide that step four should go to something cheaper. It just gets on with it, competently, at the premium rate, including every search and every helper task on the way.

So don’t let it take over a complete task itself, incl. searches and all these helper/worker tasks → that’s how you burn your tokens. Prompt it to be the orchestrator, explicitly, in the prompt.

Without that instruction the whole pattern just doesn’t happen, and you only notice it later on the invoice.

When to skip the layer completely

Two-layer setups are not always right, and this is where I think people overbuild.

If you are doing a plan + implementation setup (the task is fuzzy, the approach is not settled, somebody has to decide what “done” even means) then yes, take the strongest model for the plan/orchestration agent. That’s exactly the shape it is good at.

But if you already have well defined tasks, you as the human are basically the orchestrator. You did the decomposition, you know what has to happen, there is no judgment left to delegate. Then the orchestration layer is pure overhead, you are paying a model to forward instructions you already wrote. Call the worker model directly.

Keep the review either way. Skipping the orchestration layer means you took over the steering, it doesn’t mean the work stops needing a second pair of eyes from another family.

Why this really cuts the bill

Worth being precise about the mechanism, because “use cheaper models” alone is not the insight.

The saving is not mainly the price difference between the tiers, even though that’s real. It’s that most tokens in any bigger task go into exploration: reading files, searching, trying something and backing out again. That’s the bulk, and that’s exactly the part where the model tier matters the least. The tokens that really need the strong model are a small share: the plan, the judgment calls, the assessment of what came back.

Splitting those two groups is where the cost drops a lot, and it drops without the quality dropping → because you didn’t downgrade the decisions, only the labour.

That’s basically the whole idea: use the expensive model only for the parts where its judgment actually shows up in the result.

Turn the reasoning up before you turn the model down

Sat, 25 Jul 2026 00:00:00 GMT

Short: smarter → needs less reasoning → fewer tokens for easy work → cheaper.

That sounds wrong the first time you read it, because we all learned the opposite. Big model expensive, small model cheap… so when the budget gets tight everybody does the same thing: switch to the smaller model and crank the reasoning up to compensate.

And that’s mostly the worst option you have.

Written in July 2026. Model names and effort levels will be outdated pretty quickly, the mechanism won’t.

TL;DR

There are two dials: model tier and reasoning effort. Most people only ever touch the first one
Better adjust the reasoning level than switching to a smaller model
A more capable model needs less reasoning for the same result → it can be cheaper and better at the same time
Weak model + maximum effort is the worst cell in the whole grid
Start strong and tune the effort down. Not the other way around.
Escalating to a better model is cheaper than shipping something mediocre

Two dials, and everybody only turns one

Every serious model today has some reasoning or effort setting: low, medium, high and something above that. And most people I talk to pick a model once, leave the effort on whatever the default was, and then treat “which model” as the only lever they have.

But the effort dial does something really different from the tier dial, and it’s usually the one you actually want.

Reasoning tokens are tokens. They get generated, they get billed, they fill up your context. A model on maximum effort thinks a lot before it answers, that’s the whole point. And for a task that didn’t need it you paid for all of that thinking and got the same answer anyway.

The concrete case

It’s not worth it to use Sonnet on xhigh. Use Opus on medium, it’s a more capable model, needs less reasoning for the same “intelligence” and it’s cheaper.

That’s the sentence I would put on the wall of every team getting nervous about their usage. The smaller model on maximum effort is doing more work to get to a worse answer, and you pay for the extra work.

Why? Because reasoning is how a model compensates for not immediately knowing. A stronger model needs fewer steps to get to the same place: you pay for capability once, instead of paying for extra thinking on every single task.

The worst cell in the grid

If you lay both dials out as a grid, one square is clearly the loser: weak model, maximum effort.

It burns the most tokens per task of all the small-model configurations, it’s slow, and it still lands below what a stronger model gives you on medium. You get the cost profile of the expensive option with the quality profile of the cheap one.

And it feels responsible while you do it, which is maybe why it’s so common. You didn’t reach for the expensive model, you were being careful. But you weren’t, the cost just moved to a place the model dropdown doesn’t show you.

So what I do now

The default that works for me:

take the strongest model I have access to
tune the effort down until the quality drops
leave it there

Not the other way around. Starting cheap and cranking the effort up until it works means you never find out how good the result could actually be. You only find out how much thinking a weaker model needs to approximate it.

Nearly everything I do daily runs on medium. High is for the genuinely hard stuff where the plan itself is the difficult part. The levels above that burn your tokens in seconds and honestly nearly never change the decision the model ends up with.

Where this flips

There is one case where “just take the small model” is right: bulk mechanical work with a fully specified spec. Migrations, mass renames, data shape changes, the fifteenth similar handler. Intelligence buys you nothing there because there is no judgment left in the task, somebody already made all the decisions and volume is the only cost driver.

Which is also why this fits together with putting the strong model into the orchestrator seat instead of letting it type. The strong model decides, the cheap ones execute the decided part. Same principle, one level up.

Escalating is cheaper than shipping bad work

Last thing… and this one really took me the longest to accept.

If a cheaper model gives you something that doesn’t meet the bar, don’t review it, don’t patch it, don’t argue with it in three follow-up prompts. Just run it again on a better model.

Re-running a task costs a few cents. Reviewing and fixing a weak result costs your attention, which is the actually scarce thing. And merging it costs whoever touches that code next, forever. The price tag on the model dropdown is the smallest number in that whole comparison and it’s the only one we ever look at :D

So: judge the output, not the price tag.

Steal the idea, not the config

Sat, 25 Jul 2026 00:00:00 GMT

Don’t blindly copy-paste anything I say or show you. Don’t do that with stuff from anyone. Don’t blindly install skills, paste things into your CLAUDE.md or complete prompts.

See all of that stuff as ideas or inspiration. It’s like anything else in your setup: you start somehow vanilla, and if you find something not working for you, address that. You see optimization potential? Try it.

That’s the disclaimer I put in front of everything I share… and here is why I think it’s more than just being polite.

TL;DR

A shared config is someone else’s answer to a problem you maybe don’t have
Copying is not neutral-if-unused → a wrong instruction overrides what the agent would have found out by itself
Start vanilla → hit real friction → fix that specific thing → keep it only as long as it earns its place
What’s worth sharing is the observation, not the artifact
Nobody ever deletes anything from these files. Do that too.

A config is an answer to a question you never asked

When somebody publishes their CLAUDE.md, a skill or a prompt library, what you see is basically a list of things that went wrong for them. In their repo, with their conventions, on the model they used at that time.

“Always run the type-check before committing” is in there because their CI kept breaking. “Never use barrel files” is in there because some import cycle cost them a day. “Prefer the repository pattern” describes an architecture you don’t even have. Take the context away and what’s left looks like universal best practice, but is really just a list of things that hurt them once.

Which is fine, that’s exactly what makes it interesting to read. It’s just not what makes it good to install.

Copying is not free, even when the instruction is wrong

This is the part people underestimate. The intuition is that a borrowed instruction either helps or does nothing. Both halves of that are wrong.

It’s not free, because everything in that file goes into every single session, relevant or not. A big context file is a tax on every session you will ever run, and the numbers we have say these files are really easy to overuse: developer-written ones helped a little, generated ones made things slightly worse and more expensive.

And it’s not harmless when it’s wrong, because agents follow instructions quite literally. A modern agent dropped into your repo without any guidance goes and looks: searches, reads the actual code, figures out the actual pattern. Now give it a confident instruction that doesn’t match your repo → you just replaced something it would have gotten right by looking with something it now gets wrong by obeying.

You didn’t add context there, you overrode it.

And nobody really calculates that trade: the upside is a bit of guidance you maybe don’t need, the downside is your agent being confidently wrong about your own codebase.

Start vanilla, then earn every addition

So the loop I would argue for is boring and it works:

start vanilla → no skills, no context file, defaults. Yes really, you need a baseline before you can say if anything you add is an improvement
work, and notice real friction → not theoretical friction, the thing that annoyed you for the third time this week
fix that specific thing → the narrowest fix for the friction you actually felt
keep it only while it earns its place → if you can’t remember why a line is in there, that’s information

Why the order matters: additions triggered by inspiration grow forever, because nothing in that process ever removes something. Additions triggered by pain limit themselves, because you only have so much pain.

And this is also why I’m suspicious about my own setup, not only about other people’s. To be honest… I really can’t tell you which of my customizations are load-bearing and which are just superstition I added once and never tested again. Being bad at evaluating that is a real problem, and stacking somebody else’s untested choices on top of my own untested choices doesn’t make it better.

If configs don’t transfer, why write about this stuff at all?

Because the part that transfers was never the file. It’s the observation behind it: this failed for me, here is what I think happened, here is what I changed. That survives the move to your repo, your model, your team. The artifact doesn’t.

So when you read somebody’s setup, mine included, the useful question is not “what do I copy?” It’s “what problem was this person solving, and do I even have it?” Usually the answer is no… and you still learned something, because now you know that problem exists and what it looks like when it shows up.

The habit nobody has: deleting

Last thing, because it’s the cheapest improvement available and basically nobody does it.

These files only grow. Every one I ever saw, mine too, has instructions for a framework that got replaced, a convention that changed, a model weakness that got fixed two generations ago. And all of it still loads, every session, describing a project that doesn’t exist anymore.

Open yours and read it like the agent would: as a factual description of the codebase you are about to work in. Delete everything that is not true anymore.

It’s usually more than you think, and it’s the one edit that makes the file better in every direction at once → smaller, cheaper, and not lying anymore.

If your codebase is good for new-joiners, it's also good for agents

Mon, 20 Jul 2026 00:00:00 GMT

Starts with an empty context. Explores the repo to figure out how things work, picks up patterns that are already deprecated, follows docs that don’t match reality anymore… and the output needs a careful review before you can trust it.

You probably are thinking of agents, context windows, fresh sessions… but I was talking about this new guy who joined last week.

He tries to find his way through the giant codebase with 3 different ways of styling, different UI libraries, multiple validation approaches. And some components with “new” in the filename which are actually used nowhere. The wiki pages he reads are outdated for at least half a year, and it takes him a whole day (and asking multiple people) just to get the complete stack running. Only to find out one important service he has no access to is missing.

It maybe sounds familiar. Everybody knows this is something we should clean up, but other things have more priority, and “hey, you just have this pain once, then you know it”.

That’s true for the new joiner. His context window fills up once and stays. But there is one guy going through this exact process multiple times a day, with a context window that gets deleted on every fresh session… your code agent.

TL;DR

A fresh agent session and a new joiner have the identical problem → no prior knowledge, only what’s findable
The difference is the frequency. The human pays that once, the agent pays it on every new session, forever
Agents are really good at self-onboarding, but only up to the quality of what’s findable
They don’t hallucinate your architecture, they infer it from the stuff you left lying around
Agent confusion doesn’t reach you as a question. It reaches you as a mediocre diff.

Why it’s the same problem

An agent session starts empty. It knows nothing about your project, your conventions, or that three year old decision behind the weird adapter in the payments module. It builds that up the only way it can: searching, going through the code, following the links you left it… and it does that again on the next session, and the one after that.

The good news is agents are really good at this. It’s the part they are built for: reading a lot of unfamiliar material fast and staying close to what’s actually there instead of inventing something. A fresh session is maybe even the better onboarder: faster, never tired, and no ego about reading the same file for the fifth time.

But that only holds as long as the material supports it. An agent finds its way when the path from “task” to “the right file” is short, when there is one way to do a thing instead of three half-migrated ones, when the documentation matches the code. And when the reasoning behind non-obvious decisions is written down somewhere the code can’t say it itself.

Take that away and the agent doesn’t fail loudly. It does something worse: it infers confidently from bad evidence. Three styling approaches in the repo means it picks one, plausibly and defensibly… and often the deprecated one.

That’s not really a hallucination, the codebase told it wrong.

And that’s also why dead code became an actual liability. A human learns at some point that everything with “new” in the name is the abandoned rewrite. An agent reads it as the newest and most intentional version, because that’s literally what the name says.

The frequency is the whole argument

If this was only about quality, this post would be the usual “keep your codebase clean” advice and you would have stopped reading. The thing that changed is the multiplier.

Onboarding used to be a one-time cost per person. You could rationally decide to leave the mess and let that pain be paid by somebody new, twice a year. The maths worked out. Now the same environment gets re-read by a fresh context multiple times a day, by something that produces code the whole time. A one-time tax became a recurring one and nobody redid the calculation.

And the pain is invisible, which is really the problem. When the new joiner runs into the wall, he walks over and asks you. When the agent runs into it, it just produces something slightly wrong and you think: the model is getting worse.

The feedback that would tell you your environment is broken never reaches you as a question. It reaches you as a mediocre diff.

Your new joiner is a measurement instrument

Which brings me to the practical part. You can’t ask your agent what confused it, but you can ask a human, and the answer transfers nearly perfectly.

You really can test your setup when you have new people joining. If they have no questions at all, that reads in two very different ways: either you did a great job, or they decided to struggle through quietly instead of looking slow in week one. Ask them to walk you through their first day if you want to know which one it was.

If there are a lot of questions, look at what kind:

“why don’t we have this?”
“why is this not working?”
“what do I need to install?”
“something is not working as I assumed”
“this readme is pretty old, is this actually up-to-date?”

Every single one of those is a gap between what your project claims and what it is. And each one tells you three things at once: you are answering out of experience that is written down nowhere, that knowledge is not spread around the whole team either. And there is a high chance this is also the answer why your results with agents are not as good as everybody told you they would be.

That last one is the interesting one for me. If your agents underperform, the instinct is to reach for a better model, a longer prompt, more tooling. Sometimes the honest answer is that you handed a competent worker a codebase where the truth is not findable.

Where the answers go

So now you have a list of questions. The tempting move is to dump every answer into one big context file so the agent always has it.

Don’t → a big CLAUDE.md measurably doesn’t help and can even hurt, and it is a tax on every single session, no matter if the information is relevant this time or not.

Put the answer where the question was asked instead. If the confusion was about a function, the answer is a comment above that function. If it was about a setup step, the answer goes into the setup script, or into the error message that fires when the step is missing. If it was about a decision, write the why next to the thing it explains. That’s the one piece of context an agent can never derive from reading the code, because it’s about the alternatives you rejected.

That’s a full reversal for me by the way, and it took a while. I used to treat comments as a smell. But that rule was about humans maintaining prose they don’t want to maintain… and the reader changed. There is more about where exactly that inverts in Maintainable for whom?.

And while you are in there: delete the dead component, finish the half-done migration, fix the readme. Not as a cleanup sprint. As the cheapest AI investment you have available → no budget, no vendor, no procurement.

One effort, two beneficiaries

I like this one because you don’t have to believe anything about agents for it to be worth doing. Making a codebase self-explaining was always the right thing, it just never had a good enough business case against the next feature.

Now it has one. Improving the environment for a new joiner automatically improves the environment for the coding agents and the other way around. One effort, two beneficiaries. This is something we could work on and keep an eye on.

The agents didn’t create this problem. They just made it expensive enough to finally care about it.

Maintainable for whom?

Mon, 20 Jul 2026 00:00:00 GMT

If an agent is taking care of the code, what is “maintainable” even meaning? Maintainable for humans, or for agents?

That question got stuck in my head, because “but is it maintainable?” is the most senior-sounding question in every code review. It ends discussions. Nobody is against maintainability, like nobody is against safety.

But the word has a hidden assumption we never had to spell out. For decades the answer was so obvious nobody asked: maintainable for a human, with a human’s working memory, a human’s reading speed and a human’s patience. If agents write and maintain most of the code, that assumption breaks… and I don’t think the word gets useless then, it just needs a new definition.

TL;DR

“Maintainable” always meant “maintainable by a future human hand-editing this file” → that part was never questioned
A lot of it survives the shift: clear names, one obvious pattern, discoverable structure help agents exactly like they help humans
But some rules invert: verbosity, repetition and “too many” comments are cheap for agents → implicit conventions and tribal knowledge, which humans tolerate, are the deadly part now
My new definition: maintainable is what a fresh context window can safely change

What survives

The good news first: most classic maintainability advice was never really about humans, it was about readers, and agents are readers too. A fresh agent session is structurally a new joiner: no tribal knowledge, only what’s discoverable. So everything that helps a new joiner still holds:

self-explaining names and structure
one way to do a thing, not three half-migrated ones
the why written down where the code can’t say it
tests that state the intended behavior, not the implementation

If your codebase is a mess, agents won’t save you. They’ll just produce mess faster. So no, maintainability is not obsolete, it’s what the agents themselves depend on.

What inverts

Now the uncomfortable part. Some rules we treated as timeless were actually workarounds for human limitations, and those flip:

“Don’t repeat yourself, ever.” DRY exists because humans forget to update the second copy. An agent greps all copies in seconds. Aggressive abstraction to save keystrokes (keystrokes are free now) often just adds indirection a fresh context has to unwind first. Some duplication with local clarity beats a clever abstraction three files away.
“Comments are a smell.” This one I really reversed on completely. The old logic: comments drift, humans hate maintaining them, code should speak for itself. But agents read every comment on every session and update them while they edit. An inline “why” comment is context exactly where it’s needed, paid for exactly when it’s needed. The opposite of a bloated CLAUDE.md that taxes every session.
“Keep files short.” Human-sized files were about scrolling and cognitive load. For agents the unit that matters is not file length, it’s whether a change is local: can you touch this behavior without holding five distant files in context?
“Clever and compact is elegant.” Nobody is reading the code for pleasure anymore. Boring, explicit, maybe even verbose code that a model can’t misread wins against the clever one-liner every time.

And the things humans tolerate best (implicit conventions, “everyone knows we do it like this”, knowledge living in one colleague’s head) are exactly what agents can’t survive. We optimized for the weaknesses of a reader who is not the main reader anymore.

The new definition

The definition I landed on for myself: code is maintainable if a fresh context window can safely change it. Safely meaning: find the right place, understand the local why, make the change and verify it, without a human feeding it tribal knowledge and without unintended blast radius.

To be clear, this doesn’t mean humans stop reading code. You’ll still read code, on the level of review, architecture and “is this actually what I meant”. And a codebase a fresh agent can safely change is one a human can safely read too. The reader changed, not the care.

So next time “but is it maintainable?” ends a discussion, ask the hidden question out loud: maintainable for whom? If the honest answer is “for a kind of maintenance that stopped happening”… then maybe you are not defending quality anymore, just a habit.

The adoption experts who won't adopt

Mon, 20 Jul 2026 00:00:00 GMT

It’s really funny to see: the exact people who complained for years about users not being able to adopt new software are now behaving the same with agents.

Every developer knows the complaint. We built the new system, it’s objectively better, and the users… just won’t use it. They cling to their Excel sheet. They ask for the old button back. They found one bug in week one and now “the new tool doesn’t work”. We rolled our eyes at this for a decade, gave talks about change management, built onboarding flows and feature tours because users resist change.

And now agents arrive in software development, and the same people (us) go through the identical stages. Which brings me to the question this post is actually about: why is this agents topic so difficult exactly in software development? I think the answer is more uncomfortable than “developers are lazy”.

TL;DR

Developers are going through textbook adoption resistance: denial, cherry-picked failure stories, clinging to the old workflow. The same pattern we mocked our users for
The blocker is not capability. Agents got good, the arguments didn’t update
The real blocker is identity: writing code is what many of us built our professional self-image on, and agents automate exactly that part
The way out is to stop being fixed on the keystrokes. You were never paid for code, you were paid for working software

The pattern looks really familiar

Watch a software department meet agents and you see every stage we know from our users:

Denial: “It’s just fancy autocomplete.” Said today, about tools that plan, run tests, review their own diffs and work for hours unattended.
The one failure story: “I tried it once, it hallucinated an API. Useless.” One bug in the new system, and the old Excel sheet was suddenly great again… remember?
Workflow-clinging: insisting every agent change goes through the full human-sized ceremony, so the new way is guaranteed to feel slower than the old one.
Waiting it out: “Let’s see where this goes first.” A strategy that, as far as I can tell, has never once worked for a platform shift.

If a user behaved like this about our software, we would call it a change management problem and get to work. Somehow when we do the same ourselves, it counts as engineering rigor.

It’s not about capability

First, rule out the obvious suspect. Most of the resistance arguments were formed on models from one or two generations ago and never updated. Agents today onboard into a codebase like a professional new joiner, keep their own context, verify their work and loop with reviewers. Are they flawless? No. Neither is any colleague you ever had. The honest comparison is not “agent vs. perfect engineer”, it’s “agent loop with reviews vs. what your team actually ships under deadline pressure”.

But here is the thing: the capability arguments get weaker with every model generation, and the resistance stays exactly the same. So I don’t believe capability was ever the real argument.

The real one: identity

Software developers are in a strange position: we are the first profession watching our craft itself get automated, by ourselves, with tools we built. Writing code is not just what many developers do, it’s what they are. The years of learning, the taste, the elegance of a well-crafted function: that’s the identity. And agents walk in and do exactly the typing part.

That’s why I think this is so much harder in software departments than anywhere else. Nobody’s identity was “person who fills in the Excel sheet”. But “person who writes great code”… that’s a self-image worth defending, and people defend it with technical-sounding arguments because those are more acceptable than “I’m scared of losing what makes me valuable”.

I get asked why I’m not more attached to writing code myself. My honest answer, and honestly my answer to the whole debate:

Why are you so fixed on writing code? I really don’t care.

I care about the idea, the product, the system that ends up existing in the world. Code was always the means, it was never the point. And I noticed that this sentence provokes developers way more than any benchmark result does, which tells me we are not really arguing about tools here.

Treat it as the change project it is

The funny part is that we already know the cure. It’s our own playbook, the one we always wished management would apply to our software rollouts:

Don’t argue capability with people defending identity. No benchmark convinces someone whose real objection is unspoken. Address the actual fear instead: your judgment gets more valuable, not less.
Wins over slides. One team visibly shipping faster with agent loops converts more colleagues than any all-hands deck.
Meet the workflow where it is. Users kept their Excel sheet because the new tool ignored how they worked. Same here: forcing agent output through unchanged human-sized ceremony guarantees it feels slower. Adapt the process, not just the tooling.
Expect the dip. Every adoption gets worse before it gets better. Teams that quit in the dip “proved” it doesn’t work… the same proof our users always brought us.

You were never paid for code

No customer ever paid for keystrokes. They paid for working software: problems solved, systems running, decisions encoded correctly. Everything you actually bring (judgment, taste, architecture, knowing what not to build) becomes more valuable when the typing is free, not less. Even the old quality instincts survive the shift, they just need a new definition (more on that in Maintainable for whom?).

The adoption experts were right all along: resisting a platform shift doesn’t stop it, it only decides how much say you have in how it plays out. We knew that when it was about our users. Now it’s about us.

We need to get over Git

Mon, 20 Jul 2026 00:00:00 GMT

We need to get over Git.

Last year it came into my mind: is Git really the best solution? We are relying on it just because we’ve done it since ever, right? That was before I created my first worktree, before this whole agentic coding era. Even back then it somehow felt clunky, like bureaucracy: you need to create commits (I never found a good strategy of scoping them), need to push, somehow fight local changes against upstream, stashing, branching. It suddenly just didn’t feel right anymore.

It didn’t feel like a tool helping me build software anymore, more like paperwork. Then agents arrived, and it got really obvious.

TL;DR

Git’s ceremony (commits, branches, stashes, PRs) is a coordination protocol for a world where human work was expensive, serial and full of handoffs
Agents broke every one of those assumptions: work is cheap, parallel and continuous. The ceremony didn’t adapt, it just became overhead
Git the database (content-addressed snapshots, distributed sync) is fine and will survive
Git the workflow is what has to go, and agent harnesses are already quietly replacing it with checkpoints, worktrees and review loops
I built an experiment to test this: ChangeLedger, where the change is the primary object and a Git commit is just the export format

What Git actually is

Strip the habit away and Git is two things bolted together:

A database: content-addressed snapshots of your tree, with cheap diffing and distributed sync. This part is genuinely great.
A coordination protocol: commits as units of human intention, branches as units of human ownership, PRs as units of human review, stashing as a workaround for humans doing one thing at a time.

We treat the second part like a law of nature, but it’s just an interface, designed around the constraints of 2005: human labor is expensive, so every change deserves a hand-written message. Humans work serially, so you need stash and branch juggling. Handoffs between humans are the bottleneck, so you build a whole ceremony (the PR) around them.

Ever noticed that nobody actually has a good answer for how to scope a commit? “Atomic, but not too small, logically complete, but reviewable.” Twenty years and the best we have is vibes. For me that’s a sign the concept itself doesn’t really fit the work.

Agents broke the assumptions

Every constraint the ceremony was built for is gone:

Work was expensive → now it’s cheap. When an agent produces hundreds of changes an hour, hand-scoped commits with hand-written messages just don’t scale anymore.
Work was serial → now it’s parallel. My first worktree was the moment this clicked for me: suddenly five agents work five tasks in the same repo without fighting each other. Stashing (this whole “local vs. upstream” wrestling) only exists because one human, one working copy, one thing at a time. That world is over.
Handoffs were the unit of review → now loops are. Agent work gets reviewed continuously by other agents while it happens, not once at the end by a colleague who context-switches into a 40-file diff. The PR boundary sits at the wrong place in the wrong rhythm. (I even skip branches and PRs completely for fully agentic work, because the ceremony protects a handoff that just doesn’t happen there.)

What stays genuinely valuable is none of the ceremony: it’s checkpointing (“return to any earlier state”), provenance (“which session changed this and why”) and gating (“what’s allowed to reach production”). Git the database does checkpointing well. The ceremony does provenance and gating badly: a commit message is a worse record than the full agent transcript that produced the change.

It’s already happening

Look closely and the replacement is being built, just not announced as one. Agent harnesses auto-checkpoint every step, so you can rewind without ever having “committed”. Worktrees turned the one sacred working copy into disposable parallel sandboxes. Stacked-diff tools like Graphite exist because raw branch/PR mechanics already don’t fit how work flows. And Jujutsu quietly made “every edit is automatically a snapshot, describe it later, reshape history freely” feel normal, on top of Git’s database, with Git’s ceremony removed.

That’s the pattern I would bet on: nobody “replaces Git”. Git sinks one level down and becomes plumbing (like TCP/IP: nobody thinks about it, it’s just there). The layer we actually touch becomes: continuous checkpoints, parallel sandboxes, session-level provenance and review loops instead of review handoffs. The resistance to this will be loud, because Git fluency was hard-earned. I get that, mine was too.

I got curious enough to build it

At some point complaining wasn’t enough, so I started an experiment to see what the layer above Git could look like. I call it ChangeLedger: change-native development infrastructure, where the product change is the primary object, not the commit.

The model, in one line:

Intent -> Change -> Operations -> Checkpoints -> Evidence -> Git export

A change carries its goal, constraints, decisions and rollout state. Every mutation is an attributed operation with a stated intent. Every checkpoint is an immutable source tree, created continuously, never hand-scoped. Verification results attach as typed evidence to the claims they support (“cancellation behavior is correct” → the test run that proves it). And Git? Git is the export format: one squashed synthetic commit per approved, integration-ready change, generated at the end. Exactly the demotion from the last section: workflow above, plumbing below.

And look what dissolved on the way: nobody scopes commits (checkpoints are continuous, the change is the unit). Nobody writes commit prose (intent was declared up front, evidence is attached, the message is derivable). And nobody stashes (ordinary files are just a workspace projection of the ledger’s objects).

It’s a runnable local MVP, not a product. The point was never to ship a Git killer, I wanted to check if the ceremony is actually load-bearing. Spoiler: it isn’t. Everything valuable (checkpointing, provenance, gating) got stronger when intent and evidence became first-class and commits became output.

What I actually do today

I’m not waiting for the successor to be announced. The pragmatic version, today:

Fully agentic work skips the ceremony. No branch, no PR, no hand-scoped commits: the agent loop with reviews is the quality gate. The ceremony only earns its cost where a real human handoff happens.
Worktrees by default for anything parallel. The single working copy is a habit, not a requirement.
Provenance over commit prose. The session and its transcript are the real record of why a change exists. Commit messages become labels, nothing more.
Let the harness checkpoint. I stopped creating safety commits “just in case”, the tooling already snapshots continuously.

None of this abandons Git. It demotes it, from workflow to storage.

We don’t owe Git our workflow. It was built for a world where typing was the expensive part, and that world is gone.

Be aware of the context window

Tue, 31 Mar 2026 00:00:00 GMT

The context window is the working memory of a coding agent, and the single most underrated reason why long Claude Code sessions drift, forget, and produce worse results over time. This post covers the two mechanisms behind it, auto-compaction and context rot, and the low-effort habits that avoid both.

Disclaimer: This was originally written on March 31, 2026. Things move fast. Depending on when you read it, some parts may already be outdated. Since we have a Claude company license and most of us use Claude Code, this is fairly specific to Claude Code. General concepts like context rot apply just as much to other harnesses and models (Codex, Opencode; GPT, GLM, Kimi).

TL;DR

Keep an eye on the context window → statusline
Try to avoid context compaction
- or be prepared for it → keep state session-external
A 1M context window is no workaround for compaction in long sessions
Context rot: past a certain fill level, results get significantly worse → stay in the sweet spot
Keep the context window small → avoid MCPs, a big CLAUDE.md, big compaction results
Don’t overengineer context management. Just be aware of it.
- Keep sessions small and short.
- Better to start a new session with a longer intro prompt than to stay in one long session.

What is context compaction?

Claude Code operates within a token context window. When the window fills up, Claude Code runs auto-compact: it summarizes the entire conversation history into a compressed form and continues from that summary. It basically keeps the session alive. For details on how Claude Code handles compaction, see the docs.

Unfortunately, in my experience Claude Code’s auto-compaction is bad (especially compared to Codex). After compaction it forgets which files were modified, a plan from plan mode, parts of the todo list… you basically lose the flow. Ever wondered why results get worse during long sessions? That’s one answer.

If you want to stay in a long session, you need to be aware of this and prepare accordingly. Use a session-external structure for planning (e.g. markdown files) that also tracks progress and survives compaction. In my experience, every time I hit compaction in a long-running session, the drift begins and strange behavior starts.

It’s extremely frustrating and unproductive when this happens in the middle of a task, leaving you in a kind of broken state.

Compaction is expensive

The auto-compaction itself eats token usage. It’s hard to measure exactly what drives the cost, but in my early Claude Code days I could clearly see a percentage jump after major compactions. In the end it re-processes your complete history to compact it, and that costs tokens.

On top of the compaction itself, the “where am I?” phase afterwards costs tokens too. The whole gap between “context full” and “next productive step” burns tokens while producing no output at all.

Compaction itself takes context

The result of the compaction gets added to the context, that’s the whole point of the concept. But be aware that this also increases your context usage from the start.

You can see it in this little illustration:

A session before, at, and after auto-compaction. Own illustration.

After compaction you won’t start from 0% (you never do :D), but with roughly 5% additional used context from the compaction result, depending on the session.

How to avoid auto-compaction

Use more new sessions, or /clear
1. Keep tasks short and scoped
2. Personal tip: use a longer intro prompt that explains the rough context of the task: what’s already done, where we are, what’s next, a bit about the environment. Reuse this intro prompt and adjust it for each task.
/compact yourself when you’re in a “compact-safe” state, at logical breakpoints. You can also add a custom focus after the command to tell Claude what to prioritize in the summary.

Context window

This is a topic of its own and would be too much for this post, so I’m leaving out things like MCPs, skills, and subagents.

Before you continue reading: run the /context command in one of your active sessions. It shows exactly how your current session’s context is being used.

You’ve maybe seen or already used the 1M context variants of Opus and Sonnet. Seems like the logical solution to all these problems, right? Right? No!

There are use cases for such a large context, like working with lots of data or single big files (e.g. PDFs) that don’t fit into the normal window at all. But it’s not the solution for auto-compact.

Why? → Context rot.

One additional use case I can think of is avoiding auto-compaction. But then you really need to watch your context usage and manage it manually via /clear or /compact to not run into context rot.

Also good to know: the 1M variants burn through your usage faster beyond the 200k base window. If you’re already struggling with strict limits, avoid them.

What is context rot?

Context rot is a known problem where LLM results significantly worsen once the context fills past a certain level: the model gets measurably worse at using what’s in its window as the window grows.

Maybe you’ve experienced it: you’re in a session, and the results get worse with every prompt. Perhaps you’re in a yelling-loop (a phenomenon where the next most likely answer is wrong, so the user yells again, just like in the last three prompts), or you’ve hit context rot. This graph from Chroma’s context rot research illustrates it well. Newer models are improving here, but it’s still a problem.

Model accuracy against input length on the “Repeated Words” benchmark. Source: Chroma, Context Rot.

Anthropic says Opus 4.6 has significant long-context improvements, but it’s still significantly worse at 1M than at 256k.

It’s hard to call exact numbers or pin down the tipping point for Opus or Sonnet, and I’m not aware of a published Claude-specific threshold. From my own sessions, the ~60% area is a working heuristic, not a measured number.

On the 256k variant, the compaction trigger sits around 85–95% of the context window in the sessions I’ve watched. That leaves enough buffer to wrap up a session and prepare for a new one, or for a compaction.

So if you want better results: try to stay in the sweet spot.

Micro context management

Context management is a whole topic in itself. You might now think you have to be extremely careful not to create too much context, avoid auto-compact at all costs, and so on, just to stay in the sweet spot.

No, it’s not worth the effort. That would only stop you from developing the right mindset for getting good results. Just avoid the big things: lots of MCPs, skills, or a huge CLAUDE.md. It’s setup optimization, not agonizing over context with every single input.

Being aware of the topic is enough.

How to CLAUDE.md

Tue, 31 Mar 2026 00:00:00 GMT

CLAUDE.md (or AGENTS.md, by the way: just symlink them) is the context file coding agents load into every session, and it’s easy to overuse. A recently published study looked directly at this, so I want to share it here so we stay aligned with the latest evidence.

Study: arXiv 2602.11988
Hacker News discussion
Related paper: arXiv 2602.12670
There are also some videos about the topic

TL;DR

AGENTS.md / CLAUDE.md files seem easy to overuse. The study found that developer-written files produced only a modest average improvement (~~+4 percentage points), while LLM-generated /init-style files slightly reduced success (~~−3 points) and increased cost by more than 20%, largely because agents explored, tested, and reasoned more. Agents also tend to follow these instructions quite literally.

What that means in practice

From my personal experience, I can attest to that. Having a detailed AGENTS.md / CLAUDE.md and constantly working on and adjusting it was worse than having a super tight and focused one. The same goes for MCPs and skills.

There are useful ones, like the frontend-design skill from Anthropic itself, but they should be installed very selectively.

Agents are now so good at searching for context on their own (e.g. via Explore subagents) that an overly explicit context file that doesn’t match 100% of the time can mislead them and worsen results. On top of that, a big CLAUDE.md occupies context in every single session, see Be aware of the context window for why that matters.

Since most of us use Claude, we don’t benefit from Codex 5.4’s ability to strongly align with existing patterns in the codebase. So this is more of a model-skill gap than something we’ll need to handle ourselves in the very near future.

Jonas Rohde (@edhor) — Blog

Don't look at unreviewed code

TL;DR

Why you shouldn’t be the first reader

One pass is not a loop

The key move: a different model family

Put it into the prompt

What kind of review

What’s left for you

I'm not the expert, and that's the point

TL;DR

Far away from being the expert

”Then just write it by hand”

What I’m really bad at

Not everything has to be a pull request

We are all over the place

The thing that really pushed me

What to expect here

Orchestrate, don't operate

TL;DR

The trap

Put it in the orchestrator seat

The important part: tell it explicitly

When to skip the layer completely

Why this really cuts the bill

Turn the reasoning up before you turn the model down

TL;DR

Two dials, and everybody only turns one

The concrete case

The worst cell in the grid

So what I do now

Where this flips

Escalating is cheaper than shipping bad work

Steal the idea, not the config

TL;DR

A config is an answer to a question you never asked

Copying is not free, even when the instruction is wrong

Start vanilla, then earn every addition

So what is worth sharing?

The habit nobody has: deleting

If your codebase is good for new-joiners, it's also good for agents

TL;DR

Why it’s the same problem

The frequency is the whole argument

Your new joiner is a measurement instrument

Where the answers go

One effort, two beneficiaries

Maintainable for whom?

TL;DR

What survives

What inverts

The new definition

The adoption experts who won't adopt

TL;DR

The pattern looks really familiar

It’s not about capability

The real one: identity

Treat it as the change project it is

You were never paid for code

We need to get over Git

TL;DR

What Git actually is

Agents broke the assumptions

It’s already happening

I got curious enough to build it

What I actually do today

Be aware of the context window

TL;DR

What is context compaction?

Compaction is expensive

Compaction itself takes context

How to avoid auto-compaction

Context window

What is context rot?

Micro context management

How to CLAUDE.md

TL;DR

What that means in practice