A function that took an afternoon now takes a prompt and a review. A prototype that took a week can exist by lunch. Boilerplate, migrations, test scaffolding, the fifth CRUD screen: models produce all of it quickly and mostly correctly.

It is tempting to conclude that software itself is getting cheap.

I don’t think that follows. Code is getting cheaper. Software isn’t, at least not at the same rate.

The difference is where the interesting work is moving.

Code was never the whole cost

Anyone who has run a software project for long knows that typing was rarely the bottleneck.

The expensive parts were elsewhere:

• working out what the system should actually do,
• deciding where one component ends and another begins,
• integrating with systems you don’t control,
• handling the cases nobody mentioned in the spec,
• keeping it running, observable and correct once real people use it,
• changing it later without breaking what depends on it.

Models help with some of this. They are good at reading unfamiliar code, proposing a design and spotting an obvious gap.

But most of that list is about decisions, not keystrokes. And decisions have consequences that outlive the session in which they were made.

When the cost of producing code drops, the relative cost of those decisions goes up.

Cheap code means more code

When something gets cheaper, we tend to use more of it.

That is already visible. More internal tools. More prototypes. More scripts that quietly become services. More integrations, because building one is now an evening instead of a sprint.

Each of those pieces may be simple. The system they form together is not.

Every new component brings interfaces, state, failure modes and an owner who may or may not remember it exists in six months. Cheap code lowers the cost of adding parts. It does nothing for the cost of understanding how the parts interact.

So the total amount of complexity in a company can grow faster than before, not slower.

That is not an argument against using AI to write software. I use it constantly. It is an argument for paying more attention to the shape of what we are building.

What systems thinking actually means here

“Systems thinking” can sound like a consultancy slide. I mean something quite practical.

It is the habit of asking questions like:

• Where does state live, and who is allowed to change it?
• What happens when this call fails halfway?
• What does this component assume about the others, and what happens when that assumption stops being true?
• Where are the feedback loops? How would we notice if this were quietly wrong?
• What is the cost of being wrong here, and who pays it?

None of these questions gets easier because the code was generated.

Some of them get harder. Generated code is often locally reasonable and globally unaware. A model can write a perfectly sensible retry loop that, combined with 3 other perfectly sensible retry loops, produces a very efficient way of taking down a dependency.

Agents make it more obvious

Working with agents makes this especially visible.

An agent iterating on its own work has the same failure modes as a team without a clear definition of done. When I wrote a small skill for iterating on an artifact until it reaches a confidence threshold, the 2 problems I had to design against were exactly that:

• Score inflation: every pass nudges the number up without evidence.
• Scope padding: to reach 100%, the loop invents work the artifact doesn’t need.

The fix wasn’t a smarter model. It was structure: every re-score has to cite specific evidence, the loop stops when the same weakness appears twice, and trade-offs go back to a human instead of being guessed.

That is systems design. The model is one component. The loop around it determines whether the result is useful.

The same thing showed up in a trading experiment with a fast decision model. Changing the wording of the question moved the rate at which it wanted to trade from 3% to 70% of decisions on identical market states. The model hadn’t become braver. The system around it had changed, and nobody would have noticed without caching answers by prompt and comparing like with like.

Where the value moves

If code gets cheaper and systems don’t, a few things become relatively more valuable.

Knowing what not to build. When building is nearly free, the discipline is in saying no. Every feature you ship is something you operate.

Clear boundaries. Good interfaces were always valuable. They are more valuable when a lot of the code on either side of them is written quickly, by people and by models, and replaced often.

Cheap ways of being wrong early. Before spending money on model calls in that trading experiment, the useful first step was computing the cost floor: the minimum a strategy has to earn to pay its own fees. It said the idea was impossible at that horizon, and every later result agreed. A few lines of arithmetic did more than any amount of generated code.

Operating knowledge. Someone still has to know why the system is shaped the way it is. Some of that can live in documentation and, increasingly, in agent memory. But somebody has to decide what is worth remembering.

Taste. Not the aesthetic kind only. The judgment that a design is too clever, that a dependency isn’t worth it, that 2 services should really be one.

The open questions

I’m not sure how far this goes.

Models are getting better at the system level too. They can already read a whole codebase and point out that 3 services duplicate the same logic. It would be naive to assume that architecture is a permanently human activity.

I’m also not sure how people will learn systems thinking if they rarely write the code themselves. A lot of systems intuition comes from building things that broke and having to understand why. If a model writes the code and another model fixes it, where does that intuition come from?

And there is an organisational question. Many companies measure engineering by output. Cheap code makes output a worse measure than ever. What replaces it?

Where I’ve landed for now

For now, I treat generated code roughly the way I treat code from a fast, capable colleague I haven’t worked with for long.

Useful. Often right. Occasionally confidently wrong in ways that only show up at the boundaries.

The code is the cheap part. The system is the product.

Which, to be fair, was always true. It is just harder to ignore now.

You type, it answers. The model produces text, and everything else, tools, agents, structured output, gets built on top of that text.

Jev is a different kind of thing, and playing with it is a good way to think about where models can sit inside software.

What Jev is

Jev is a model from TypeSafe. They describe it as a System One model: built for decisions inside software rather than for conversation.

You don’t send it a prompt and get prose back. You send it structured state and a question with a fixed set of options, and it returns a typed choice with probabilities for each option.

A decision looks roughly like this:

const result = await client.systemOne({
  state: { objective, computer, availableActions },
  questions: {
    action: choice("Choose the best available action.", criteria),
  },
});

It is also cheap and fast. TypeSafe prices it at $42 per billion input tokens, and their own demo shows a decision in about a tenth of a second.

When I say tiny in the title, that is what I mean: tiny per decision, in cost and in time. I don’t know how big the model actually is. What matters for the experiments is that you can afford to ask it something every half second, for hours.

That changes what you can build.

I gave Jev a computer from 1999

One experiment is JEV/98: a small simulated late-90s computer in which Jev chooses every action.

Every ~650 ms the loop runs:

• the simulated computer changes state,
• Jev sees that state and a finite list of legal actions,
• Jev chooses exactly 1 of them,
• the interface shows the full probability distribution,
• ordinary deterministic code applies the consequence.

There are 3 missions. Get online and download a file without infecting the machine. Identify a suspicious sender and delete the attachment. Finish a download before Mom needs the dial-up phone line.

The important design choice is that Jev can’t do anything the code doesn’t allow. It is not a chatbot wearing a beige-computer skin. There is no way for it to invent a command, break the fourth wall or talk its way out of the simulation. The code defines the action space. The model only chooses within it.

Everything is recorded: the selected action, the top probabilities, whether the answer came from the live model or a local fallback, and the latency. A run can be shared as a replay link that plays back the recorded decisions without calling the model again.

If there is no API key, a simple heuristic plays instead, and the interface labels it DEMO POLICY. No fake model results.

I gave Jev dysentery

JEV/78 does the same thing with the 1978 Oregon Trail.

The original is a BASIC program, and JEV/78 is not a wrapper that sends keystrokes to it. The rules are rebuilt in the same shape as JEV/98: one function returns the available actions, another advances the state. Jev chooses every legal wagon action. The world is seeded, so a death can be replayed.

Some things didn’t fit. The famous TYPE BANG shooting minigame is about reaction time, not decisions, so Jev doesn’t play it: its rifle skill becomes a roll. Shop and fort amounts are bucketed so the set of choices stays finite.

That last constraint turns out to be the whole trick. Once the choices are finite and explicit, a model can operate a system safely and legibly.

I gave it money, on paper

Games are forgiving. Markets are not.

I also built a lab to test whether Jev had any short-horizon trading value on the Hyperliquid Bitcoin perpetual. Same pattern: normalised market state in, buy, sell or hold out, with probabilities, and deterministic code deciding whether anything actually happens.

The answer was no.

Across about 2,100 decisions at a 30-second horizon, its signal was indistinguishable from noise once the sample was large enough, and never within an order of magnitude of the cost of trading. Longer horizons, maker orders, regime classification and daily news briefs didn’t rescue it either.

Two details stayed with me.

First, in the early runs Jev’s own estimate that a trade would be profitable after costs never went above 0.51. It had no edge, and in a sense it knew.

Second, the wording of the question mattered enormously. Changing the phrasing moved its trade rate from 3% to 70% of decisions on identical market states. Within one test window, prose briefs beat JSON dumps. Verbose you are a risk manager instructions added nothing. I ended up writing a house style for questions, because otherwise experiments weren’t comparable with each other.

Jev is documented as weak on raw numbers, so none of this is a verdict on the model. It is a verdict on one use of it. Structured yes-or-no decisions look like a much better fit than predicting prices.

Strange new interfaces

The part I find most interesting isn’t the trading result. It’s what these experiments look like on screen.

There is no chat box. You don’t talk to the model. You watch it.

The interface is the state of the world, the list of things that can happen next, and a probability bar for each option. You can see the model hesitate between 2 choices. You can see it become confident. You can replay a run and see exactly where it went wrong.

That feels closer to how we might want software with a model inside to behave generally:

• The action space is the interface. What the model may do is visible, not hidden in a prompt.
• Uncertainty is shown, not hidden. Probabilities are more honest than a fluent paragraph.
• Decisions are replayable. You can inspect a past choice with exactly the inputs it had.
• The model is a component, not the product. Deterministic code owns the consequences.

Chat is a wonderful interface for open-ended questions. It is a strange interface for a system that should make 1 of 5 known choices 100 times a minute.

Open questions

I don’t know yet where the useful applications are.

Games and simulations make the pattern easy to see. The JEV/98 notes already list a virtual railway dispatched by the same decision API, and eventually physical hardware. Whether that is useful or just fun is part of the question.

The bigger question is where fast, cheap decisions inside software beat either hand-written rules or a large model reasoning in text. My guess is routing, gating, triage and control loops, anywhere the choices are known and the cost of asking needs to be close to zero. The trading lab is also a reminder that a one-line rule is sometimes just as good.

And I’m curious what happens when interfaces like these become normal. When the model is not something you talk to, but something you can watch deciding.

That seems like a strange new interface worth building more of.

They can reason surprisingly well about whatever is in front of them, but start a new conversation and much of that understanding disappears. You explain the company again. The project again. Your preferences again. The reason a decision was made three weeks ago, again.

For a chatbot, that can be mildly annoying.

For an agent that is supposed to do useful work over time, it becomes a fundamental limitation.

Over the past year I’ve spent a lot of time building with agents and thinking about what happens when they stop being isolated prompts and begin operating as persistent software systems.

Memory turns out to be one of the more interesting parts.

Not because storing information is difficult. We have been exceptionally good at putting things into databases for several decades.

The difficult part is deciding what deserves to be remembered, what it means later, and when it should come back.

Memory is not a transcript

The obvious implementation of agent memory is to save every conversation.

That is useful, but it isn’t really memory.

A transcript is history. Memory is compression.

Humans don’t replay every sentence they have ever heard before making a decision. We retain some facts, forget others, form abstractions and gradually build a model of the world.

An agent needs something similar.

Imagine an engineering agent working inside a large codebase.

Over time it might discover that:

• a certain service deliberately avoids local state,
• a particular API has an ugly compatibility constraint,
• the team prefers one architectural pattern over another,
• a bug that looks obvious has already been investigated twice,
• one engineer tends to care deeply about backwards compatibility,
• another system is scheduled to disappear in six months.

None of those facts necessarily belong in the immediate prompt.

But they can dramatically change the quality of the next decision.

The useful unit of memory therefore isn’t:

Here is everything that happened.

It is closer to:

Here is what appears to remain important.

That distinction sounds small. It changes the architecture considerably.

More context is not the same as more intelligence

Large context windows created a tempting idea: perhaps we can simply give models everything.

Eventually, that becomes its own failure mode.

An agent with access to thousands of irrelevant facts can be worse than one with ten useful ones. Retrieval becomes noisy. Old assumptions survive long after reality changed. Contradictory information accumulates.

Context has a cost even when the model can technically accept it.

The real problem becomes selection.

When an agent is working on a database migration, what should it remember about the product?

When it is replying to a customer, what should it know about the architecture?

When a user changes their mind, how quickly should an older preference lose authority?

The quality of a memory system is therefore not measured by how much it stores.

It is measured by how well it decides what to surface.

That starts looking less like a database problem and more like an information architecture problem.

Which, conveniently, means software engineers get to reinvent librarianship with embeddings.

Memories have different lifetimes

Another thing that becomes obvious surprisingly quickly: not all memory should behave the same way.

Some things are effectively permanent.

This application uses PostgreSQL.

Some are durable preferences.

Prefer boring infrastructure over introducing another service.

Some are observations.

The current implementation appears to be CPU-bound during type checking.

Some are temporary.

We are debugging the authentication flow this week.

And some are conclusions that may later turn out to be wrong.

This bug is probably caused by caching.

Treating all of these as equivalent creates trouble.

Useful agent memory needs some notion of provenance, confidence and time.

Where did this belief come from?

Was it explicitly told to the agent or inferred?

Has it subsequently been contradicted?

When was it last relevant?

That metadata matters because an agent is not merely retrieving facts. It is retrieving beliefs about a changing system.

Software changes.

Organizations change.

People change their minds.

A memory system that cannot forget eventually becomes a very confident historian of a world that no longer exists.

Forgetting is a feature

This may be the counterintuitive part.

Good memory requires good forgetting.

Engineers naturally like persistence. Losing information feels like failure.

But forgetting can be an important form of compression.

If an agent worked through twenty hypotheses before finding the cause of a production bug, the useful long-term memory probably isn’t all twenty hypotheses.

It might be:

Requests to this service can appear stale because this cache is process-local. Prefer the shared Redis path for cross-instance state.

The investigation mattered while solving the problem.

The conclusion matters afterward.

That raises an interesting question: should agents periodically reinterpret their own histories?

I think increasingly they will.

Rather than memory being written once and retrieved forever, persistent agents may continuously consolidate what they know. Recent experiences become observations. Repeated observations become patterns. Some patterns become durable knowledge. Others decay.

That starts to resemble learning, even if the underlying model weights never change.

Memory changes the interface

Persistent memory also changes how software feels.

Today we largely think of AI interfaces as conversations.

Open a box. Ask a question. Receive an answer.

But once the system remembers projects, decisions, people and unfinished work, the conversation becomes only one view into something larger.

The interesting object isn’t the chat.

It is the evolving relationship between the agent and its environment.

An agent might remember that a migration was postponed, notice the dependency has since disappeared, and bring the issue back months later.

It might understand why a particular architectural decision was made instead of merely observing that the code exists.

It might recognize that the problem somebody is describing today looks suspiciously similar to an incident from last year.

At that point the system begins to feel less like a tool waiting for commands and more like another participant in the work.

That introduces plenty of uncomfortable questions around privacy, control, observability and trust.

It also makes the software considerably more useful.

The model is only part of the product

Building with increasingly capable models has reinforced something I already believed about software.

The cleverest component is rarely the whole product.

A powerful model without the right context can produce a mediocre result. A slightly less capable model embedded in a system with good tools, useful memory and strong feedback loops can be remarkably effective.

The surrounding architecture matters.

So does product judgment.

What information do we expose?

What actions can the agent take?

When should it ask instead?

What should be remembered?

What should disappear?

What can the user inspect and correct?

Those decisions increasingly determine whether an AI system feels impressive for five minutes or remains useful after five months.

Where this gets interesting

I don’t think the eventual form of agent memory will look much like a folder labelled memories.

It will probably be distributed across several layers: explicit facts, semantic retrieval, project state, interaction history, environmental observations and learned preferences.

Some memory will belong to a person.

Some to a company.

Some to a task.

Some to the agent itself.

And agents will need to reason about the boundaries between them.

We are still early enough that many of these systems feel slightly improvised. That is part of what makes working on them fun.

A lot of AI right now is focused on making the model smarter.

I suspect an equally important frontier is making software around the model better at remembering what matters.

Because intelligence without continuity is useful.

But continuity is what starts turning intelligence into a system.

Behind every action there is a person.

A person opens the account. A person passes KYC. A person approves the payment, signs the transaction, accepts the terms and carries the responsibility when something goes wrong. Software sits in between, but it is plumbing. It carries instructions. It does not have intentions.

That assumption is starting to wear thin.

Agents can now read a situation, decide what to do and act on it, including actions that move money. Not in a science-fiction sense. In a mundane, already-possible sense: a process with credentials, a budget and a goal.

I work on financial infrastructure, and I spend a lot of time building with agents. The overlap between those two things raises questions I don’t think the industry has good answers to yet.

Identity was always about people

Regulated finance is organised around knowing who you are dealing with.

KYC for individuals. KYB for companies. Beneficial ownership. Sanctions screening. Transaction monitoring that compares behaviour to what is expected of that customer.

All of it assumes the actor is a legal person, or a structure that resolves to legal persons.

An agent is neither. It acts on behalf of someone, but not in the way a bank transfer acts on behalf of someone. It makes choices within a range. Run the same agent twice with the same instructions and it may not do the same thing.

So the question isn’t only who is this? It becomes:

• who does this agent act for?
• what was it allowed to do?
• who set those limits, and when?
• did this specific action fall inside them?

Those are different questions. Current identity systems mostly answer the first one.

Keys are already becoming mandates

Interestingly, wallet infrastructure is further along here than most of traditional finance.

At Agio our public docs describe 3 kinds of wallet. Custodial wallets use multi-signature approval policies and address whitelists: funds can only move to known places, with the right people signing. Hot wallets leave the encryption key with the client. Smart wallets built on ERC-4337 support session keys for delegated signing.

A session key is an interesting primitive. It separates ownership from authority to act. The owner keeps control of the account. Something else, possibly a piece of software, gets a narrow, revocable permission to do specific things for a while.

That is very close to what an agent needs. Not the keys to everything. A mandate.

The financial world has used mandates for a long time: powers of attorney, trading authorities, standing orders, investment guidelines. What is new is that they can be expressed in code, enforced at the point of signing, and granted to something that isn’t a person.

The model decides, the code enforces

When I’ve built experiments where a model makes decisions with financial consequences, one pattern kept proving useful.

The model proposes. Deterministic code disposes.

In a small trading lab I built, the model only ever emits a market signal: buy, sell or hold, with probabilities. It never sees the portfolio and never places an order itself. Ordinary code decides whether the signal clears the thresholds, applies the position rules, computes the costs and records everything. Real trading is deliberately annoying to switch on: it needs an explicit environment flag that reads LIVE_TRADING=YES_I_UNDERSTAND.

That last detail is a joke, but only slightly.

The general shape is what I think matters for finance:

• the model’s output is a typed, bounded proposal, not free text,
• the space of possible actions is defined by code, not by the model,
• limits are enforced where the action happens, not in the prompt,
• every decision is logged with what the model saw and what it chose,
• switching from simulation to real money is an explicit human act.

A prompt that says never spend more than $100 is a request. A signing policy that rejects transactions above $100 is a control. Regulators, auditors and customers will eventually want to see the second kind.

Audit becomes about reasoning, not just records

Financial systems are good at recording what happened. Ledgers, transaction logs, approval trails.

When software acts, why becomes much more important.

If a person makes a bad trade, you can ask them. If an agent does, you need to reconstruct what it knew at the time, which instructions it was following, which limits applied, and whether the outcome was a bug, a bad instruction or a reasonable decision that turned out badly.

That means logging inputs and outputs, not just effects. The prompt, the state, the model version, the probabilities, the policy that approved or rejected the action.

It also means being able to replay a decision. In my own experiments, caching every model answer against exactly what the model was shown turned out to be essential. Without it, you can’t tell whether a change in behaviour came from the model, the prompt or the market.

For compliance, that kind of replayability may become as important as the ledger itself.

Liability doesn’t disappear

A tempting mistake is to treat an agent as a new kind of party. It isn’t, at least not legally. Someone deployed it. Someone gave it authority. Someone benefits from what it does.

So responsibility will keep resolving to people and companies. What changes is how clearly that chain has to be documented.

Today, if a payment goes wrong, the chain is usually short: customer, bank, maybe an intermediary. With agents it can get long quickly: the user, the application, the agent framework, the model provider, the wallet, the policy that approved it.

Financial infrastructure that makes that chain explicit, who granted what authority to which software under which limits, will be much easier to trust than infrastructure that treats agent activity as just another API call.

The open questions

I don’t know how most of this plays out.

Does an agent need its own identity? Or is it always an extension of its principal, with a mandate attached? The second feels more honest to me, but the first may be more practical at scale.

How do you monitor behaviour that is meant to vary? Transaction monitoring looks for deviations from expected patterns. An agent that adapts will deviate by design.

What does consent look like? A user clicking allow on a broad permission once is not meaningfully informed consent for 1,000 future decisions.

Where does the model sit in a regulatory sense? A tool, a service provider, or something new?

What I’m fairly confident about is the direction. Software is moving from carrying instructions to making decisions. Finance is one of the places where that shift matters most, because the consequences are measured in money and the rules were written for people.

The interesting infrastructure work is in the gap between the two.

That can look odd. The usual assumption is that at some point you stop building and start directing: you write the strategy, someone else writes the code.

I understand the logic. I just don’t think it holds up very well, and less so every year.

A prototype is a question with a deadline

Most ideas look good in a document.

A document lets you skip the parts you haven’t thought about. It lets two people agree on a sentence while imagining completely different systems. It never fails to compile.

A prototype doesn’t give you that comfort. The moment you build something, even a crude version, the vague parts become obvious. Where does this data actually come from? What happens on the second run? Who is allowed to do this? What does the user see while they wait?

So I think of a prototype less as a first version of a product and more as a question with a deadline. The question is usually some form of: do I actually understand this?

Often the answer is no. That is the useful part.

Cheap answers to expensive questions

A recent example: I wanted to know whether a new, fast decision model had any short-horizon trading value.

Questions like that can turn into weeks of discussion. This one became a small, isolated harness: live market data, paper trading with real fees and slippage, cached model answers, and a set of boring baselines to compare against.

The first useful output wasn’t even from the model. It was a cost floor: how much the market has to move in a given window before a trade can pay for itself. At the horizon I started with, it was effectively impossible. Every later result agreed.

The model did produce one exciting run along the way: 8 correct calls out of 9. That disappeared at 31 trades and again at 85. Small samples lie in your favour.

The final answer was a clear no, for about 20 cents of model usage.

I don’t think I would have trusted that answer as much if someone had summarised it for me. Building it myself meant I knew exactly which assumptions were in the harness, which ones weren’t, and where the result could be wrong.

Understanding doesn’t delegate well

A lot of work can be delegated. Understanding is harder.

If I want to make good decisions about systems, I need an accurate model of how they behave. Not the architecture diagram. The actual behaviour: where it is slow, what breaks, which abstraction is leaking, what looked simple and wasn’t.

Much of that knowledge only comes from contact. Reading about a new model is not the same as watching it make 500 decisions and noticing where it hesitates. Reviewing a design for agent memory is not the same as discovering that your agent is confidently remembering something that stopped being true weeks ago.

At Agio Digital I spend most of my time building, prototyping, reviewing systems and figuring out what we should do next. Those activities feed each other. Prototyping makes my reviews better. Reviews tell me what is worth prototyping.

It keeps the conversation honest

There is also a quieter benefit.

Once a rough version of something exists, conversations about it change. We stop debating whether an idea could work and start looking at what the prototype showed. Disagreements become specific. This part was slow. This step confused people. This assumption was wrong.

A working prototype is hard to argue with in the abstract. That is a feature.

It also cuts the other way. If I propose something and can’t make even a crude version work, that tells me something about the idea, or about my understanding of it, before anyone else has spent time on it.

AI changed the economics

A few years ago, the argument against founders prototyping was partly about time. Building even a rough version of something could take days, and those days had other uses.

That cost has dropped a lot. With agents and good tooling, a prototype that used to take a week can often exist in an afternoon. Scaffolding, glue code and the fifth form field are no longer where the time goes.

So the remaining time goes into the part that matters: deciding what to build, what to measure and what the result means.

If anything, that makes prototyping more appropriate for someone whose job is to figure out what to do next, not less.

What I try to get right

A few habits make prototypes more useful to me:

• Decide the question first. A prototype without a question is just an unfinished product.
• Keep it isolated. Nothing it touches should be hard to delete. The trading harness imported nothing from the rest of the codebase it lived in, on purpose.
• Compare against something boring. A result only means something next to a baseline. Often the baseline wins.
• Label fakes clearly. One of my experiments falls back to a simple heuristic when no API key is present, and the interface labels it DEMO POLICY. No fake model results, even in a demo.
• Leave out infrastructure you don’t need yet. The first release of that same experiment has no database: replays are self-contained links.
• Write down what you learned. A prototype you learned nothing from was just a hobby. Which is also fine, but it helps to know which one it was.

The open question

The part I’m less sure about is scale.

Prototyping myself works when I’m close to the problem. As companies grow, the gap between what one person can build and what the organisation needs gets wider. At some point the prototype becomes a bottleneck, or a toy that doesn’t reflect the real constraints.

I don’t think the answer is to stop. I think it is to be selective: prototype where understanding is the scarce resource, and delegate where it isn’t.

I still enjoy opening an empty repository and figuring something out. Some of those repositories become useful. Some answer a question.

That’s enough.