This translation is not available yet. Showing the original article.
Two people can buy the same iPhone and end up with very different phones. One uses it to text and take pictures. The other has built a pocket studio for recording, editing, and publishing.
The AI version of that story starts with the model, then goes further. Give two people the same model, the same agent, and the same job. Over time, one may become able to take on work that neither of them could handle at the start.
I think one of the biggest divides of the next few decades will be in what people and teams can reliably take on. How they put AI tools together matters, as does what they carry forward from each time they use them.
The model, the agent, and the person
A model can propose a fix. An agent can inspect the code, try the fix, run a test, and use the result to decide what to try next. The person defines what counts as a fix, gives the agent appropriate access, and decides what can ship.
The same installation of Codex can therefore become a different working system for each person. A skill can capture a debugging procedure. A plugin can package access to a tool that fetches approved logs. A hook can run a check at a specific point.
These sound like small differences. But a developer who knows how to give an agent a reproducible failure has changed what that agent can do. With a test it can run and a result it can read, it can make progress across several attempts.
Two loops, on two timescales
Inside a task, the agent can plan, act, check, and revise. It needs a stopping rule: stop when the relevant checks pass, when the evidence is ambiguous, or when the agreed budget runs out.
Consider a fix that passes the current tests but breaks an older customer configuration. A person spots it in review. If they turn it into a regression test and make it part of the workflow, the next agent run can catch it before review.
That is the second loop, across tasks. Each run can leave behind a useful test, an example, or a clearer rule. The person or team can start the next job with what they learned last time, even if they switch models in between.
When a small skill becomes a multiplier
A tool that retrieves logs has some value on its own. Pair it with a skill that tells the agent which failures to look for and a test that tells it whether the fix worked. Now each piece makes the others more useful.
Imagine a team that can try 10 fixes in a week, half of which meet the review standard. That is five accepted fixes. If it can try 15 at the same cost and 70% meet the same standard, it would average 10.5 accepted fixes: 2.1 times as many.
That is an illustration, not a forecast. A 1.5× increase in attempts and a 1.4× increase in the share that passes can multiply. If review is already at capacity, the extra output may instead sit in a queue.
Sustained gains can look exponential for a while if each improvement makes the next one easier. An unused plugin contributes nothing. A weak test can make a fast loop repeat the same mistake. Eventually a new bottleneck changes the rate of progress.
A larger set of problems worth trying
Speed is only part of the advantage. A team that can cheaply verify proposed fixes may be able to take on a migration it used to avoid. The change is in the scope of work it can attempt with confidence.
The same applies deeper in engineering and research. Knowing about fine-tuning lets you ask whether good examples could teach a recurring behavior. Knowing about reinforcement learning lets you ask whether a reliable reward is available for the task.
Neither technique is the default. Data, evaluations, permissions, and review time still matter. Sometimes a better instruction or a reliable check solves the problem. Knowing which approach to try is itself a capability.
What can the next person start with?
Tool access and time to experiment are uneven. But once a working system exists, some of the gains can be shared: a teammate can inherit the check, the examples, and the reasons for using them.
I’d start with one task I do every week. Define what good looks like. Give the agent one way to check its work. Save one failure that matters. Run it again next week and see what now takes less effort or becomes possible for the first time.
The useful question is what your next task can start with that this one had to figure out from scratch.
Two people can buy the same iPhone and end up with very different phones. One uses it to text and take pictures. The other has built a pocket studio for recording, editing, and publishing.
The AI version of that story starts with the model, then goes further. Give two people the same model, the same agent, and the same job. Over time, one may become able to take on work that neither of them could handle at the start.
I think one of the biggest divides of the next few decades will be in what people and teams can reliably take on. How they put AI tools together matters, as does what they carry forward from each time they use them.
The model, the agent, and the person
A model can propose a fix. An agent can inspect the code, try the fix, run a test, and use the result to decide what to try next. The person defines what counts as a fix, gives the agent appropriate access, and decides what can ship.
The same installation of Codex can therefore become a different working system for each person. A skill can capture a debugging procedure. A plugin can package access to a tool that fetches approved logs. A hook can run a check at a specific point.
These sound like small differences. But a developer who knows how to give an agent a reproducible failure has changed what that agent can do. With a test it can run and a result it can read, it can make progress across several attempts.
Two loops, on two timescales
Inside a task, the agent can plan, act, check, and revise. It needs a stopping rule: stop when the relevant checks pass, when the evidence is ambiguous, or when the agreed budget runs out.
Consider a fix that passes the current tests but breaks an older customer configuration. A person spots it in review. If they turn it into a regression test and make it part of the workflow, the next agent run can catch it before review.
That is the second loop, across tasks. Each run can leave behind a useful test, an example, or a clearer rule. The person or team can start the next job with what they learned last time, even if they switch models in between.
When a small skill becomes a multiplier
A tool that retrieves logs has some value on its own. Pair it with a skill that tells the agent which failures to look for and a test that tells it whether the fix worked. Now each piece makes the others more useful.
Imagine a team that can try 10 fixes in a week, half of which meet the review standard. That is five accepted fixes. If it can try 15 at the same cost and 70% meet the same standard, it would average 10.5 accepted fixes: 2.1 times as many.
That is an illustration, not a forecast. A 1.5× increase in attempts and a 1.4× increase in the share that passes can multiply. If review is already at capacity, the extra output may instead sit in a queue.
Sustained gains can look exponential for a while if each improvement makes the next one easier. An unused plugin contributes nothing. A weak test can make a fast loop repeat the same mistake. Eventually a new bottleneck changes the rate of progress.
A larger set of problems worth trying
Speed is only part of the advantage. A team that can cheaply verify proposed fixes may be able to take on a migration it used to avoid. The change is in the scope of work it can attempt with confidence.
The same applies deeper in engineering and research. Knowing about fine-tuning lets you ask whether good examples could teach a recurring behavior. Knowing about reinforcement learning lets you ask whether a reliable reward is available for the task.
Neither technique is the default. Data, evaluations, permissions, and review time still matter. Sometimes a better instruction or a reliable check solves the problem. Knowing which approach to try is itself a capability.
What can the next person start with?
Tool access and time to experiment are uneven. But once a working system exists, some of the gains can be shared: a teammate can inherit the check, the examples, and the reasons for using them.
I’d start with one task I do every week. Define what good looks like. Give the agent one way to check its work. Save one failure that matters. Run it again next week and see what now takes less effort or becomes possible for the first time.
The useful question is what your next task can start with that this one had to figure out from scratch.
Two people can buy the same iPhone and end up with very different phones. One uses it to text and take pictures. The other has built a pocket studio for recording, editing, and publishing.
The AI version of that story starts with the model, then goes further. Give two people the same model, the same agent, and the same job. Over time, one may become able to take on work that neither of them could handle at the start.
I think one of the biggest divides of the next few decades will be in what people and teams can reliably take on. How they put AI tools together matters, as does what they carry forward from each time they use them.
The model, the agent, and the person
A model can propose a fix. An agent can inspect the code, try the fix, run a test, and use the result to decide what to try next. The person defines what counts as a fix, gives the agent appropriate access, and decides what can ship.
The same installation of Codex can therefore become a different working system for each person. A skill can capture a debugging procedure. A plugin can package access to a tool that fetches approved logs. A hook can run a check at a specific point.
These sound like small differences. But a developer who knows how to give an agent a reproducible failure has changed what that agent can do. With a test it can run and a result it can read, it can make progress across several attempts.
Two loops, on two timescales
Inside a task, the agent can plan, act, check, and revise. It needs a stopping rule: stop when the relevant checks pass, when the evidence is ambiguous, or when the agreed budget runs out.
Consider a fix that passes the current tests but breaks an older customer configuration. A person spots it in review. If they turn it into a regression test and make it part of the workflow, the next agent run can catch it before review.
That is the second loop, across tasks. Each run can leave behind a useful test, an example, or a clearer rule. The person or team can start the next job with what they learned last time, even if they switch models in between.
When a small skill becomes a multiplier
A tool that retrieves logs has some value on its own. Pair it with a skill that tells the agent which failures to look for and a test that tells it whether the fix worked. Now each piece makes the others more useful.
Imagine a team that can try 10 fixes in a week, half of which meet the review standard. That is five accepted fixes. If it can try 15 at the same cost and 70% meet the same standard, it would average 10.5 accepted fixes: 2.1 times as many.
That is an illustration, not a forecast. A 1.5× increase in attempts and a 1.4× increase in the share that passes can multiply. If review is already at capacity, the extra output may instead sit in a queue.
Sustained gains can look exponential for a while if each improvement makes the next one easier. An unused plugin contributes nothing. A weak test can make a fast loop repeat the same mistake. Eventually a new bottleneck changes the rate of progress.
A larger set of problems worth trying
Speed is only part of the advantage. A team that can cheaply verify proposed fixes may be able to take on a migration it used to avoid. The change is in the scope of work it can attempt with confidence.
The same applies deeper in engineering and research. Knowing about fine-tuning lets you ask whether good examples could teach a recurring behavior. Knowing about reinforcement learning lets you ask whether a reliable reward is available for the task.
Neither technique is the default. Data, evaluations, permissions, and review time still matter. Sometimes a better instruction or a reliable check solves the problem. Knowing which approach to try is itself a capability.
What can the next person start with?
Tool access and time to experiment are uneven. But once a working system exists, some of the gains can be shared: a teammate can inherit the check, the examples, and the reasons for using them.
I’d start with one task I do every week. Define what good looks like. Give the agent one way to check its work. Save one failure that matters. Run it again next week and see what now takes less effort or becomes possible for the first time.
The useful question is what your next task can start with that this one had to figure out from scratch.
