If I could send a few notes back to a younger me, none of them would be technical.

Own the work

Take responsibility for the work in front of you, and do it well. Over years, the single largest leverage you have in any job is that you can be relied on. That sounds boring. The compounding advantages usually are.

Be nice to everyone. Not as a strategy. Not because it pays off. Because the alternative is exhausting, and most of the people around you are doing harder work than you can see.

Take feedback seriously, without taking it personally. Junior engineers do one of two things with feedback: dismiss it as wrong, or absorb it as identity damage. Both are expensive. The skill is separating the signal from the sting — pulling out what is true and discarding the rest, including the parts that hurt for reasons that have nothing to do with the work.

Before asking someone for help, do the work yourself first. The exception is a deadline at risk — then ask early, not late. Outside of that, the struggle *is* the work — not the friction of being stuck, but the act of forming your own model of the problem before someone else hands you theirs. Skip that and you skip the thing you are actually paid to learn.

Serve the organization

The job is not to be a good engineer. It is to help the organization move forward. The two are correlated, but not the same thing.

That means asking the questions other people are not asking. Understanding what the product is for, who pays for it, where it is going. Pushing on decisions that look suspect even when they sit above your level. Plenty of capable engineers spend years optimizing their craft and never wonder whether the work is the right work for the company.

This is also why job-hopping every twelve months is expensive. The first year you learn where the bathrooms are. The second year, the system actually becomes legible — you start to see the joints, the politics, the parts that are real and the parts that are scaffolding. That legibility is when your judgment becomes useful. Leave at month thirteen and you burn the investment just before it pays. There are exceptions — a company unraveling, a role that was misrepresented, a manager you cannot work for — but make sure the reason is real, not a restless year mistaken for a broken job.

Stay long enough to be useful in a way only someone who has been there can be.

Pick the right thing

Most engineers I have watched fail were not unskilled. They were busy doing impressive work on the wrong thing.

Ask yourself, repeatedly: is this where my time should be right now? The question is uncomfortable, because an honest answer often invalidates the last week of effort. Ask it anyway.

The same restraint applies to the code itself. Solve the problem you have, not the one you might have at a hundred thousand users you will never reach. Over-engineering is not an architectural sin — it is an attention tax. Every hour spent hardening the wrong code is an hour not spent on what matters now.

Ship small, then iterate. A series of small changes beats one big release. Smaller diffs are easier to review, faster to revert, and quicker to expose a wrong assumption. The instinct to ship one big polished thing often hides a fear of being seen mid-thought — but even when the motive is pure, the mechanics still favor small.

And resist dogma. DDD is not the answer. Neither is TDD. Neither is the framework you read about last week. None of them survives contact with every problem. Each was forged in a specific context and breaks the moment you carry it somewhere else. The job is to pick the right tool for the work in front of you — language, framework, architecture, design. People who hold one methodology tightly have mistaken their preference for a principle.

Build your leverage

Invest in AI, then put in the reps. A cheap subscription gets you curiosity, not fluency. The judgment for when a model will handle a task cleanly, when it will bluff, when to push back, when to switch — that comes from volume. Pay for the better plan and use it until the tools stop feeling mystical. Calibrated intuition is the goal — knowing, without thinking about it, what these tools are good and bad at. You get there only by working at the frontier long enough that it stops feeling like the frontier.

Then use AI as a tutor, not a vending machine. Before writing code, talk to the model. Ask it to walk you through the codebase in your own language. Have it explain a component the way a patient senior engineer would, calibrated to what you already know. The real unfair advantage is not the code it generates — it is the synthesis it produces for you specifically. Engineers who use AI well are not the ones who type fastest. They are the ones who understand the systems they touch.

Then sharpen your environment. Engineers waste astonishing amounts of time fighting their tools — switching windows, hunting for the same command, breaking flow to look up syntax. Spend a couple of days getting your editor, shell, and daily workflow exactly how you want them. The setup feels indulgent. It pays back every working day for years.

The shortcut is the trap

None of this is clever. None of it is a hack. That is the point. The shortcuts do not compound — the unglamorous habits do.

Younger me would have skimmed this looking for the trick. There isn’t one.

You spend an hour on a design with an agent. By turn fifteen it has internalized your framing and now defends, as obvious, the choices you made in turn three. When you ask that same thread to review the work, it reviews against assumptions it shares with you. The pushback you get is the pushback of a colleague who was in the room the whole time.

That is not pushback. It is agreement with extra steps.

A reviewer that shares your context shares your bias

Most people respond by pressing harder. *Tell me what’s wrong. What are my blind spots? Push back.* The agent obliges, produces three plausible critiques, and the conversation moves on. The critiques sound right because they are bound by the same frame as the work.

You cannot ask the thread that built the thing to challenge the thing. The framing is in the air.

The fix is structural. No prompt rewording will save you. Launch a subagent — a fresh context with no history of how you got here. Hand it the artifact and ask what breaks. It reads cold. It has no turn-three commitment to defend.

Three things bias a reviewer: the conversation it just had with you, its training, and the artifact itself. The fresh subagent fixes the first. It still flatters by default. It still inherits whatever frame the artifact encodes. This technique moves the bias you can move; the rest stays.

Hand over the artifact, not your interpretation

This is where the technique fails for most people.

The temptation is to brief the subagent the way you would brief a teammate. *We decided to do X because of Y, and I’m worried about Z — what do you think?* Now the subagent inherits your frame. The clean context is wasted: the prompt itself is the laundered version of your bias. You have built a second room and walked in carrying the same furniture.

The discipline is to hand over the artifact and let it speak for itself. *Read this design. What breaks?* Strip the summary, the decision history, the preview of what you fear. Let the subagent encounter the work the way a reviewer would on a Friday afternoon — with only the artifact, and no clue what you wanted to hear.

What comes back is sometimes useless. Sometimes it surfaces a flaw you would have hunted for two days. The signal is highest when you do not preload the answer.

Cold reading has its own failure mode. The subagent will sometimes flag an issue you settled in turn five — a deliberate trade-off it cannot see and reads as a bug. The cost is a minute of triage, not a wrong fix. Brief it only when the artifact cannot stand alone: a design that omits its constraints, code that depends on conventions nowhere written down. Default to letting it read cold and discarding the false positives.

Adversarial review, by default

After a long thinking session, senior engineers used to pull a teammate over for a sanity check. The cost was a colleague’s interruption, and that cost made sanity checks rare — reserved for the work that mattered most.

That cost is gone. Spawn a fresh agent. Hand it the artifact. Ask what breaks. Do this every time the work matters — not because the agent is smarter than you, but because it has not spent the last hour nodding along.

A reviewer in your thread shares the blind spots you built together. A reviewer in another context does not.

Then the windows grew. A million tokens now. More soon. The constraint is gone, and the temptation is to fill the space: pour the whole task in, every file, every ticket, every stray thought, and let the agent sort it out.

The discipline should stay.

A long session degrades in ways more context cannot repair. The agent picks up false constraints from earlier turns. It rationalizes around a mistake it made in turn three. Decisions made for one slice bleed into slices where they do not belong. You can watch it happen: the agent quotes its own earlier wrong assumption back at you in turn nine as if it were a requirement. The transcript becomes a thicket the agent must carry but cannot prune.

A session is a function

A session has inputs, a scope, and an output. The discipline you apply to a function — one responsibility, narrow interface, verifiable result — applies here. Cram three responsibilities into one session and you get what a thousand-line function gives you: hidden coupling, surprising side effects, untestable behavior.

Engineers do not write the whole system in one function. They do not write the whole feature in one PR when they can avoid it. The same instinct should govern how you scope an agent’s work. If two parts can be done independently, give them to two agents. If one part must finish before the other can start, that is a sequence, not a single session.

The groundwork is its own thread

Some work has true shared groundwork. A schema migration before two features that both depend on the new fields. A refactor that lifts a common abstraction before three callers can use it. Do that work first, in its own session, and capture the result — a merged PR, a written summary, a pinned doc.

The dependent work runs in fresh threads with the groundwork as input, not as conversation history. The context they need is the artifact, not the journey that produced it.

Chunk like an engineer

A senior engineer, given a feature, breaks it into pieces a junior could pick up cold. Each piece has a clear input, a clear output, and a way to verify it. The pieces fit together — in parallel, in sequence, or both — but each one stands on its own.

Apply that to agents. Before starting a session, ask: what is the smallest piece of work that produces something verifiable? That piece is the session. The next piece is another session, started fresh, with whatever the first produced as input.

This sounds like overhead. The overhead is the long session you debug, restart, and re-explain because something went sideways in turn ten. Small threads fail small. Big threads fail expensively.

A bigger window is a capacity, not an instruction. Use it when more is unavoidable. More is not better.

Scope the thread. Capture the output. Start fresh.

Teams built entire disciplines around that fear. PRDs, design reviews, estimation, planning poker — every ceremony existed to prevent expensive work from producing something nobody wanted. The instinct was rational. But the economics that justified it have changed. An agent builds in an afternoon what once took a week. Specification and decision-making now take longer than the code they describe.

Once building gets fast, the old instincts misfire. You debate an approach for two days that a prototype would answer in two hours. You write a PRD for a feature that a working demo would describe more precisely.

Try it

The fastest way to be right about something is to try it.

That sentence used to be an aspiration. Building an MVP still took a team, a quarter, a roadmap. The unit of experimentation was a whole product.

Now the unit of experimentation is an afternoon. You build two versions of a UI and look at them side by side. You spike an architecture, see that it breaks, and spike a different one — all in the time a meeting would take to schedule.

The discipline

When the direction is unclear, build more than one answer.

Not as a thought experiment. Not as a whiteboard diagram. Working code, end to end, that you can run and touch. Two or three versions. Then pick.

This sounds wasteful. The old instinct treats all code as expensive: three implementations means three times the cost. That was true. Two of the three will be thrown away — that is the point. They were fast to make, and their job was never to ship. Their job was to teach you which one should.

The real cost is not building three things. It is evaluating them. You have to understand each version well enough to compare. That takes attention. But attention spent comparing working code is more productive than attention spent debating abstractions. One produces evidence; the other produces consensus.

Most teams spec one approach, commit to it, and rationalize afterward. The waste is invisible because nothing was thrown away. The team built the wrong thing once instead of the right thing after two quick tries. The first outcome feels cheaper. It almost never is.

Wear the experimentation hat

Exploration is a posture, not a phase.

The team that gets this right does not run a “discovery sprint” followed by a “build sprint.” They wear the experimentation hat by default. Every ambiguous decision becomes a prototype instead of a debate. Every strong opinion gets verified fast, so opinions carry less weight than evidence.

That posture changes what seniority looks like. The old senior engineer predicted which approach would work. Their value was taste built over years of expensive mistakes. That taste still matters — a prototype answers whether something works mechanically, not whether it belongs architecturally.

But the leverage has shifted. The senior engineer who leans in builds three, tests three, and keeps the one that works. The one who resists still gets the right answer sometimes. The difference is that the prototyping team learns something new every afternoon, while the tasteful team mostly confirms what it already believed.

Keep the lesson, not the code

The hardest part is throwing work away.

When code was expensive, working code was too valuable to discard. You shipped what you built because building it had cost too much to abandon. That sunk-cost reflex persists. Teams protect prototypes — extend them, ship them, pretend they were meant to be real all along. The prototype becomes the product. Exploration collapses back into commitment.

Resist that. A prototype is a question you ask the codebase. Once you have the answer, the prototype has done its job. Keep the lesson, not the code. The real implementation should be written cleanly, with the benefit of everything the prototypes taught you. Sometimes the best prototype is already clean enough to ship. Often it is not. Either way, the decision is easier when you have seen the alternatives.

The scarce resource is no longer code. It is clarity about what to build. Prototypes buy clarity. The clarity is what you keep.

The new default

For years, the best advice was plan carefully before you build. The cost of the wrong answer was too high to skip the planning.

That advice no longer holds.

Plan less. Build more. When two approaches seem plausible, try both. When a feature feels uncertain, prove it with a working thing you can touch.

Build three. Keep one. Throw the rest away.

That ratio has flipped.

The bottleneck moved

An agent produces a candidate change in minutes. The review queue becomes the constraint. A single developer with agents can generate changes faster than reviewers can meaningfully evaluate them. The backlog grows. Context-switching multiplies. Reviewers skim because the volume makes careful reading impossible.

This is a structural problem, not a discipline one. Code review assumed writing was slow and reviewing was fast relative to writing. The opposite is now true. Writing is nearly instant; reviewing still takes the same human time it always did.

You cannot hire enough reviewers to match the pace of agents. You cannot speed up reviewers without gutting the review. Throttling agents uniformly defeats the purpose — but not all changes carry equal risk.

What review actually provided

Before killing the pull request, understand what it gave us.

Code review served four purposes: catching bugs, enforcing style, sharing knowledge, and maintaining quality standards.

Catching bugs is better handled by tests — but only if the tests themselves are trustworthy. A test suite that runs on every commit is more thorough, more consistent, and faster than a human scanning a diff. The risk is that when the agent writes both tests and implementation, it can share the same blind spots across both. TDD ordering — test first, watch it fail, then implement — ensures the test is not vacuous, but it does not ensure the test matches the actual requirement. That gap is why the specification matters more than the diff. A human-written spec, precise enough that test correctness becomes verifiable, is where human attention belongs. The agent proves correctness; the harness verifies the proof is honest — through coverage thresholds, mutation testing, or property-based tests that generate cases the agent did not anticipate.

Enforcing style is partly automated. Linters, formatters, and static analysis handle syntactic style without a human. Architectural consistency — API design, abstraction choices, pattern adherence — is harder to automate and falls under quality standards.

Sharing knowledge is the most underrated purpose. Pull requests are often the only way teams stay aware of what is changing. Kill the PR without replacing that signal and developers lose track of the codebase fast — especially when agents churn out changes at volume. The replacement must be concrete: an auto-generated changelog from merged commits, a notable-changes channel, a daily digest. Something that arrives without anyone asking for it.

That leaves quality standards — the judgment calls. Does this change belong? Is this the right approach? Does it add complexity we will regret? Human attention still matters here. But it need not happen on every change.

Auto-merge by default, human review by exception

The alternative is simple. A change that passes the test suite, type checks, linting, and whatever other automated verification you trust merges and deploys. No pull request. No reviewer. No queue.

A change that touches a critical path — payment processing, authentication, database migrations, core abstractions — pulls in a human automatically. Not because a colleague chose to request a review, but because the system knows which paths demand human judgment.

Defining the critical path requires mapping not just files but dependency chains — a change to a shared utility can affect payments indirectly. The boundary will be wrong sometimes, and changes that should have been reviewed will slip through. That is acceptable if the layered defenses catch the failures quickly. The question is not whether the boundary is perfect but whether the cost of occasional misclassification is lower than the cost of reviewing everything. For most teams, it is.

We already trust automation in constrained domains — CI pipelines, auto-scaling, infrastructure provisioning. Those systems operate within pre-reviewed boundaries. The challenge here is defining boundaries tight enough to make auto-merge safe for novel code changes.

The changes you did not tag

The honest objection concerns the change nobody expected to be dangerous. A config tweak that breaks production. A refactor that subtly shifts behavior. A dependency update that introduces a vulnerability.

Pull requests caught some of these — but inconsistently, and at a cost that scales poorly when change volume increases by an order of magnitude. The question is not whether review has value, but whether that value justifies the bottleneck when alternatives exist.

The real defense is layered. Automated config validation, canary deployments, real-time alerting, fast rollbacks. No single layer is perfect, but the combination covers the same ground more reliably. A reviewer might notice a dangerous config value once in ten times. A validation rule catches it every time.

Acknowledge the limits: not everything rolls back cleanly. Database migrations mutate state. External API contracts change. These belong on the critical path list alongside payments and auth — not because a human will catch every problem, but because an unreviewed mistake here costs too much.

The real objection

The objection is rarely about bugs. It is about trust.

The natural counter: fix review culture, do not kill the mechanism. Make reviews more thorough. But more thorough at what? If the answer is catching bugs and enforcing style, that is work machines already do better. The reviews worth keeping are the ones no machine can replace: is this the right architecture? Is the product heading in the right direction? Is this system decoupled enough to change later? Those deserve human attention. The rest does not.

Humans should plan. They should decide what the product becomes, why a user would care, and what problem the team solves next. They should write the specifications that make agent output verifiable — not scan diffs for off-by-one errors. The pull request, as it exists today, puts the reviewer in the wrong seat: reading implementation details instead of shaping direction.

Some teams face compliance constraints. Regulated industries require documented approval as an audit trail. That is a real constraint, not theater. For those teams, the immediate goal is narrowing approval to what regulators actually require. Longer term, automated verification with immutable audit logs may satisfy the same regulatory intent. The pull request is not the only way to prove a change was vetted.

For everyone else, trust should come from the system, not from a ritual. Build the system that deserves trust, and the ritual becomes unnecessary.

Better, not just faster

Speed is the obvious gain. Code in minutes instead of days. Iterations in seconds instead of hours. But speed alone is the wrong goal. Faster bad code is still bad code.

The pull request never made code better. It made code reviewed. A tired reviewer approving a mediocre diff did not raise the bar — it just added a stamp. The real opportunity is not to ship the same quality faster. It is to ship higher quality at the same pace agents already move.

That means investing the time the review queue used to consume. Write better specifications so agents produce cleaner first drafts. Build stricter test harnesses so regressions die before they merge. Define the standards — naming, structure, error handling — so agents follow them by default. The discipline shifts from inspecting output to defining what good looks like.

Kill the pull request. Invest in verification. Tag the critical paths. Let the agents ship better code, and let the humans shape what gets built.

That coupling is gone.

An agent produces in minutes what a developer once needed days to write. It writes correct code, passes the tests, ships. But the developer who triggered the task understands that code no better than if a stranger had written it. The codebase grew. The team’s comprehension did not.

This is cognitive debt. Not technical debt—the code works. Cognitive debt is the widening gap between what your system does and what your team understands about how it does it.

Technical debt has a sibling

Technical debt is familiar. You cut a corner, you know you cut it, you plan to fix it later. The debt is visible.

Cognitive debt is invisible. The code works. Nothing looks wrong. But nobody on the team can explain why the service handles retries the way it does, or what happens when the cache layer fails. The system is correct and opaque.

Cognitive debt is worse than technical debt: you discover it only when you need the understanding you lack. A production incident hits a module an agent built three months ago. Nobody remembers the design—it passed CI and shipped. Now you are debugging a system you do not understand, under pressure, with no working picture to guide you.

Technical debt slows you down. Cognitive debt leaves you lost.

The compounding problem

Cognitive debt compounds faster than technical debt.

Every module an agent builds that you do not understand makes your next decision worse. Not because the code is bad—because your mental model of the system is incomplete. You approve an architectural choice that conflicts with a service an agent built last month. You make integration decisions from an understanding that is months out of date.

When humans built every module, they understood it. The team’s collective understanding stayed current with the codebase. At agent speed, the codebase outruns your mental model within weeks. Catching up means reading code you did not write, for a design you did not choose. Most teams will not do it. The debt accumulates in silence.

Existing tools fall short

Code review shares knowledge, but it was built for human-speed delivery. When agents produce changes faster than reviewers can read them, review becomes a bottleneck or a rubber stamp.

Documentation is always stale. It is worse now because the rate of change has accelerated while documentation habits stayed frozen.

Tests prove behavior, not understanding. A passing test suite does not tell you why the system works, how the pieces connect, or what assumptions underpin the design. Full test coverage and full cognitive debt coexist easily.

AI-generated summaries help, but only at the surface. An agent can walk you through a module, answer questions, diagram dependencies. That aids comprehension. It does not aid navigation. When a production incident strikes, the problem is rarely “I cannot understand this code.” The problem is “I do not know which of forty services to look at first.” You can ask an agent to explain a module, but you cannot ask it which of three modules you have never read is causing your outage. The navigational problem precedes the explanatory one.

If full comprehension is impossible, the question becomes: what replaces it?

Nobody knows every street

You will not solve cognitive debt by understanding everything. Not at agent speed. The volume is too high, the rate of change too fast.

Think about a city. Nobody knows every street—not the mayor, not the taxi drivers, not the lifelong residents. But cities work. People navigate them every day, not because they memorized the layout, but because cities are navigable. Street signs, grid systems, neighborhoods with distinct character.

Your codebase must become a city, not a maze. A maze is complex and unsigned—you navigate it only by memorizing the path. A city is complex and signed everywhere. The complexity remains, but it is legible. Most codebases built at agent speed will become mazes by default, because agents build for correctness, not human navigation.

Making the codebase navigable

Forget full comprehension. Navigability becomes the goal—making a system findable and orientable for a human who did not build it and lacks time to read all of it.

Explicit architecture. A top-level document describes the major components, their responsibilities, and how they connect. Each component carries its own doc: the data model it owns, the contracts it exposes, the assumptions it depends on. When an agent adds a service, someone updates both layers. Without them, every exploration starts from scratch.

Consistent patterns and clear boundaries. When every service handles errors, retries, and logging the same way, a developer who understands one service can reason about all of them. Pair that consistency with explicit module interfaces, and you get a neighborhood structure: you need not know the whole city, just the block you are working on and where it connects. Agents follow patterns well when told to. Enforce them.

Decision records. When someone makes a significant design choice—human or agent—write down what was chosen and why. Not a novel. A paragraph. Not in a wiki. Not in a Slack thread. In the repo, next to the code it affects. This history lets future developers understand intent, not just implementation.

Orientation before implementation. Before building, read. Before an agent writes a feature, trace the relevant paths in the system. Not to review the code—to build the understanding that makes future decisions sound. Five minutes of orientation saves hours of debugging.

The discipline is new

Technical debt has decades of shared language—linters, refactoring sprints, architecture reviews. Cognitive debt has none. Most teams feel the symptoms—slow debugging, bad decisions, fragile changes—but never name the cause.

Name it. Then build a city, not a maze.

So teams cut corners. They shipped the quick version because the right version cost too much. They hardcoded the config, skipped the validation, duplicated the logic, and wrote a TODO. Not because they wanted to — because the alternative was missing the deadline. The tradeoff was real: ship now with debt, or ship later with quality. Every team chose ship. This applied most directly to implementation-level debt — code quality, test coverage, validation, naming — the kind that accumulates line by line under deadline pressure.

That tradeoff no longer exists.

The price of good code collapsed

An AI agent writes the clean version as fast as the messy version. The proper abstraction costs the same as the shortcut — minutes, not days. Ask an agent for a well-structured service with proper error handling, clear interfaces, and comprehensive tests. It delivers. Ask it for a quick hack. It delivers that too, just as fast. Agents still need review and still make mistakes — but a clean first draft that needs minor correction is a different problem than a mess that needs a rewrite.

When the clean solution and the shortcut cost the same, choosing the shortcut is not pragmatism. It is habit.

Teams still carry the old instinct. Decades of expensive code trained the instinct to cut corners. Developers learned that “do it right” meant “do it slow.” That association runs deep. But the underlying economics have changed, and the instinct has not caught up.

The old excuses

Every excuse for technical debt traces back to the same root: we did not have time.

We did not have time to write the abstraction. We did not have time to add the validation. We did not have time to write the tests. We shipped what worked and promised to come back later. We rarely came back.

Time was the constraint, and cutting corners was the release valve. Remove the constraint and the valve is useless.

An agent does not get tired on a Friday afternoon and skip the edge cases. It does not get bored writing the third integration test. It does not decide that “good enough” is good enough because the sprint ends tomorrow. It applies the same rigor to the last test as the first. The discipline failures that created technical debt were human failures rooted in fatigue, boredom, and deadlines. The constraints are gone.

What remains

Not all technical debt came from time pressure. Some came from ignorance — the team did not know the right approach when they built it. Some came from changing requirements — the right approach last year is the wrong approach now. Some came from dependencies — a library forced an awkward integration.

These sources still exist. An agent cannot solve a problem the team has not yet understood. It cannot predict next year’s requirements. It cannot fix a bad dependency API.

But these are qualitatively different from time-pressure debt and require different solutions — better discovery, better planning, better vendor choices. Most technical debt, in most codebases, is the accumulated residue of a simple calculation: we could not afford the right solution at the time. That calculation no longer holds.

The new standard

If good code is cheap, the standard changes. Technical debt stops being the cost of shipping and becomes a choice — a bad one.

This means teams need to stop treating debt as normal. Stop planning “tech debt sprints” to clean up messes that agents could have avoided. Stop accepting PRs that take shortcuts when the shortcut saves no time.

The conversation shifts from “when will we pay down the debt?” to “why did we take on debt at all?”

The discipline is different now

The old discipline was prioritization. Which debt do we pay down first? How much time do we allocate? What is the interest rate on this shortcut?

The new discipline is specification. Tell the agent what good looks like. Define the patterns. Enforce the standards. Make the right way the default way, and agents will follow it consistently.

This is easier and cheaper than paying down debt. Instead of writing clean code yourself — which is what made it expensive — you describe what clean means and the agent writes it. The cost of quality shifted from execution to definition.

Teams that still accumulate technical debt in 2026 are not under pressure. They are under-specified. They left “good” undefined, so the agents produce whatever works. The debt is not a tradeoff — it is a configuration error.

The irony

For decades, the industry built tools, processes, and entire careers around managing technical debt. Linters to catch it. Refactoring tools to fix it. Sprint ceremonies to prioritize it.

Now the same technology that made code cheap enough to write well makes most of those tools obsolete. You do not need a tech debt sprint if you never take on the debt. You do not need a refactoring tool if the agent writes it clean the first time.

The irony: AI agents kill technical debt not by paying it down but by making it pointless to accumulate.

Good code used to be a luxury. Now it is the default — if you ask for it.

Ask for it.

The instinct comes from a reasonable place. You want the session to go well. You want to avoid wasted work. So you front-load specification. But the problem is the same one that sank waterfall in teams: you cannot specify what you do not yet understand. A plan written before you have touched the code is a guess dressed as a decision. It feels productive. It is often wrong.

Planning is not the problem

Planning itself is fine. Boris Cherny, one of the creators of Claude Code, starts most sessions in plan mode:

and iterates on the plan until he likes it. That works because he treats the plan as a conversation, not a contract. His tasks are pull-request-sized features with known scope. The plan aligns direction. Then he moves.

The problem starts when planning becomes a default for every session. When you reach for plan mode before a bug fix, before a spike, before an exploration — before you even know what the task demands. That is not discipline. That is comfort. You are writing a PRD because it feels productive, not because the task needs one.

Match the workflow to the task

Not every task needs the same starting point.

If you are building a feature with clear scope — a new API endpoint, a settings page, a migration — plan mode earns its keep. You know roughly what the result looks like. A brief plan aligns direction before the work begins.

If you are fixing a bug where the behavior is already clear, a plan is overhead. A failing test is a better starting point. Pin the contract, confirm the failure, then fix it. I wrote about this approach recently: make the test fail first, then make the narrowest change that turns it green.

If you are exploring — spiking an idea, trying a library, feeling out an architecture — you do not know enough to plan. Start coding. Let the shape emerge. Planning an exploration is a contradiction.

The session is a conversation

The deeper issue is how you think about the session itself.

Plan mode tempts you into a handoff mentality: specify, then execute. But the best sessions are not handoffs. They are conversations. You start with a direction, the model makes something, you react, it adjusts, you push further. The work improves because both sides contribute judgment along the way.

That is the agile insight applied to a different scale. You do not need a two-week sprint to benefit from iteration. A thirty-minute session works the same way. Start with enough direction to move. Adjust as you learn. Trust that course correction is cheaper than perfect specification.

Pick the right tool

Plan mode is a tool. Red-green TDD is a tool. Freeform exploration is a tool. The mistake is picking one and applying it everywhere.

Plan when the scope is known. Test-first when the contract is clear. Explore when it is not. And in every case, stay in the loop. The session is not a spec you hand off. It is a conversation you steer.

Then the trial ended. The app locked me out. Not “you can still read what you saved, but you need to upgrade to add more.” Locked out entirely. My data, behind a paywall, with no warning that the clock had been running.

I did not pay. I opened my editor and started building a replacement.

The reflex that changed

Two years ago, that impulse would have been a fantasy. Building a read-later app from scratch meant weeks of work: storage, syncing, parsing, a decent interface. The rational move was to pay, grumble, and move on.

Now the rational move is different. With an AI agent and a weekend, I had a working app. It did exactly what I needed, nothing more. No pricing tiers, no dark patterns, no trial clock ticking in the background. Mine.

That is the shift. The cost of building a simple tool for yourself has collapsed. What used to take weeks takes hours. What used to require a team requires one person with a clear idea and good tools.

The subscription trap loses its leverage

Subscription software depends on a gap between what users want and what they can build. The wider the gap, the more leverage the vendor holds. You pay monthly because the alternative—building it yourself—is too expensive, too slow, or too hard.

That gap is closing fast.

When building a basic replacement takes a day, the threat changes direction. The vendor no longer holds your data hostage. You hold the option to leave. Not in theory—users could always leave in theory. In practice, with current tools, they actually can.

Some subscriptions will survive. Some products carry genuine ongoing costs: server infrastructure, real-time data, large-scale collaboration. A monthly price makes sense when the service costs money to run every month. But most subscription software is not infrastructure. Most of it is static functionality repackaged as a recurring charge—a tax on the gap between wanting and building.

That tax just got much harder to collect.

Software feels free again

For a long time, software felt like something imposed on you.

You picked from the options available, accepted the pricing, tolerated the dark patterns, and worked around the limitations. If the vendor changed the terms, you adapted or left. That was the relationship: you rented, they decided.

Once you know you can build, that posture changes.

You open a new app and notice the pricing page before the features. You calculate how long it would take to build the parts you actually need. The question shifts from “can I afford this?” to “does this earn my use over what I would build myself?” That makes you a peer, not a captive.

Software stops feeling like renting and starts feeling like making. You run into a problem and reach for your editor before you reach for the App Store. If someone already built it well, you pay for the craft. If not, you build your own. Either way, the choice is yours.

Software feels free again. Not free as in price. Free as in agency. Free as in unlocked.

What is left to sell

If anyone can build a basic version, what justifies charging others?

The answer is polish. When you build for yourself, you solve your own problem. You skip the edge cases that do not affect you, ignore the platforms you do not use, and tolerate rough spots you understand. That is fine for a personal tool. It is not enough for a product.

A product means someone else solved the edge cases, tested on devices you do not own, and made it reliable for people whose workflows differ from yours. That work has real value. It deserves to be paid for.

But it deserves to be paid for once. Polish has ongoing costs—platform updates, security patches, new devices. But the same shift that collapsed build costs collapsed maintenance costs too. A one-time payment—the price of a couple of coffees—is a fair exchange for someone else’s craft. It says: I could build this myself, but you already did, and you did it well. That is worth a few dollars.

A monthly subscription that holds your data hostage says something different. It says: you need me, and I intend to keep collecting.

The new deal

The old deal was simple: you pay monthly because you cannot build it yourself. The new deal is simpler: you pay once for craft, or you build your own.

One-time payments for polished tools. Subscriptions only where there is genuine ongoing cost. Everything else, build it yourself. Not every case is clear-cut. But when you can build the alternative, the vendor has to earn each month. The tools are good enough. The time is short enough. The ceiling on what one person can attempt has moved.

That is where software is heading. Not back to some nostalgic era of shareware and hobbyist code. Forward, to a place where building is cheap, agency is real, and the subscription trap has lost the only leverage it ever had.

Reps build judgment

Heavy AI use gives you something harder to describe than a prompt library: a feel for the system.

You learn when a model will handle a task cleanly and when it will bluff, how much context it can carry, when a vague instruction is fine, when the task needs tighter scaffolding, when to retry, when to switch models, and when to stop. After enough use, you can often predict the shape of the reply before it arrives.

That judgment does not come from benchmarks or one impressive demo. It comes from volume. You get it by pushing models into real work, watching them fail, trying again, and seeing enough patterns that they stop feeling mystical. They become legible. That is how trust forms. Not blind trust. Working trust.

Volume costs money

This is the part I underestimated.

A cheap plan, even with some work usage on top, is enough to keep you curious. It is not enough to make you fluent.

Fluency requires more usage than most people admit. You need long sessions, failed attempts, exploration, side projects, repeated prompting, and enough room to compare approaches until you understand why one worked and another did not.

That is where the more expensive plans stop looking indulgent. They start looking like the price of serious practice.

Cheap models are useful. Open models matter. But if you want tacit knowledge of what frontier AI can actually do, you have to spend real time at the frontier. Otherwise, you build your intuitions around the limitations of weaker systems and mistake that for realism.

A rare moment to lean in

This is also an extraordinary moment to be alive and to build.

I do not mean that in a childish sense. It is simply rare to live through a tooling shift that expands what one motivated person can attempt this much. You can prototype faster, explore more directions, and try projects that would have been too tedious or too lonely to begin a few years ago. The tools are uneven. They still fail in stupid ways. The larger fact remains: the ceiling has moved.

That is why I think engineers who can afford serious usage should stop treating it as optional software spend. This is not a moral argument, and it is not aimed at people who genuinely cannot afford a higher subscription. It is aimed at people who can afford it and still file it under “nice to have.”

For many engineers, a high-usage frontier subscription is one of the best career investments available right now. Not because paying more is virtuous, but because the return is not only output. It is speed, instinct, ambition, and better judgment.

I understood the theory. I still preferred to write the code first, handle the edge cases, and add tests around what I had built. When implementation was the slow part, that order felt natural. The hard work was getting the code onto the page.

Working with agents changed that.

Now an implementation can appear in seconds. The expensive step is no longer producing code. It is deciding whether the result deserves to stay. That changes the job of the test. I no longer think of test-first as a ritual for disciplined programmers. I think of it as a way to pin the contract before the implementation starts drifting.

That is why red-green TDD feels useful to me again.

Make red specific

If you already know the behavior you want, start by making the failure concrete.

Suppose your billing job should skip paused subscriptions, but a paused account is still getting an invoice. A vague prompt would say, `Fix billing for paused subscriptions.` A better prompt would say, `Write a test that proves a paused subscription is invoiced by the monthly job. Run it. Confirm that it fails for the expected reason. Then make the narrowest correct change that makes it pass.`

That difference matters. The first prompt asks the agent to guess. The second asks it to establish a contract.

The test must fail, and it must fail for the right reason. That means the agent has to run it before touching the implementation. If it passes immediately, you have learned something important: the bug report is wrong, the fixture is wrong, or the test never touched the path you care about. If it fails because a seed script broke or a factory cannot build the record, you still do not have the contract. Fix the setup first.

This part is easy to skip, especially with fast code generation. A model can write a plausible test file and jump straight into the change. That is exactly what you do not want. Until the agent has executed the test and seen the right failure, it is still working from a story, not from evidence.

Red is not paperwork. Red is the moment when the expected behavior stops being prose and becomes something the codebase can reject.

Then make green small

Once the failure is real, the implementation gets simpler.

Now the agent is no longer coding against a paragraph. It is coding against an executable example. That narrows the solution space. It also makes wrong answers easier to spot. A change that sounds plausible but does not satisfy the example is not done.

This is the part that feels different in the agent era. Before, test-first could feel like extra typing before the real work. Now the implementation is often the easy part. The hard part is avoiding an answer that is locally convincing and globally wrong.

That shift helps in review too. I can ask two concrete questions instead of one fuzzy one: does the test capture the intended behavior, and does the change satisfy it without breaking adjacent cases? That is a much cheaper judgment than trying to reconstruct intent after the fact.

Where I would not force it

I would not use this pattern for everything.

If I am exploring a new API, tuning UI feel, or spiking an architecture change, I may not know the right assertion yet. In that kind of work, writing the test first can become theater. The contract is still moving.

Red-green pays off when the behavior is clear enough to state precisely: a bug, a business rule, a parser edge case, a regression, a transformation, an authorization boundary. In those cases, the test does not slow the work down. It prevents the work from drifting.

That is also why I care less about strict dogma than about order. I do not need every change to follow a perfect textbook cycle. I do want the contract to become executable before I trust the result.

The prompt can stay short

In practice, the instruction can be brief: `Use red-green TDD for this bug.`

That small prompt carries more structure than it seems to. It means: write the focused test, run it before touching the implementation, check that the failure matches the bug, fix the setup if the failure is wrong, make the narrowest correct change that turns the test green, and rerun the checks.

Sometimes that test is unit-level. Sometimes it is an integration test, a CLI snapshot, or a browser assertion. The important point is not the layer. The important point is that the acceptance criteria exist before the implementation lands.

I used to think TDD felt unnatural because it asked me to describe the answer before I had written it. With agents, it feels natural for the opposite reason. I am not using the test to help me type. I am using it to decide whether a fast answer is trustworthy.

When code arrives cheaply, the scarce resource is confidence. A good failing test is one of the fastest ways to buy it.

When an agent lands in `shipping-quotes`, it should be able to answer four questions quickly:

- What does this component own?

- How do I work here?

- How do I verify a change?

- Where does the tricky context live?

If the component cannot answer those questions locally, the agent reads too much, touches too much, and asks too many basic questions. Ownership is fuzzy. The right commands are tribal knowledge. The important context lives in a slide deck, a spreadsheet, or somebody’s memory. So the agent wanders.

That is not always a model problem. Often, it is a component problem.

This is also a different problem from feedback after the edit. Before an agent can verify its own work, it has to orient itself in the component.

What does this component own?

An agent works best when it can reason locally.

That means the component should have a clear boundary, a small blast radius, and obvious contracts. In `shipping-quotes`, the agent should be able to tell what this component owns, what it depends on, and what it should not touch. It should know whether this component computes carrier quotes, consumes package and destination data, applies zone rules, or also owns checkout totals. Those are different jobs. A good boundary makes that visible in the interfaces, the file layout, and the local docs.

This matters more than context-window size. Even with a huge context window, a tangled component is still hard to change. The problem is not only how much code the agent can read. The problem is how much uncertainty the component creates. If every small edit may break three adjacent systems, the cost of acting goes up fast.

The first test is simple: can the agent make a local change without dragging half the repo into scope?

How do I work here?

Once the boundary is clear, the local path should be obvious.

If I drop an agent into `shipping-quotes`, I want it to find a short local guide. That might be `AGENTS.md`, `CLAUDE.md`, or a tight `README`. The name matters less than the job. The file should say what this component owns, which invariants matter, which commands to run, where the tests live, and what not to edit casually.

The component should also expose one obvious way to work. There should be one obvious command to run the local flow, one obvious command to exercise the tests, and one obvious place to look when something fails. If the repo offers four test commands, three half-working scripts, and two undocumented setup paths, the agent spends its first half hour on archaeology.

Good output belongs here too. When something breaks, the error should narrow the problem. “Missing carrier rate for zone” is useful. “Package dimensions exceed supported service limits” is useful. A stack trace with no domain signal is not. Legible components produce legible failures.

How do I verify a change?

Before an agent can fix a component, it needs a fast way to learn what the component does.

That is why tests matter so much. They do not only verify the change after the edit. They orient the agent before the edit. A strong suite shows what inputs matter, which edge cases the team cares about, and how wide the surface really is.

In `shipping-quotes`, a small suite might reveal the expected output for a domestic order, what happens to oversized packages, how missing carrier rates fail, and which rounding rules matter. In five minutes, that tells the agent more than a long design doc full of abstractions.

If a component is hard to understand, the fix is often not more prose. It is better tests. A good test file is both a guardrail and a map.

Where does the tricky context live?

The hard part of a component is often not the syntax. It is the domain logic.

That context should live where the agent can read it: in or near the component. Examples, fixtures, schemas, expected outputs, notes on invariants, and short explanations of weird cases all help. They are discoverable, versioned, searchable, and easy for an agent to inspect.

If the meaning of `shipping-quotes` lives in a slide deck, a spreadsheet, or somebody’s memory, the agent starts blind. The operator then has to shuttle basic context into the prompt by hand. That is slow, fragile, and easy to get wrong.

This does not mean every component needs a Markdown essay. It means the important context should exist in agent-readable form and sit beside the work. A canonical fixture is better than a paragraph. A sample output is better than a vague comment. A short glossary beside the code is better than a forgotten deck.

The standard to aim for

A good operator should be able to drop an agent into `shipping-quotes` without writing a custom tour guide every time.

The agent should find a clear boundary, one local path, tests that teach the terrain, and context that lives beside the code. If it cannot, a bigger prompt will not solve the underlying problem. The component is still illegible.

That is the standard I care about. Not whether an agent can eventually muddle through, but whether it can land in an unfamiliar component and become useful fast.

If you want better work from agents, stop treating the prompt as the only interface. The component is an interface too.

If an agent cannot see what happened, check its own work, and recover quickly, you cannot trust it with much autonomy. You end up doing courier work: take the screenshot, paste the log, restate the bug, and ask it to try again. The system looks agentic, but the human is still carrying evidence back and forth.

I think about this as three nested loops. They are not three competing philosophies. They are three layers of feedback that tighten what the agent can do and narrow what the human must do.

- Loop 1: the human verifies after the fact

- Loop 2: the agent verifies its own work

- Loop 3: the human closes the loop on reality

Better feedback loops are what let agents work with more autonomy without losing contact with reality.

Loop 1: The human verifies after the fact

This is where most teams start.

Imagine a small web demo with an SVG orbit and a moving marker. You ask the agent to adjust the motion, line up the marker with a target, or change the animation. The agent edits the code and says it is done. Then you open the app, inspect the result, take a screenshot, and describe what is still wrong.

The loop works. It is also slow.

The human becomes the transport layer between the agent and the finished state. Because the agent cannot inspect the result on its own, it cannot correct itself. Every iteration depends on another round trip through you.

Loop 2: The agent verifies its own work

The second loop starts when the agent can inspect the system directly.

Give the same orbit demo browser automation, screenshots, logs, DOM assertions, and a fast test runner. Now the agent can change the code, open the page, capture the result, check whether the marker reached the target, and try again without waiting for a human to relay the evidence.

That is the key step up from Loop 1. The agent no longer needs the human to act as courier for basic evidence. It can compare the code against the rendered result itself. But the human often still has to do the last piece of work: open the final state, decide whether it really makes sense, and translate that judgment back.

That change is larger than it sounds. Better tools do not merely make the workflow nicer. They increase how much autonomy you can safely allow.

The same pattern holds outside toy demos. A broken onboarding form, a flaky CLI flow, or a staging-only UI regression all become easier when the agent can run the app, inspect structured output, and verify the result directly.

The analogy is simple. A developer can write software in a bare text editor. The same developer will move faster and make fewer mistakes with search, debugging, tests, and fast feedback. Agents are no different. A shell and a pile of text are enough to start. Logs, structured file access, screenshots, and browser tooling are what make self-correction practical.

That is Loop 2. The agent can inspect its own work, verify the result, and retry without waiting for a human to relay the evidence.

If you want agents to do more unsupervised work, start here. Improve what they can see and shorten the time it takes them to check themselves. But do not stop there. The next step is to build a shared playground around the app.

Loop 3: The human closes the loop on reality

Loop 3 starts when you build a shared playground around the app.

Loop 2 is about self-verification. The agent can run checks, inspect output, and correct itself. Loop 3 adds a shared surface for inspection. The agent and the human can open the same exact state on demand, look at the same evidence, and talk about the same thing.

That distinction matters. Passing tests is not the same as shipping the right thing. A screenshot can prove that the marker is on the target. It cannot tell you whether the motion feels awkward, whether the interaction matches the real intent, or whether the change solves the user’s problem.

Take the orbit demo one step further. Add query parameters that pin the marker to an exact angle, set the target, pause the motion, and render known scenarios on demand. Now the agent can open a precise state by itself. It can run checks and capture screenshots. The human can open the same URL and inspect the same state. The agent closes the verification loop; the human closes the product loop.

The form of that playground depends on the app. In a web app, it might be query parameters, fixtures, and debug routes. In a CLI app, it might be a scripted tmux session with fixed terminal size, seeded input, known fixtures, and a command that recreates the flow on demand. The tool changes. The principle does not: build a surface where the agent and the human can inspect the same reality.

That is the job the human should keep. Not micromanaging every step. Not approving every command. The human anchors the work to product intent, taste, and real-world constraints.

What to add in practice

If you want agents to do more useful work, shape the environment around them. In a real repo, that often means adding a few boring, high-leverage affordances:

- Build a shared playground for the app. For a web app, that may mean fixtures, query parameters, and debug routes. For a CLI app, it may mean a scripted tmux session with fixed dimensions, seeded input, and known fixtures.

- Expose important state on purpose. Add seed scripts, stable fixtures, and one-command setup paths that let an agent open a known state without guessing.

- Make verification cheap. Keep one fast command for focused tests, one reliable way to run the app, and one short path to capture logs or screenshots.

- Prefer structured tools over scraping. Return JSON from diagnostics, use stable DOM locators, and expose clear file or API interfaces instead of forcing brittle shell parsing.

None of this is glamorous. It is infrastructure for feedback. But it changes the shape of the work. When the system is legible, the agent can move faster. When checks are cheap, the agent can recover faster. When the human and the agent can inspect the same state, trust gets easier to build.

A small toy project helps because it makes these loops easy to see. But the lesson is not about toys. In real teams, the ceiling on agent autonomy is usually set less by intelligence than by feedback. If agents can inspect state, run checks, and recover on their own, they stop needing a human to ferry evidence between attempts. If they can step into a shared playground built for the app, the human can stop acting as courier and start acting as judge.

Prompting still matters. But once the task is understood, the practical questions are simpler: What can the agent see? What can it verify? What shared playground can it open with you? Better answers to those questions are what turn a clever demo into a reliable way of working.

Subscribe now