i shipped more. i remembered less.

One June weekend, Anthropic reset everybody's five-hour and weekly Claude limits and told them to enjoy the weekend.

One Reddit response was:

Whaaaaaaaaat?!?! I am supposed to be off this weekend.

Somebody replied:

If I got limits I GOTTA use it.

I laughed, and then felt slightly attacked.

That is embarrassingly close to how I behave. If my Claude limit resets, some unfinished project suddenly looks urgent. If Codex has capacity, perhaps this is the night to refactor something that has worked perfectly well for three years.

That counter was never stable. Anthropic introduced weekly caps after saying that some subscribers ran Claude Code continuously. It later reset subscriber limits after a context-management bug was linked to faster usage drain, tied doubled five-hour limits to new compute deals, and temporarily gave eligible users 50% more weekly usage. Apparently a data-centre deal can now change how much code I write on a Tuesday.

I started with Cursor, used Pi for a while, and now spend most of my time in Claude Code and Codex. I use Claude through an enterprise account at work, pay for the $200 Max plan on my personal laptop, and use Codex with an API key.

I recently went through the retained histories: more than 700 personal Claude sessions, the work sessions that were safe to inspect, Codex runs, child agents, Git history, abandoned branches, and code I deleted shortly after generating it.

My first attempt at writing about it contained all the numbers.

It was accurate. It was also fucking exhausting to read.

The useful part was not the dashboard. It was what kept happening underneath it: I was shipping more while holding less of what I shipped in my head.

1. More tokens did not give me more attention

Before agents, starting a feature was expensive. I had to understand the repository, find the files, hold the architecture in my head, and write enough code to discover whether the idea was stupid.

Now starting is almost free.

I can describe a feature, send one agent into the backend, another into the frontend, and a third to inspect tests. By the time I have made chai, I have a plan, a branch, and sometimes a working implementation.

This removes a bottleneck. It also means I can create unfinished decisions much faster than before.

Every new run needs somebody to remember why it exists, compare it with the other runs, resolve contradictory assumptions, review the result, and decide whether any of it should ship. The agents do not feel the cost of ten half-built ideas sitting around. I do, usually at midnight.

The real capacity limit is no longer how many agents I can start. It is how many results I can still understand well enough to accept.

So I no longer launch work because capacity happens to be available. The little usage counter does not get to run my life. I am still learning this.

2. Agents can finish the wrong thing

One personal session produced a substantial working prototype. The code was there. The main flows worked. The agent considered the task mostly achieved.

My turning-point prompt was:

bro I dont feel I'm building something I believe in

There was no clever technical failure. I just did not want the product anymore. Nothing was committed. Nothing shipped.

In a larger project, I asked agents to move the product towards a hosted control plane. I told them to work autonomously and return when it was done. They implemented, reviewed, fixed, and reviewed again. The session added roughly 49,000 lines.

Then I used the product and realised I wanted the opposite: one interface, open source, no cloud.

The next session deleted more than 40,000 lines.

The agents had not disobeyed me. They had executed my temporary enthusiasm with terrifying competence.

This changed the question I ask after a run. Not “did the agent complete the task?” Not even “did the tests pass?” I ask whether I still want the result after using it and sleeping on it.

Generated code is cheap enough to be a way of thinking. That is useful. But a large pile of working code creates emotional gravity. It feels wasteful to delete, even when it answers the question with “no.”

Deleting it is still engineering.

3. Parallelism multiplies assumptions

My cleanest multi-agent session was an investigation. Four agents inspected different parts of a work system: backend, frontend, services, and API contracts. They only read. The parent session compared the evidence and created the follow-up work.

It was fast, easy to verify, and boring in the best possible way.

My messier sessions gave many agents write access before the shared assumption was solid.

During a large light-theme migration, the work was divided safely across files. There were few overlapping edits and no dramatic merge-conflict disaster. But every worker received the same shallow conversion recipe. They reproduced the same bad assumption across the repository: unreadable accents, broken focus states, and components that looked fine in development but failed in the built product.

File isolation prevented conflicts. It did not prevent coordinated stupidity.

I still use subagents heavily, but the order matters. Parallelise reading, research, and independent review first. Let one owner integrate the evidence. Fan out implementation only after the architectural rule has survived contact with one real slice of the system.

4. A green evaluator can still be bullshit

In one work project, I built an evaluation harness for visual output. Agents generated examples, rendered them, compared results, and assigned grades. It looked like exactly the kind of closed loop agents are supposed to excel at.

The matrix ran. Some comparison controls did nothing, so the inputs changed while the scores barely moved. Most importantly, the evaluator was not measuring whether the output actually looked good.

My assessment in the session was concise:

the testing is fucked up

It was.

An agent is extremely effective when the feedback loop is cheap and honest: a compiler error, a focused test, a reproducible failure, a performance number, or a screenshot that represents the real user experience.

Agents optimise whatever loop we give them. They do not add truth to a broken one.

Now, before launching a large autonomous run, I manually check that the evaluator can distinguish one obviously good result from one obviously broken result. It sounds insultingly basic. So does checking that a smoke alarm reacts to smoke.

I have skipped both kinds of obvious check when excited about the system around them.

5. I remember less code

This is the trade-off I notice every day and cannot extract from a JSONL file.

I remember fewer paths, function names, and file relationships than when I made every edit myself. Writing code used to page the repository into my head. Now I often ask an agent where something lives and receive the answer faster than I could recall it.

That is a loss.

At the same time, I spend more time asking questions one level above the file: should this state belong in the web application or the host? Does the migration work against every real regional state? Is this test measuring visual quality or merely proving that a renderer returned something? Why are there two interfaces? Should this feature exist?

Agents sometimes give me a better systems view because I can interrogate every layer quickly. They also let me avoid understanding a layer until the precise moment that becomes painful.

Both things are true.

Here is one real example from a personal project. I asked Claude to remember a viewer's position in a video. It knew the repository and immediately started putting the state in the video host.

A real exchange

Personal Claude Code session · July 2026

1. Me

   can we add one quick feature quickly .. can we save where the user was at last to may be loca storage or something .. so if the user left midway a video and they come back .. they can start from the same place? .. make sure to handle edge cases well

2. Claude

   This is [an existing issue] — and the restructure just made it cheap: we own the shipped host now ([host entry]), so resume lives in the host itself (same-origin localStorage on the scenes origin, direct video-element access). No [player] change, no [web-app] change, immune to the [message-channel issue] postMessage drops, and it ships to every lesson via one runtime publish + pointer flip. Building it inline now. Read the current host-entry first:

3. Me

   what .. shouldnt this be controlled by apps/web ?

4. Claude

   Done: - Code reverted — [resume file] deleted, [host entry] back to committed state, tree clean - Design recorded on [the existing resume issue]: the three candidate homes (host / web app / player), why web app is the right owner, the [message-channel] dependency blocking it, and the worked-out edge cases (save floor, resume window, duration-drift invalidation, max age, versioned schema) so none of today's thinking is lost [The resume issue] now depends on [the message-channel fix] — do that first when you pick this up.

Claude had more repository detail in its answer than I had in my question. It knew the delivery path, the browser boundary, and the failure mode in the existing message channel. It was still about to put product state in the wrong owner.

I did not catch that by remembering a filename. I caught it by asking one systems question. That is the trade-off in miniature: the agent carried the map; I had to notice it was driving in the wrong direction.

The part that worries me most is learning. Years ago, I chose Go for an internship assignment even though I had never used it. Struggling through the implementation under a deadline taught me things that no generated explanation would have. If a current agent had completed it in ten minutes, I would have delivered faster and learned less.

I do not think we should preserve boilerplate as a sacred ritual. But some friction is education. If agents remove it, we need to deliberately replace it with something better than watching a diff scroll past.

What I do now

My workflow is still changing, but these rules have held up:

• Send multiple agents to gather evidence; keep one owner responsible for integration.
• Test an architectural rule on one real slice before fanning it across a repository.
• Prefer feedback loops that exercise the result where a user will experience it.
• Check that the evaluator can recognise an obviously broken result before trusting its score.
• End the run when the product goal changes, and delete its output without mourning the tokens.

Where I landed

I still read code. Sometimes I write it. I use Claude and Codex every day, and I am not going back. Agents have helped me ship more, attempt systems I would not have attempted, and understand unfamiliar code much faster.

They have also helped me produce software that should not exist, scale bad assumptions cleanly, trust meaningless green checks, and forget parts of repositories I technically own.

I do not think programming has ended. I think implementation became cheaper than deciding what deserves to be implemented.

The agent can keep going. My job is knowing when it should not.