At my first professional Muay Thai event, we went to support a new amateur fighter. Their bout was on the early card, before even the preliminaries. In my mind, this person was already an expert at fighting.
Then we stayed for the rest of the event.
As the night moved through the early bouts and into the professional fights, across different levels and weight classes, the differences in skill were noticeable. Everyone was participating in the same sport, in the same environment. Yet “knows how to fight” covered far more ground than I had understood.
Platform shifts change the usefulness of experience. Technical judgment can carry forward while familiar assumptions need testing. With agents, practice delegating and reviewing work may become newly useful. Two seasoned architects can bring different preparation to that work, even when they know the same product.
Experience contains principles and assumptions
Consider the move from installed client/server applications to browser-based web development.
The web still uses clients and servers. The change was in how applications were delivered and used, and which assumptions a developer could safely make.
Knowledge of data modeling, business rules, security, and debugging remained useful. Familiar expectations about the client, its installation, and the continuity of an interaction needed another look. Even early HTTP design discussions explicitly considered the difficulty of bringing systems that retained intermediate results into the web’s request model. The protocol’s design notes record that problem.
A seasoned developer had substantial knowledge to bring. They also had to distinguish an underlying principle from a habit that worked well in the previous environment.
Desktop to mobile presents a similar question. Understanding software and interaction design remained valuable. But shrinking an interface could not resolve every difference in how the application would operate. On iOS, for example, moving into the background changes what an app is allowed to do; it must prepare for suspension and the possible loss of resources. Apple’s lifecycle guidance makes that responsibility explicit.
These are examples of changed conditions, not evidence that every veteran struggled with them. The useful question is how someone responds when a familiar approach stops being sufficient.
Two people with comparable years of experience can bring different combinations of knowledge, assumptions, and practice to the same transition.
A change in the work can also make previously adjacent experience more relevant.
Delegation becomes part of the technical work
That possibility interests me most with agents.
I have been a development lead, run global teams across multiple functions, and managed people with different skills and levels of experience. I suspect that background helps explain why some agent work feels familiar.
Leading delivery requires making a problem understandable to someone else. You have to establish what they need, where their assignment ends, what depends on it, and how you will assess what comes back.
The assignment also changes with the person receiving it. Someone may need a clear boundary and access to the right sources. Someone else may need an example, a smaller task, or an earlier review.
Some work I once delegated to people now goes to agents or scripts. Decisions about scope, context, dependencies, and review remain.
Managing people involves obligations and relationships that do not transfer to software. Still, experience organizing work through others seems relevant to organizing agent work.
A solution architect can have deep product knowledge without having spent much time leading delivery through a team. Another architect may have done both. Those backgrounds could produce different approaches to agents, even when their domain expertise is comparable.
That is a possible explanation for differences in practice. Establishing how much it explains would require more than observing one person’s result.
What experts make routine
An AI-assisted comparison document prompted this line of thought. It examined two approaches to purchasing across multiple business locations and included test results, screenshots, and a recommendation.
My question was how much of the assignment needed to be figured out again.
A request to “compare these approaches” leaves considerable work unstated. Which buyer roles matter? What should happen when someone attempts to reach a location outside their authority? Does changing locations affect pricing? Whose identity belongs on the order?
Choosing those questions requires domain judgment. An agent with suitable access can investigate them and collect evidence. Someone still has to decide whether the investigation supports the recommendation.
A successful checkout, for example, does not establish that access restrictions work. That requires an attempt that should be refused.
The expertise shapes both the assignment and the assessment.
Once an expert has conducted that investigation, some of the method can carry into the next one. The relevant sources can be identified. The test conditions can be written down. A fixed check can become a script. The distinction between an observed result and an assumption can become an explicit requirement.
That preparation changes what the next assignment demands.
My working environment includes standing instructions about sources, verification, permissions, review, and completion. Those instructions give new work somewhere to start. They also need revision when they fail or the environment changes.
This helps explain how substantial work can become routine. Some of the decisions required to conduct it have already been made and preserved.
The remaining judgment concerns what is different this time.
A recurring assignment can test what transferred
In There’s No Replicator Yet, I wrote about how much cooking a person still has to supply when working with AI. The MasterChef Problem already distinguishes access to equipment from demonstrated skill, including the ability to coordinate work. In Open Kitchen, I examined how difficult it can be to make a personal working setup usable by someone else.
The additional question here is which prior experience helps someone develop that practice when the tools and conditions change.
Preparing a reusable method is easier to justify when an investigation recurs. For a one-off task, writing and maintaining that method may cost more than it saves. And a method can repeatedly test the wrong thing. Domain expertise and taste still matter in deciding whether the result fits the problem.
For my own agent work, the practical test is a recurring assignment. I can examine what I had to intervene in, decide which interventions should become reusable instructions or checks, and see whether the next run needs less repair without losing evidence.
