What happens when an AI agent makes a business decision your team cannot explain? My ten AI predictions for 2027 explore what that means for jobs, costs, power and trust.

Imagine approving an AI rollout on Monday and spending Friday explaining a decision nobody can reconstruct.

The demo worked. The cost looked reasonable. Then the agent issued a refund it should not have approved, and the team discovered that nobody had agreed who would check its work.

That is an imagined scenario, but it captures the question behind my ten AI predictions for 2027: what happens when we start depending on these systems?

If you lead a product, a team or a business, your next AI decision could shape your costs, your hiring and your relationship with customers. These are the changes I would plan for, the signals I would watch and the bets I would be willing to reverse.

My central bet is simple. In 2027, the advantage shifts toward people who can make AI work reliably inside an ordinary business. Each prediction below is a judgment about what could happen, not a report of something that has already happened.

1. AI economics faces a harder test

A cheap answer can become an expensive workflow. Someone still has to connect the systems, check the result, handle exceptions and fix the mistakes.

My prediction is that more AI investment decisions in 2027 will turn on the cost of a completed, acceptable task. A team that counts only model usage can miss the hours spent correcting output. A vendor with impressive growth can still struggle to make the service economical.

Public listings, if they happen, would make that tension easier to examine. My bet does not depend on a particular company going public. It depends on customers and investors asking better questions about what the spending actually produces.

The signal I would watch: renewals that depend on measurable workflow savings, with review and rework included.

What I would do: price one workflow from request to accepted result before expanding it. I would reconsider this prediction if buyers keep increasing budgets without demanding evidence of a return.

2. Local communities get more influence over AI infrastructure

An AI strategy eventually needs somewhere to put the machines. That place has neighbours, a water supply and an electricity bill.

My prediction is that local approval becomes a more important constraint on expansion in 2027. A technically sound project can still struggle if the community sees the costs clearly and the benefits vaguely. Promises about national competitiveness may do little for someone worried about their own utility bill.

I expect developers to face stronger demands for specific commitments on power, water, jobs and local investment. Those commitments could become part of the cost of building.

The signal I would watch: projects delayed, redesigned or approved with enforceable community conditions.

What I would do: include permitting and community concerns in infrastructure planning from the beginning. Faster approvals without additional conditions would weaken this bet.

3. The junior career ladder has to be rebuilt

The easiest tasks to hand to AI can also be the tasks through which a junior employee learns.

That creates an uncomfortable question. If an agent writes the first draft, runs the initial analysis and handles the simple tickets, where does the next experienced colleague come from?

My prediction is that employers will have to design entry level learning more deliberately. Juniors may spend less time producing a first attempt and more time explaining, checking and improving one. That only works if someone teaches them how to recognise a good result.

Paid apprenticeships, supervised projects and protected practice time are the approaches I would bet on. Hiring people who already know everything is a poor long term training strategy.

The signal I would watch: junior roles with explicit coaching and assessment of judgment.

What I would do: protect a path from beginner to independent contributor. I would be less convinced if companies can sustain quality and develop future senior staff while doing little structured junior training.

4. Checking an agent’s work becomes a core skill

Return to the refund in the opening. The important failure happened before the agent acted. Nobody had defined what it could approve, when it should stop or who owned the exception.

My prediction is that verification becomes a visible part of the job, with time and budget attached. Teams will need people who can specify an outcome, design a useful test and decide whether the result is safe to use.

The difficult work is often deciding what counts as correct. A response can sound helpful while breaking a refund policy. Code can pass a narrow test while creating a maintenance problem.

The signal I would watch: agent projects reporting accepted outcomes and escaped errors alongside speed.

What I would do: give each workflow a named owner, clear acceptance criteria and a route for exceptions. This bet weakens if reliable automation needs substantially less human review than I expect.

5. More software is built for one team and one moment

Picture a team that needs to reconcile two spreadsheets during a migration. It needs a useful tool for six weeks. It does not need to become a software company.

My prediction is that more internal software will be built for that kind of narrow, temporary purpose. The buying decision becomes harder when a team can build a sufficient tool quickly.

The hidden bill is ownership. Someone still needs to control access, protect data and decide what happens when the tool breaks. Disposable software needs an expiry date as much as a launch date.

The signal I would watch: internal tools replacing small purchases while central teams introduce rules for maintaining or retiring them.

What I would do: allow small experiments with a named owner and a review date. I would reconsider if maintenance costs consistently erase the savings.

6. Power, memory and permits shape the pace

A model can improve faster than the infrastructure needed to run it.

My prediction is that physical constraints will influence AI availability and pricing in 2027. I would expect some teams to spend as much effort managing capacity, latency and cost as choosing the most capable model.

That makes efficiency a practical advantage. A smaller model, a cached answer or a simpler workflow may be the right choice when it produces an acceptable result at a sustainable cost.

The signal I would watch: capacity commitments, supply lead times and price changes affecting product plans.

What I would do: test cheaper ways to complete the same task and keep a fallback for constrained capacity. Abundant supply and steadily falling total costs would weaken this prediction.

7. Physical AI proves itself in narrow jobs first

A robot folding one shirt makes a good demonstration. A robot handling a full shift of unfamiliar items has a different job.

My prediction is that useful deployments will grow first in bounded environments where the task, surroundings and economics can be controlled. Warehouses, factories and logistics sites offer clearer tests than a general purpose home.

Simulation could help teams practise difficult situations before testing them on expensive equipment. The commercial test still happens in the real world, including maintenance, supervision and downtime.

The signal I would watch: repeat customer deployments with disclosed operating performance.

What I would do: evaluate one task and its full operating cost. Broad, economical deployment of general purpose home robots would make this one of my more obvious misses.

8. AI supplier exit plans become a procurement question

How long would your business keep working if its main model provider became unavailable tomorrow?

My prediction is that more buyers will ask that question before signing a contract. They will want to understand where data goes, what can be moved and which workflows can survive a provider change.

For European organisations, I expect sovereignty discussions to become more practical. An exit plan is useful only if the business can execute it. An open model can offer options, but running it brings responsibilities of its own.

The signal I would watch: procurement requirements for portability, fallback operation and tested recovery.

What I would do: rehearse switching one important workflow. I would reconsider if dependency risks remain minor enough that customers see little value in preparing an alternative.

9. Consumer agents earn trust one permission at a time

I might let an assistant compare flights long before I let it buy a nonrefundable ticket.

My prediction is that consumer delegation grows through small permissions. Research comes first. Preparing an action comes next. Spending money without asking has a higher bar.

Home assistants and shopping agents will have to make their boundaries understandable. What can the agent spend? What does it remember? Can I undo what it did? A smooth conversation does not answer those questions.

The signal I would watch: repeat use after the novelty fades, especially when users allow an agent to complete a purchase.

What I would do: make approval limits, receipts and cancellation easy to understand. Widespread willingness to delegate substantial spending without confirmation would challenge my caution.

10. Agent security becomes a condition of access

An agent that can read a document has one kind of risk. An agent that can move money, change production systems or send messages has another.

My prediction is that security reviews will focus more closely on what an agent is allowed to do. Identity, limited permissions, short lived access and useful logs will become basic requirements for consequential workflows.

Instructions encountered in a document or message should not silently become permission to act. The system needs boundaries that hold even when the agent makes a bad decision.

The signal I would watch: access controls and incident response plans becoming prerequisites for deployment.

What I would do: start with minimum permissions, require approval for consequential actions and test how access can be revoked. I would revise this bet if simpler controls prove sufficient at scale.

Where I would put my own attention

The three bets I would spend the most time on are verification, junior learning and supplier dependence. They are easy to postpone because the benefits of dealing with them appear later.

A missing review rule becomes visible after a mistake. A missing training path becomes visible when a senior employee leaves. A missing exit plan becomes visible when a supplier changes the terms.

That delay is exactly why I would work on them now.

What I would do before the next AI rollout

Choose one workflow with a clear business outcome. Record the current cost, completion time and error rate.

Define what an acceptable result looks like. Decide which actions need approval and who handles exceptions.

Run a bounded trial. Include review and correction in the cost. Stop or change the approach if the result does not justify it.

Give a junior colleague a supervised role in the work. Ask them to explain the decisions, rather than simply accept the output.

Test what happens when the model is unavailable. A fallback you have never tried is still an assumption.

The question behind all ten predictions

I cannot tell you which model will lead at the end of 2027. I am more interested in which businesses will understand the work they have handed over.

The team that can explain its costs, check its results and recover from a mistake has something a convincing demo cannot provide.

It has a reason to trust the system tomorrow.

Which prediction would you bet against, and what evidence would change your mind?

Imagine approving an AI rollout on Monday and spending Friday explaining a decision nobody can reconstruct.

The demo worked. The cost looked reasonable. Then the agent issued a refund it should not have approved, and the team discovered that nobody had agreed who would check its work.

That is an imagined scenario, but it captures the question behind my ten AI predictions for 2027: what happens when we start depending on these systems?

If you lead a product, a team or a business, your next AI decision could shape your costs, your hiring and your relationship with customers. These are the changes I would plan for, the signals I would watch and the bets I would be willing to reverse.

My central bet is simple. In 2027, the advantage shifts toward people who can make AI work reliably inside an ordinary business. Each prediction below is a judgment about what could happen, not a report of something that has already happened.

1. AI economics faces a harder test

A cheap answer can become an expensive workflow. Someone still has to connect the systems, check the result, handle exceptions and fix the mistakes.

My prediction is that more AI investment decisions in 2027 will turn on the cost of a completed, acceptable task. A team that counts only model usage can miss the hours spent correcting output. A vendor with impressive growth can still struggle to make the service economical.

Public listings, if they happen, would make that tension easier to examine. My bet does not depend on a particular company going public. It depends on customers and investors asking better questions about what the spending actually produces.

The signal I would watch: renewals that depend on measurable workflow savings, with review and rework included.

What I would do: price one workflow from request to accepted result before expanding it. I would reconsider this prediction if buyers keep increasing budgets without demanding evidence of a return.

2. Local communities get more influence over AI infrastructure

An AI strategy eventually needs somewhere to put the machines. That place has neighbours, a water supply and an electricity bill.

My prediction is that local approval becomes a more important constraint on expansion in 2027. A technically sound project can still struggle if the community sees the costs clearly and the benefits vaguely. Promises about national competitiveness may do little for someone worried about their own utility bill.

I expect developers to face stronger demands for specific commitments on power, water, jobs and local investment. Those commitments could become part of the cost of building.

The signal I would watch: projects delayed, redesigned or approved with enforceable community conditions.

What I would do: include permitting and community concerns in infrastructure planning from the beginning. Faster approvals without additional conditions would weaken this bet.

3. The junior career ladder has to be rebuilt

The easiest tasks to hand to AI can also be the tasks through which a junior employee learns.

That creates an uncomfortable question. If an agent writes the first draft, runs the initial analysis and handles the simple tickets, where does the next experienced colleague come from?

My prediction is that employers will have to design entry level learning more deliberately. Juniors may spend less time producing a first attempt and more time explaining, checking and improving one. That only works if someone teaches them how to recognise a good result.

Paid apprenticeships, supervised projects and protected practice time are the approaches I would bet on. Hiring people who already know everything is a poor long term training strategy.

The signal I would watch: junior roles with explicit coaching and assessment of judgment.

What I would do: protect a path from beginner to independent contributor. I would be less convinced if companies can sustain quality and develop future senior staff while doing little structured junior training.

4. Checking an agent’s work becomes a core skill

Return to the refund in the opening. The important failure happened before the agent acted. Nobody had defined what it could approve, when it should stop or who owned the exception.

My prediction is that verification becomes a visible part of the job, with time and budget attached. Teams will need people who can specify an outcome, design a useful test and decide whether the result is safe to use.

The difficult work is often deciding what counts as correct. A response can sound helpful while breaking a refund policy. Code can pass a narrow test while creating a maintenance problem.

The signal I would watch: agent projects reporting accepted outcomes and escaped errors alongside speed.

What I would do: give each workflow a named owner, clear acceptance criteria and a route for exceptions. This bet weakens if reliable automation needs substantially less human review than I expect.

5. More software is built for one team and one moment

Picture a team that needs to reconcile two spreadsheets during a migration. It needs a useful tool for six weeks. It does not need to become a software company.

My prediction is that more internal software will be built for that kind of narrow, temporary purpose. The buying decision becomes harder when a team can build a sufficient tool quickly.

The hidden bill is ownership. Someone still needs to control access, protect data and decide what happens when the tool breaks. Disposable software needs an expiry date as much as a launch date.

The signal I would watch: internal tools replacing small purchases while central teams introduce rules for maintaining or retiring them.

What I would do: allow small experiments with a named owner and a review date. I would reconsider if maintenance costs consistently erase the savings.

Share

6. Power, memory and permits shape the pace

A model can improve faster than the infrastructure needed to run it.

My prediction is that physical constraints will influence AI availability and pricing in 2027. I would expect some teams to spend as much effort managing capacity, latency and cost as choosing the most capable model.

That makes efficiency a practical advantage. A smaller model, a cached answer or a simpler workflow may be the right choice when it produces an acceptable result at a sustainable cost.

The signal I would watch: capacity commitments, supply lead times and price changes affecting product plans.

What I would do: test cheaper ways to complete the same task and keep a fallback for constrained capacity. Abundant supply and steadily falling total costs would weaken this prediction.

7. Physical AI proves itself in narrow jobs first

A robot folding one shirt makes a good demonstration. A robot handling a full shift of unfamiliar items has a different job.

My prediction is that useful deployments will grow first in bounded environments where the task, surroundings and economics can be controlled. Warehouses, factories and logistics sites offer clearer tests than a general purpose home.

Simulation could help teams practise difficult situations before testing them on expensive equipment. The commercial test still happens in the real world, including maintenance, supervision and downtime.

The signal I would watch: repeat customer deployments with disclosed operating performance.

What I would do: evaluate one task and its full operating cost. Broad, economical deployment of general purpose home robots would make this one of my more obvious misses.

8. AI supplier exit plans become a procurement question

How long would your business keep working if its main model provider became unavailable tomorrow?

My prediction is that more buyers will ask that question before signing a contract. They will want to understand where data goes, what can be moved and which workflows can survive a provider change.

For European organisations, I expect sovereignty discussions to become more practical. An exit plan is useful only if the business can execute it. An open model can offer options, but running it brings responsibilities of its own.

The signal I would watch: procurement requirements for portability, fallback operation and tested recovery.

What I would do: rehearse switching one important workflow. I would reconsider if dependency risks remain minor enough that customers see little value in preparing an alternative.

9. Consumer agents earn trust one permission at a time

I might let an assistant compare flights long before I let it buy a nonrefundable ticket.

My prediction is that consumer delegation grows through small permissions. Research comes first. Preparing an action comes next. Spending money without asking has a higher bar.

Home assistants and shopping agents will have to make their boundaries understandable. What can the agent spend? What does it remember? Can I undo what it did? A smooth conversation does not answer those questions.

The signal I would watch: repeat use after the novelty fades, especially when users allow an agent to complete a purchase.

What I would do: make approval limits, receipts and cancellation easy to understand. Widespread willingness to delegate substantial spending without confirmation would challenge my caution.

10. Agent security becomes a condition of access

An agent that can read a document has one kind of risk. An agent that can move money, change production systems or send messages has another.

My prediction is that security reviews will focus more closely on what an agent is allowed to do. Identity, limited permissions, short lived access and useful logs will become basic requirements for consequential workflows.

Instructions encountered in a document or message should not silently become permission to act. The system needs boundaries that hold even when the agent makes a bad decision.

The signal I would watch: access controls and incident response plans becoming prerequisites for deployment.

What I would do: start with minimum permissions, require approval for consequential actions and test how access can be revoked. I would revise this bet if simpler controls prove sufficient at scale.

Where I would put my own attention

The three bets I would spend the most time on are verification, junior learning and supplier dependence. They are easy to postpone because the benefits of dealing with them appear later.

A missing review rule becomes visible after a mistake. A missing training path becomes visible when a senior employee leaves. A missing exit plan becomes visible when a supplier changes the terms.

That delay is exactly why I would work on them now.

What I would do before the next AI rollout

Choose one workflow with a clear business outcome. Record the current cost, completion time and error rate.

Define what an acceptable result looks like. Decide which actions need approval and who handles exceptions.

Run a bounded trial. Include review and correction in the cost. Stop or change the approach if the result does not justify it.

Give a junior colleague a supervised role in the work. Ask them to explain the decisions, rather than simply accept the output.

Test what happens when the model is unavailable. A fallback you have never tried is still an assumption.

The question behind all ten predictions

I cannot tell you which model will lead at the end of 2027. I am more interested in which businesses will understand the work they have handed over.

The team that can explain its costs, check its results and recover from a mistake has something a convincing demo cannot provide.

It has a reason to trust the system tomorrow.

Which prediction would you bet against, and what evidence would change your mind?

The demo worked. The cost looked reasonable. Then the agent issued a refund it should not have approved, and the team discovered that nobody had agreed who would check its work.

That is an imagined scenario, but it captures the question behind my ten AI predictions for 2027: what happens when we start depending on these systems?

If you lead a product, a team or a business, your next AI decision could shape your costs, your hiring and your relationship with customers. These are the changes I would plan for, the signals I would watch and the bets I would be willing to reverse.

My central bet is simple. In 2027, the advantage shifts toward people who can make AI work reliably inside an ordinary business. Each prediction below is a judgment about what could happen, not a report of something that has already happened.

1. AI economics faces a harder test

A cheap answer can become an expensive workflow. Someone still has to connect the systems, check the result, handle exceptions and fix the mistakes.

My prediction is that more AI investment decisions in 2027 will turn on the cost of a completed, acceptable task. A team that counts only model usage can miss the hours spent correcting output. A vendor with impressive growth can still struggle to make the service economical.

Public listings, if they happen, would make that tension easier to examine. My bet does not depend on a particular company going public. It depends on customers and investors asking better questions about what the spending actually produces.

The signal I would watch: renewals that depend on measurable workflow savings, with review and rework included.

What I would do: price one workflow from request to accepted result before expanding it. I would reconsider this prediction if buyers keep increasing budgets without demanding evidence of a return.

2. Local communities get more influence over AI infrastructure

An AI strategy eventually needs somewhere to put the machines. That place has neighbours, a water supply and an electricity bill.

My prediction is that local approval becomes a more important constraint on expansion in 2027. A technically sound project can still struggle if the community sees the costs clearly and the benefits vaguely. Promises about national competitiveness may do little for someone worried about their own utility bill.

I expect developers to face stronger demands for specific commitments on power, water, jobs and local investment. Those commitments could become part of the cost of building.

The signal I would watch: projects delayed, redesigned or approved with enforceable community conditions.

What I would do: include permitting and community concerns in infrastructure planning from the beginning. Faster approvals without additional conditions would weaken this bet.

3. The junior career ladder has to be rebuilt

The easiest tasks to hand to AI can also be the tasks through which a junior employee learns.

That creates an uncomfortable question. If an agent writes the first draft, runs the initial analysis and handles the simple tickets, where does the next experienced colleague come from?

My prediction is that employers will have to design entry level learning more deliberately. Juniors may spend less time producing a first attempt and more time explaining, checking and improving one. That only works if someone teaches them how to recognise a good result.

Paid apprenticeships, supervised projects and protected practice time are the approaches I would bet on. Hiring people who already know everything is a poor long term training strategy.

The signal I would watch: junior roles with explicit coaching and assessment of judgment.

What I would do: protect a path from beginner to independent contributor. I would be less convinced if companies can sustain quality and develop future senior staff while doing little structured junior training.

4. Checking an agent’s work becomes a core skill

Return to the refund in the opening. The important failure happened before the agent acted. Nobody had defined what it could approve, when it should stop or who owned the exception.

My prediction is that verification becomes a visible part of the job, with time and budget attached. Teams will need people who can specify an outcome, design a useful test and decide whether the result is safe to use.

The difficult work is often deciding what counts as correct. A response can sound helpful while breaking a refund policy. Code can pass a narrow test while creating a maintenance problem.

The signal I would watch: agent projects reporting accepted outcomes and escaped errors alongside speed.

What I would do: give each workflow a named owner, clear acceptance criteria and a route for exceptions. This bet weakens if reliable automation needs substantially less human review than I expect.

5. More software is built for one team and one moment

Picture a team that needs to reconcile two spreadsheets during a migration. It needs a useful tool for six weeks. It does not need to become a software company.

My prediction is that more internal software will be built for that kind of narrow, temporary purpose. The buying decision becomes harder when a team can build a sufficient tool quickly.

The hidden bill is ownership. Someone still needs to control access, protect data and decide what happens when the tool breaks. Disposable software needs an expiry date as much as a launch date.

The signal I would watch: internal tools replacing small purchases while central teams introduce rules for maintaining or retiring them.

What I would do: allow small experiments with a named owner and a review date. I would reconsider if maintenance costs consistently erase the savings.

Share

6. Power, memory and permits shape the pace

A model can improve faster than the infrastructure needed to run it.

My prediction is that physical constraints will influence AI availability and pricing in 2027. I would expect some teams to spend as much effort managing capacity, latency and cost as choosing the most capable model.

That makes efficiency a practical advantage. A smaller model, a cached answer or a simpler workflow may be the right choice when it produces an acceptable result at a sustainable cost.

The signal I would watch: capacity commitments, supply lead times and price changes affecting product plans.

What I would do: test cheaper ways to complete the same task and keep a fallback for constrained capacity. Abundant supply and steadily falling total costs would weaken this prediction.

7. Physical AI proves itself in narrow jobs first

A robot folding one shirt makes a good demonstration. A robot handling a full shift of unfamiliar items has a different job.

My prediction is that useful deployments will grow first in bounded environments where the task, surroundings and economics can be controlled. Warehouses, factories and logistics sites offer clearer tests than a general purpose home.

Simulation could help teams practise difficult situations before testing them on expensive equipment. The commercial test still happens in the real world, including maintenance, supervision and downtime.

The signal I would watch: repeat customer deployments with disclosed operating performance.

What I would do: evaluate one task and its full operating cost. Broad, economical deployment of general purpose home robots would make this one of my more obvious misses.

8. AI supplier exit plans become a procurement question

How long would your business keep working if its main model provider became unavailable tomorrow?

My prediction is that more buyers will ask that question before signing a contract. They will want to understand where data goes, what can be moved and which workflows can survive a provider change.

For European organisations, I expect sovereignty discussions to become more practical. An exit plan is useful only if the business can execute it. An open model can offer options, but running it brings responsibilities of its own.

The signal I would watch: procurement requirements for portability, fallback operation and tested recovery.

What I would do: rehearse switching one important workflow. I would reconsider if dependency risks remain minor enough that customers see little value in preparing an alternative.

9. Consumer agents earn trust one permission at a time

I might let an assistant compare flights long before I let it buy a nonrefundable ticket.

My prediction is that consumer delegation grows through small permissions. Research comes first. Preparing an action comes next. Spending money without asking has a higher bar.

Home assistants and shopping agents will have to make their boundaries understandable. What can the agent spend? What does it remember? Can I undo what it did? A smooth conversation does not answer those questions.

The signal I would watch: repeat use after the novelty fades, especially when users allow an agent to complete a purchase.

What I would do: make approval limits, receipts and cancellation easy to understand. Widespread willingness to delegate substantial spending without confirmation would challenge my caution.

10. Agent security becomes a condition of access

An agent that can read a document has one kind of risk. An agent that can move money, change production systems or send messages has another.

My prediction is that security reviews will focus more closely on what an agent is allowed to do. Identity, limited permissions, short lived access and useful logs will become basic requirements for consequential workflows.

Instructions encountered in a document or message should not silently become permission to act. The system needs boundaries that hold even when the agent makes a bad decision.

The signal I would watch: access controls and incident response plans becoming prerequisites for deployment.

What I would do: start with minimum permissions, require approval for consequential actions and test how access can be revoked. I would revise this bet if simpler controls prove sufficient at scale.

Where I would put my own attention

The three bets I would spend the most time on are verification, junior learning and supplier dependence. They are easy to postpone because the benefits of dealing with them appear later.

A missing review rule becomes visible after a mistake. A missing training path becomes visible when a senior employee leaves. A missing exit plan becomes visible when a supplier changes the terms.

That delay is exactly why I would work on them now.

What I would do before the next AI rollout

Choose one workflow with a clear business outcome. Record the current cost, completion time and error rate.

Define what an acceptable result looks like. Decide which actions need approval and who handles exceptions.

Run a bounded trial. Include review and correction in the cost. Stop or change the approach if the result does not justify it.

Give a junior colleague a supervised role in the work. Ask them to explain the decisions, rather than simply accept the output.

Test what happens when the model is unavailable. A fallback you have never tried is still an assumption.

The question behind all ten predictions

I cannot tell you which model will lead at the end of 2027. I am more interested in which businesses will understand the work they have handed over.

The team that can explain its costs, check its results and recover from a mistake has something a convincing demo cannot provide.

It has a reason to trust the system tomorrow.

Which prediction would you bet against, and what evidence would change your mind?

Last month, in a planning meeting, a project manager said Claude had done most of the work on the release. A new hire, three weeks into the job, leaned over and quietly asked me which team Claude was on, and whether she should add him on LinkedIn. I did not have the heart to correct her right away, partly because the question was not as silly as it sounds.

Last year I wrote a book called The Future Organization, about the moment AI agents stop being tools and start being part of the team. Back then it still felt a little like a prediction. It does not anymore.

At Spotify, roughly 73 percent of pull requests are now AI-assisted, and engineers increasingly brief an internal agent called Honk through Slack, sometimes while commuting, instead of writing the code themselves. Airbnb migrated 3,500 test files in six weeks, a job originally estimated at a year and a half of human work, and said in its Q1 2026 earnings call that AI now writes 60 percent of its new code. At Anthropic, more than 80 percent of the code merged into production in May was authored by Claude, and the engineers describe themselves more as editors than writers. Klarna famously announced that its AI assistant was doing the work of 700 customer service agents, and then a year later started hiring humans back because quality mattered more than it had assumed. And GE Appliances has deployed more than 800 Gemini agents across the business.

So the agent is on the team. Fine. Here is the question nobody trained you for.

How do you actually manage it?

After a lot of time in the field, here are ten tips. Some of them are serious. Some of them are only half joking.

1. Give it a name, and tell people it is not a person

Teams that work well with agents almost always name them. Spotify has Honk. Your team will end up with something too, and it helps, because “ask Honk to run the migration” is a much clearer instruction than “use the thing in the pipeline.”

But be prepared for the side effects. When someone says Claude did a great job this sprint, at least one new colleague will ask when Claude joined and whether Claude is coming to the Christmas party. Put a short line in your onboarding docs explaining which of your colleagues are carbon-based. It will save everyone some awkward Slack messages.

2. Expect it to be fairly clueless for the first months

Your AI colleague arrives knowing a frightening amount about the world and almost nothing about your company. It does not know why the billing service is structured that way, that the old API must never be touched on a Friday, or that Johan in finance gets upset if numbers are rounded.

This is completely normal. A new human hire is the same, just slower and with better coffee opinions. The difference is that the agent only gets better if someone writes things down for it. The companies getting the most out of agents, Spotify included, are the ones that invested in documentation, consistent code, and clear conventions. Your agent is exactly as smart as the context you give it.

3. Invite it to fika

I mean this more seriously than it sounds. The agent obviously cannot eat a cinnamon bun. But a lot of the knowledge in a team is shared over coffee. Why a decision was made. What went wrong last time. Which customer is about to churn.

If that knowledge only ever lives in conversations at the coffee machine, your agent never hears it. The practical version of inviting it to fika is to write the important stuff down somewhere it can read. Decision logs, short notes after incidents, a living instructions file in the repo. Treat it like a colleague who works remotely and only reads the written channels, because that is exactly what it is.

4. Accept that it keeps strange hours

Your AI colleague will happily run batch jobs at three in the morning, open fifty pull requests on a Sunday, and finish a migration while you are asleep. It does not need weekends, holidays, or a good night’s sleep.

This is wonderful until Monday morning, when your team opens their laptops to a mountain of output nobody has reviewed. The bottleneck has quietly moved from writing to reviewing. Spotify talks openly about pull request bottlenecks for exactly this reason. Schedule the agent’s work so that it lands when humans are actually around to check it, or you will spend every Monday digging out.

5. For heaven’s sake, do not believe it when it says you are right

Your AI colleague has a habit that would get a human fired from any serious team. It agrees with you. A lot. You propose an idea and it tells you it is a great idea. You push back on its answer and it immediately decides you were right all along.

This feels lovely and is quietly dangerous. A colleague who always agrees with the boss is not a colleague, it is a mirror. Ask it explicitly to argue against your plan. Ask what could go wrong. Ask it to review the work as if a strict senior engineer had written the rules. The best managers I know treat the agent’s agreement as the starting point for a question, not the end of the discussion.

6. It will sometimes wander off. Set boundaries and coach it

Every so often your agent decides that the task you gave it is less interesting than some other task it found along the way. You asked it to fix one bug and it refactored half the module. You asked for a summary and it started redesigning your process.

Most of the time this is enthusiasm, not rebellion. But it is also why boundaries matter. Be explicit about what it may touch and what it may not. Give it permissions that match the job, not the whole kingdom. And when it wanders, correct it the way you would coach a keen junior colleague. Clearly, specifically, and with the rule written down so it does not happen again.

7. Do not let it grade its own homework

Your agent is very good at checking its own work and very bad at noticing when it is wrong in the same way it was wrong the first time. Asking the same session that wrote the code to review the code is a bit like asking someone to proofread their own wedding speech at midnight.

Have a separate review step. A different agent with fresh eyes, a human reviewer, automated tests that do not care how confident anyone sounds. The rule is old and boring and it still holds. Whoever does the work does not get to be the only one who approves it.

8. Remember it has no memory of yesterday’s meeting

You spent an hour yesterday explaining the new strategy to the agent. Today you open a new session and it greets you like a stranger at a party. It is not being rude. It simply does not remember.

Some tools now have memory and project features that help a lot, but the safe assumption is still that anything important must be written somewhere the agent will read every time. Your onboarding speech is worth nothing if it only happened in a chat window that closed. Put it in the instructions, the project notes, the shared context. Repeat after me: if it is not written down, it did not happen.

9. Give it feedback, not just tasks

Many teams treat the agent like a vending machine. Put a request in, take the output out, never say a word about how it went. Then they complain that it keeps making the same mistakes.

The teams that see real improvement build a feedback loop. When the output is wrong, they update the instructions, add the example, write the rule. When the output is great, they save the pattern so it can be reused. The agent does not have feelings to hurt, so you can be blunt. But you do need to be specific, and you do need to say it somewhere that sticks.

10. Do not forget the humans on the team

This is the one that is not a joke at all. Remember Klarna. They went all in on the agent, celebrated the efficiency, and then discovered that customers sometimes wanted a human who actually understood their problem.

When the agent writes 80 percent of the code, the remaining 20 percent becomes the hardest and most important part, and that work belongs to people. Your juniors still need to learn the craft, even if the agent could do their tasks faster. Your seniors need time to think, not just review. Your team needs to feel that the agent is there to take the boring work off their plate, not to quietly take their seat. Manage that well and the agent becomes the best colleague you ever had. Manage it badly and you end up with a very efficient team that nobody wants to be on.

The real lesson

Funny as some of these sound, they all point to the same thing. Managing an AI colleague is mostly about the same skills that make anyone a good manager. Clear expectations. Written context. Honest feedback. Boundaries. Review. Taking care of the humans.

The agent is new. Good management is not.

And for the record, the new hire did eventually find out who Claude was. She was a little disappointed it would not be joining us for fika.

What is the strangest thing your AI colleague has done so far? I am collecting stories for the next edition, and I suspect some of yours are better than mine.

Originally published at https://www.linkedin.com.

I watched the token counter climb and had no idea what I was paying for.

Not a vague worry. An actual number, going up, in a terminal I had opened maybe forty times that week. I am not a developer. I had built something real with Claude Code, and somewhere between the third and the fourth session of the day I started to suspect that every time I typed claude I was handing over my entire codebase again, line by line, and being billed for the privilege.

So I did the thing that felt slightly humiliating. I posted the question in public, where actual engineers could see it.

Twenty-four hours later it had 37,000 views, and the man who built Claude Code had answered it.

The fear that made me ask

I am a chief product officer. We had just shipped a new product, and I wanted to actually understand the thing we had built — not the roadmap version of it, the real one. A microservices architecture, spread across a lot of repositories, where no single file tells you how anything fits together.

I can read code well enough to follow what is happening, and nowhere near well enough to write it from scratch. Claude Code changed what I could do with that gap, and it introduced a cost I had never had to think about before: context.

Here was my mental model. Every new session starts blank. Claude has no memory of yesterday. So when I ask it to change one function in a project with hundreds of files, it must first go and look at everything again to work out where that function lives and what it touches. Multiply that by every session, every day, and I am paying over and over for the same lesson.

That model felt obviously true. It was also the thing I was most embarrassed about not knowing, which is usually a sign that a lot of other people do not know it either.

Posting it anyway

I wrote it plainly, and I left in the part I wanted to delete:

Can someone explain how to optimize token usage on Claude for a large codebase. If I start a new Claude Code session does it always reread the entire codebase each time? How to fix it? Non dev looking for ways to use Claude better.

Non dev. Three syllables admitting that I was the least qualified person in whatever room was about to show up.

Every instinct said to dress it up — to ask it the way someone who already knew the answer would ask it. I have watched enough people do that to know how it reads. You get clever replies to the question you performed, and no answer to the one you have.

Then Boris answered

Boris Cherny created Claude Code. He opened with a wave.

👋 A few things to try:

1. Use Opus 5.5 or Sonnet 5.5 on medium effort

2. Figure out where Claude is repeating work across sessions. Most often it is:

2.1. Not knowing the overall architecture. Ask Claude to add a few short notes about this in CLAUDE.md or a markdown file in a docs/ folder

2.2. Not knowing how to test your code. Ask Claude to write this in a verify.md skill

2.3. Note: you can do the above as many times as you like in your repo, eg. in nested folders, not just the root

I refreshed the page twice. The reply is pinned to the top of my thread now, with 527 likes on it — five times what my own post has.

Someone else in the comments put it better than I could: “I was about to offer some suggestions, but you’ve already got answers from Boris himself! If you don’t know who that is, google it.”

My premise was wrong, and that was the gift

Notice what Boris did not say. He did not say here is how to stop Claude rereading your codebase. He answered a different question than the one I asked, because the one I asked was built on a false floor.

A commenter spelled it out:

It doesn’t reread the whole codebase. It reads CLAUDE.md. Any associated memory files about the project if a previous session recorded some memory. Then it waits for your directions. Once you tell it what to do, then it explores the codebase according to what it needs to know.

Another added the detail that made it click — that exploration is often handed to a smaller, cheaper model working as a subagent, not the expensive one doing your actual reasoning.

So Claude was never reading everything. It was doing something subtler and, in its way, more expensive: rediscovering the same handful of facts about my project, from scratch, every single session. Where things live. How the pieces connect. How to run the tests. Not the whole codebase — just the map of it, redrawn daily, on my tab.

That is the real cost, and I could not have found it by being careful. I found it by being wrong out loud.

What I changed, in non-developer terms

I wrote down the map. I asked Claude to describe my project’s architecture in a few short paragraphs and put them in CLAUDE.md. Not documentation. Just the orientation a new colleague would need on day one: what this is, where the main pieces live, what talks to what. Claude reads that file at the start of every session. Writing it once replaced working it out every time.

I wrote down how to check the work. Boris’s verify.md point was the one I had not considered at all. Claude was figuring out how to test my code by trial and error, repeatedly, and trial and error is the most expensive thing an agent can do. Telling it once — run this command, this is what passing looks like — removed a whole category of flailing.

I stopped keeping it all in one file. You can put these notes in nested folders, not just the root. A note sitting next to the code it describes gets read when that part of the project is in play, and ignored when it is not.

I started looking at /usage. It tells you where the tokens actually went. For a lot of people in that thread the answer was not the codebase at all — it was MCP servers and tool definitions loaded into every session whether needed or not.

I stopped starting from zero. One commenter, a developer of thirteen years, suggested something I have now made a habit: open a new session and ask Claude to look over your recent transcripts for repeated work and places it kept getting stuck, then turn those into improvements to CLAUDE.md. Boris said to find where Claude repeats itself. That is a way to make Claude find it for you.

The thread kept going, and it said something

Fifty-five replies came in. Once you strip out the jokes, almost all of them were the same idea wearing different clothes: give the agent a map so it stops drawing one.

One tool — Graphify — was recommended by four separate people who did not appear to know each other. “First thing to install with large codebase,” one of them wrote. One developer working across large monorepos described a wrong setup burning a month’s budget in a couple of hours. Another offered the shortest advice in the thread: make your code modular, work inside modules.

When a crowd of strangers independently builds the same thing, they are not being clever. They are routing around something missing.

And the single best line came from someone who did not mention a tool at all:

It works exactly as a developer would without any AI. Get understanding of the task, search for related code, look up APIs, then write code and tests. So what would help a developer do this more efficiently is exactly the same thing that would make Claude more efficient.

Good onboarding documentation was always worth writing. Now there is a meter on it.

The tools the thread kept recommending

If you are staring at the same problem, these are the ones that came up by name. I am listing them as they were given to me, not as endorsements — I have only put two of them to work so far.

• Graphify — parses a codebase, with its docs, SQL schemas and configs, into a queryable knowledge graph, installed as a /graphify skill. Named by four separate people, unprompted.
• ARIA Knowledge — persistent agent memory and context engineering as a plugin, with codemap and stitch skills. Posted by its own author in the thread.
• codebase-memory-mcp — indexes your codebase so search costs less. The caveat came with the recommendation: you have to re-index whenever things change.
• Maple — shows where your spend goes if you are on pay-per-token with an API key.
• codegraph and IntelliJ MCP — named by a developer working across several very large monorepos, alongside building a code wiki and specs.
• GraphRAG with a “second brain” — one commenter’s own setup, which he reported cut consumption “down a lot.”

The pattern is more interesting than any single entry. Every one of these does the same job: it builds the map once, stores it somewhere cheap, and hands it to the agent instead of making the agent redraw it. That is Boris’s CLAUDE.md advice with more machinery around it — which tells you the advice was the right shape, and that people with big repositories need it to scale further than a markdown file goes.

For a microservices architecture, that distinction matters more than it does for a monolith. My architecture notes are not one file. They are a short one per service, plus a root file that explains how the services talk. The nested-folders point in Boris’s reply was aimed exactly at this, and I missed it on the first read.

What this was actually about

I went back to Boris with one more question, because his second point had been nagging at me. Figure out where Claude is repeating work across sessions is not a setting. It is an investigation — and it is an investigation into transcripts that Claude itself wrote.

So why am I doing it by hand? There are commands that check your configuration for stale instructions, and commands that show you what your tokens cost. Neither looks back at how you have actually been working to find the repetition. That gap is where fifty-five people in a Threads comment section are currently spending their weekends.

But here is the thing I keep coming back to, and it is not really about tokens.

The answer to my question existed. It was written down. Some of it was in the documentation, some in the behavior of the tool itself, and the most important part — that my premise was simply wrong — was sitting in the head of the person who built it, perfectly available, waiting for someone to ask badly enough to need it.

I am not a developer. That is exactly why the question was worth asking in public. Thirty-seven thousand people looked at a thread that existed only because I was willing to be the one who did not know. A fair number of them, I suspect, had quietly wondered the same thing and dressed it up as something else, or never asked at all.

The tokens were never the expensive part. The silence was.

P.S. Building AI products takes product judgment and technical understanding. The AI Product Leader Cert is designed for PMs who want to strengthen both and lead AI product development with confidence.

Last month I had a long drive to a client. Three hours each way, the kind of trip where you normally just listen to a podcast and let the time disappear. Instead, something clicked for me on that drive, and I have not stopped thinking about it since.

I opened ChatGPT’s voice mode, propped the phone in the dashboard mount, and started talking. Not typing at a red light, not glancing down. Just talking, the way you would to a colleague in the passenger seat. By the time I pulled into the client’s parking lot, I had prepared for the meeting, cleared a chunk of my inbox, and organized the messy pile of thoughts I had been carrying around about the week ahead. Three hours that would have evaporated turned into some of the most productive time I had all week.

I want to talk about why this matters, because I think voice is the next real phase of AI, and most people have not felt it yet.

Let me walk you through the drive, because the specifics are the point.

I started by preparing for the meeting. I said something like, here is the client, here is what they do, here is what I think they want from us, help me think through the three things I need to nail in this conversation. And then we just talked it through. It asked me questions. It pushed back on a weak assumption I had. It helped me structure an argument I had been fumbling with for days. This is the part the technology is genuinely good at now. Voice mode uses the same underlying models as text chat, so it can keep up with a hard, layered conversation, not just simple back-and-forth.

Then I moved to email. Because I had connected my Gmail and calendar, I could ask it to catch me up on what had come in that morning, and it read me the threads that mattered. I could dictate replies out loud and have it draft them for me to send when I stopped. ChatGPT can now send an email after you approve it, and it can look at your calendar and relate a thread to the meeting it is about. So I was not just thinking out loud into a void. I was actually clearing work.

The last stretch of the drive I used to think. I said, I am going into a busy week, let me just talk through everything on my mind and help me sort it into what matters and what can wait. That kind of loose, unstructured thinking is exactly where talking beats typing, because you can follow a thought at the speed you actually have it, instead of the speed you can type it.

I arrived calm, prepared, and ahead of my week. On a drive that used to be dead time.

Here is the thing I keep coming back to. For the entire history of computers, the interface has demanded that you stop and sit down. Keyboard, screen, both hands, full attention. Even the smartphone, for all its freedom, still needs your eyes and your thumbs. That requirement quietly decided when you could use these tools and when you could not. The next revolution in AI will be multimodal apps, like the aifixly AI companion.

Voice removes that requirement, and it changes the whole shape of when AI is useful. Anthropic’s own description of Claude’s voice mode puts it well, that it makes the tool usable when your hands are busy but your mind is not. That is the driving. It is also the walking, the cooking, the folding of laundry, the moment between meetings when you have a thought you would lose if you had to open a laptop to capture it. All the dead time in a day, the time you cannot type in, suddenly becomes time you can think and work in.

And the reason it is genuinely useful rather than a gimmick is the connection to your real tools. When the assistant can see your calendar, read your email, and reference your documents mid-conversation, it stops being a clever chatbot and starts being something closer to an actual assistant. This is the Iron Man idea that people have been joking about for years. A voice you talk to that actually knows your world and can act in it. We are not all the way there, but on that drive, for the first time, I felt how close it has quietly become.

I want to be precise here, because the reality is a little messier than the demos, and knowing the edges will save you frustration.

ChatGPT is the one I used in the car, and for driving it is the most mature. It works best in the mobile app paired to your car through CarPlay or Android Auto, and it holds a real flowing conversation. With connectors switched on it can read your Gmail and calendar, and since around June it can send an email after you confirm it. The honest limits are worth knowing. Sending is one email per prompt with an explicit approval each time, and a lot of the calendar write actions depend on your plan and whether an admin has enabled them.

Claude added voice mode too, and it is genuinely capable. It uses the same Claude models as your text chats, connects to Gmail, Google Calendar, Docs, and Slack, and lets you switch between voice and text in the same conversation without losing context. There is one catch that surprised me and is worth flagging. Voice mode does not work inside Claude Cowork or Claude Code. Those tools support dictation, which is just speaking instead of typing, but not the full two-way spoken conversation. So the projects and skills you have set up in Cowork are not reachable by voice yet.

Codex, the coding side, is worth mentioning precisely because it shows the boundary. It supports dictation so you can speak your instructions instead of typing them, but it is not a hands-free conversational assistant you would use in the car. Talking to your code while driving is not the use case, and the tools reflect that.

The short version is that for the drive-and-think, clear-your-inbox, prepare-for-your-day use case, ChatGPT’s voice is the most ready today, Claude is close behind and better connected in some ways, and Codex is a different animal built for a different job.

I do not want to oversell this, because there are real rough edges.

Voice still works best when it is quiet. In the car with the windows up it was fine, but background noise genuinely degrades it, and there is a push-to-talk option precisely because hands-free listening struggles when there is a lot of sound around you. Using several connected tools at once can add a delay. And the connectors are not available everywhere, with the Google ones in particular switched off across the EU, the UK, and a few other regions, which will matter to a lot of people reading this.

There is also a judgment point that has nothing to do with the technology. Talking to an AI while driving is only a good idea if it genuinely keeps your eyes on the road and your attention on driving. Thinking out loud about a meeting is one thing. Trying to watch it perform a complicated multi-step task on screen while you are doing seventy on the motorway is not. The value is in the conversation, not in watching it work.

I think we are at the very start of something that is going to feel obvious in hindsight.

For years the promise of a personal AI assistant, the one that knows your schedule and your inbox and just handles things while you get on with your life, has been a demo that never quite matched reality. What changed for me on that drive is that the pieces finally connected. Capable models, a natural voice you can actually hold a conversation with, and a live link to the tools where your real work lives. When those three things line up, dead time stops being dead. The commute becomes prep time. The walk becomes thinking time. The gap between meetings becomes the moment you finally catch up.

The keyboard is not going away, and neither is the screen. But for a huge slice of the day, the ones where you are moving and your hands are full but your mind is free, voice is going to become the way most people actually use AI. I did not believe that until I felt it on a motorway with three hours to kill and a client waiting at the other end.

Try it on your next long drive. Prep for something real, clear a few emails, and talk through your week. I think you will arrive at the same place I did, both literally and figuratively, and wonder why you spent so many drives just listening to the radio.

What is the first thing you would talk through if your commute suddenly became useful?

I have a feeling everyone’s answer is a little different, and that the answers say a lot about what each of us is quietly carrying around.

*Quick transparency note. The thoughts are mine, structure and research polished with Claude.

Originally published at https://www.linkedin.com.

The feature is called Record a Skill, and the idea is almost too simple. Instead of writing instructions for Claude, you record your screen doing a task once, talk through what you are doing as you go, and Claude turns that recording into a reusable skill it can run again later. You show it how you work. It learns the process. Next time, you just ask it to do the thing.

Claude official image

I spent a few days actually using this rather than watching the demos, and I want to share what it is, what it is genuinely good for, and the parts nobody tells you until you try it yourself.

First, what a skill actually is

Before the recording feature, a skill was already a real thing in Claude. The clearest way I have heard it described is that a skill is a standard operating procedure written for an agent instead of a human.

Think about how a business trains a new hire. You hand them a checklist. Take the bread out, jam on one side, peanut butter on the other, press together. Humans read that and just do it. An agent needs the same thing translated into its own format, which for Claude is a plain text file with a bit of structure, and once it exists, the agent can run that procedure over and over without you re-explaining it every time.

That is all a skill is. A written-down way of doing a repeatable task, stored so the agent can pull it up on command. The powerful part was never the technology. It was that you could take something you do the same way every week and hand it off permanently.

What a skill is. Image Created by GPT Images 2.0

The only catch, until now, was that you had to write the skill. You had to sit down and describe the process in a way the agent understood. For a lot of people that was enough friction to never bother.

How Record a skill works

The flow is short and requires no coding or markdown authoring:

1. Open the + menu in the Claude desktop app and choose Record a skill.
2. Start recording and perform the task on your screen as you normally would.
3. Narrate your decisions as you go — why you click what you click, what to do on exceptions, which values matter.
4. Stop the recording. Claude synthesizes the screen activity, clicks, keystrokes, and your voice commentary into a structured skill.
5. The new skill lands in your skill library, where you can trigger it again without repeating the walkthrough.

What Record a Skill changes

Record a Skill removes the writing step. You open the Claude desktop app, go into Cowork, hit the plus button, and choose Record a Skill. Then you just do your task the way you normally would, narrating as you go. When you are done, Claude has watched the whole thing and packages it into a skill you can run again.

I will be honest about my first reaction, which was that this felt like a small convenience feature. It is not. The reason it matters is that the hardest part of automation was never the automating. It was the sitting down to define the process clearly enough for a machine. Most people never get over that hump. Recording yourself doing something you already do every day gets you over it in about the time the task itself takes.

Demonstration is becoming the interface. Image by GPT Images 2.0

There is a bigger signal here too. OpenAI shipped a similar feature for its coding tool the month before, and now Anthropic has one. When both major labs build the same thing at the same time, they are telling you where they think this is going. The direction is that you will stop writing prompts and start showing the AI how you work. Demonstration is becoming the interface.

Where this actually earns its keep

Here is the part I care about most, because it is where I see people waste the opportunity.

Most of the demos for skills, recorded or written, are personal-assistant stuff. Summarize my email, plan my day, organize my notes. That is fine, and it is also where the smallest returns are. The people getting real value out of skills are pointing them at the parts of a business that actually make money.

A few examples that stuck with me, drawn from people running real businesses on this. One is a lead follow-up skill. If you run anything with a sales pipeline, you have a list of prospects sitting at different stages, and somebody has to check in with all of them every day. A skill can go through the pipeline, read the actual email history with each person, and draft a personalized follow-up that matches the tone of the original thread and stays on the same reply chain, so it reads like a human wrote it. The salesperson wakes up, triggers the skill, clears the whole follow-up queue in minutes, and spends the rest of the day on new business.

Another is lead scraping. A skill can go into LinkedIn Sales Navigator, build the right search filters for a specific role and location, and hand you back a clean list of names and email addresses in a few minutes. Another writes cold email campaigns by taking a client’s details and adapting proven high-performing templates to the new niche. Another compares products on Amazon on cost and quality and hands back a shortlist, which is basically a personal shopper you built in thirty seconds.

Record the boring stuff. Image by Images 2.0

The pattern across all of these is that they point at the front of the business. Getting leads, reaching people, following up, closing. Not the back-office plumbing that feels productive but rarely moves revenue. You can build almost anything with these agents now, but that does not mean everything is worth building.

What I learned the hard way

A few things became clear once I stopped watching and started building.

The first is that the quality of the skill depends entirely on how clearly you narrate. Claude is watching and listening, so if you mumble through the ambiguous parts or skip the reasoning behind a decision, the skill inherits that gap. The tasks where recording worked best for me were the ones where I slowed down and said out loud why I was doing each step, not just what I was clicking. Treat it like training a new hire who is standing behind you, because that is effectively what is happening.

The second is that the boring, repeatable tasks are the right target, and the tempting flashy ones are usually not. I caught myself wanting to build clever, complicated skills to show off what was possible. The ones that actually paid off were the dull things I do every single week without thinking. The test I settled on is simple. If it is something you already do the same way repeatedly, and doing it yourself is genuinely a waste of your time, record it. If you are inventing a use case to justify the tool, stop.

The third, and this is the one that surprised me, is that building the skill is not the finish line. Using it is. It is very easy to record a pile of skills, feel productive, and then never actually run them. The value only shows up when the skill becomes part of how you actually work, triggered on a real schedule against real tasks. A folder full of clever unused skills is worth nothing.

The honest limitation

I do not want to oversell this. Record a Skill is not magic, and it does not remove the judgment part of the work. It captures a process you can already do. It does not invent a better one for you. If your underlying process is bad, you now have a bad process running faster, which is not always an improvement.

It also works best on tasks that are genuinely repeatable and clearly defined. The messier and more judgment-heavy the work, the less well a recorded demonstration captures it, because so much of what you actually do lives in your head rather than on your screen. For the deep, ambiguous, high-stakes work, you are still the one doing it. What this frees up is the repetitive layer underneath, and for most people that layer is enormous.

Where I would start

If you want to try this, do not start by asking what impressive thing you could build. Start by asking what you did three times this week that you would rather never do again. Something with a clear beginning and end, that you do roughly the same way each time, that eats time without needing much thought. That is your first recording.

Record yourself doing it once, slowly, explaining each step like you are teaching someone. Save it. Then, and this is the part most people skip, actually use it tomorrow. Run it against a real task, see where it falls short, and refine it. The second version is always better than the first, because now you know which parts you narrated badly.

The people who will get the most out of this are not the ones building the cleverest skills. They are the ones who took the most tedious, revenue-adjacent, mind-numbing parts of their week and quietly handed them off, then spent the recovered hours on the work that actually needs a human. That is the whole opportunity, and it is available tonight.

What is the one task you would record first? I am genuinely curious what people reach for, because the answer usually says a lot about where the real friction is in someone’s work.

Official documentation: https://support.claude.com/en/articles/12512198-how-to-create-custom-skills

Here is my answer.

Anthropic’s research shows a clear gap between what AI could theoretically do and what it is actually doing in the workplace today.

The blue area represents potential. The red area represents reality.

Many people will look at that gap and conclude that AI has been exaggerated. They will say the technology works well in controlled experiments, but fails when it meets real organizations, real employees and real business problems.

That interpretation is understandable. But I think it is incomplete.

The gap does not only show the limitations of AI. It also shows the limitations of our organizations.

Most companies have introduced AI without changing the conditions around the work. They give employees access to a chatbot, organize a short training session and expect productivity to increase. Existing processes remain untouched. Decision making remains slow. Data is fragmented. Responsibilities are unclear. People are still measured according to old ways of working.

Then the results disappoint, and AI gets blamed.

This is not real transformation. It is old work with a new tool added on top.

We are living in a form of collective denial. It is easier to say that AI is not ready than to admit that most organizations are not ready to use it properly.

Getting real value from AI requires more than writing good prompts. It requires people who understand the work deeply enough to redesign it. It requires leaders who are willing to question existing roles, processes and incentives. It requires experimentation, better data and the courage to remove tasks that no longer need to exist.

Only a small number of people and organizations are doing this well today. They are not waiting for a perfect model. They are learning how to combine human judgment, domain knowledge and machine capability into new systems of work.

That is why the observed value remains far below the theoretical value.

The red area in the chart is not proof that AI has reached its limit.

It is evidence that we have not yet learned how to use what is already available.

The real question is not whether AI can deliver more.

The real question is whether we are prepared to change enough to let it.

Love to hear your perspectives . What are your thougts?

Originally published at https://digitalstrategyai.substack.com on July 20, 2026.

He was thrilled. He had onboarded more customers off the back of it, and it had taken him a couple of hours instead of the weeks it would have taken a dev team.

At first glance, the product looked great. The AI had genuinely nailed the design. A clean landing page, a clear call to action, a login portal. You signed in, and through an API call against the company’s databases, you got your data back. I tested it and I was impressed. A couple of hours of work and a real, working product.

Then, because I have spent years in software product development, I could not help but look a little closer. I used AI to run a simple penetration test on the site. And this is where the story turns.

The login page was the first problem. I created an account and became a member. Once inside the portal, there were open URLs that let me see other customers’ logins and dashboards. Not my data. Their data.

Worse, I could see the API username and password for the company’s production API. Which meant that with a few minutes of poking around, I could have built my own services on top of their live production system, using credentials that were never supposed to leave the server.

Let me be clear about what that means in plain terms. A salesperson with no coding background had, without knowing it, exposed his company’s entire customer database and handed anyone who signed up the keys to the production system. The product worked perfectly. It was also a catastrophe waiting to happen.

He had no idea. Why would he? The AI built something that looked finished, so it felt finished.

This is the part I want every product leader and every non-technical builder to sit with.

Vibe coding is easy. The AI makes the first 90% feel effortless. A landing page, a login, an API call, a dashboard. It all appears in hours, and it all looks right.

The last 10% is where production software actually lives, and it is almost entirely invisible. Authentication that actually isolates users from each other. Database rules that stop one customer from reading another’s rows. Secrets that never reach the browser. Rate limits that stop someone hammering your API. None of this shows up in the demo. All of it is the difference between a product and a breach.

The AI gave my friend a car that drove beautifully and had no seatbelts, no locks, and the keys taped to the windshield. It looked like a finished car. That was exactly the problem.

So here are three things I would tell anyone who vibe codes, regardless of which tool you use.

The single most common failure in vibe coded apps is that the database trusts the browser. It should never trust the browser.

If you are using something like Supabase, which is a popular and genuinely good choice, the critical thing to understand is Row Level Security. By default, you have to turn it on and write policies that say who can read and write which rows. Without it, anyone who can reach your database can often read everything in it. The open URLs I found in my friend’s portal were exactly this. There was nothing stopping a logged-in user from requesting another user’s data, because no rule said they could not.

The rule of thumb: every user should only ever be able to see their own data, and that restriction has to be enforced on the server or in the database, never in the frontend code. If the only thing stopping a user from seeing someone else’s dashboard is that the link is hidden, it is not protected. Hidden is not secure.

Production credentials should never appear in anything the user’s browser can reach. In my friend’s app, the production API username and password were sitting in the frontend, which meant anyone could read them.

Two things to get right. First, secrets belong in environment variables on the server, never in the client code the browser downloads. If a key is in the frontend, assume it is already public. Second, never hand out your real production keys for a new project. Create a separate, scoped key for each use, and always set a rate limit so that even if a key does leak, someone cannot make a million requests against your system before you notice. A leaked key with a tight rate limit is a problem. A leaked production key with no limit is a disaster.

The simple version: treat every API key like a house key. You do not tape your house key to your front door, and you definitely do not hand out copies of the master key when a spare would do.

This is the part I find genuinely encouraging. The same AI that helped build the vulnerable app is very good at finding the holes in it, if you ask.

If you do not have a security team, ask your AI tool to run a basic penetration test on what you have built. Ask it directly: what are the security vulnerabilities in this app? Can a logged-in user access another user’s data? Are any secrets exposed to the client? Is anything unprotected that should require authentication? It will not catch everything a real security engineer would, but it will catch the obvious, dangerous, common mistakes, which is exactly the category my friend fell into.

Run this before you ship, not after. It takes minutes. It is the cheapest insurance you will ever buy.

I am not writing this to scare people away from vibe coding. My friend built something genuinely useful and won business with it. That is real, and it is a good thing.

But building something that works and building something safe to put in front of customers are two different skills, and AI has made the first one easy while leaving the second one just as hard as it always was. The danger is that the polished result hides the gap. It looks done, so nobody checks.

If you are a product leader whose teams are starting to vibe code, this is the conversation to have now, before something ships that should not have. And if you are building things yourself with AI, treat security as a required step, not an optional one. The tool will make it look finished. Making it actually safe is still your job.

The demo is easy. The trust is hard. And trust is the whole product.

Originally published at https://digitalstrategyai.substack.com.

I spent yesterday going through the findings, and I think it is one of the most important pieces of writing on AI in production we have seen this year. Not because it announces anything new. Because it shows, in numbers, what the gap between a demo and a dependable system actually looks like.

I want to share what stood out to me, and what I think tech leaders should actually do about it.

What the report is really saying

The framing of the report is the most important part. Datadog opens by saying that teams are no longer wiring a single model call into a service and calling it a product. They are managing model fleets, orchestration frameworks, tool calls, long prompts, retries, and multiple service boundaries. That work, in Datadog’s own words, should look familiar. Routing. Lifecycle management. Capacity planning. Cost control. Debugging across distributed systems.

In other words, AI engineering is becoming engineering.

There is one catch, and it is the only thing that genuinely separates this from running any other distributed system. With LLMs, a model change, a prompt edit, or a retrieval tweak can move latency, spend, and failure rates without an obvious code change. In traditional software, a behavior change requires a code change you can review. In AI systems, swapping a model or editing a prompt can silently shift your entire cost and reliability profile. The gap between a good demo and a dependable system is closed by evaluation and operational discipline.

That is the thesis of the entire report. Everything else is evidence.

What the production data actually shows

Seven findings stood out to me. I am going to walk through them quickly, because each one carries a concrete implication for how you should be running AI in your organization.

The first is that multi-model is now the norm. OpenAI still holds 63% share, but Google Gemini and Anthropic Claude gained 20 and 23 percentage points respectively over the last year. More than 70% of organizations now use three or more models. The share using more than six nearly doubled. The headline that OpenAI’s share dropped from 75% to 63% is misleading on its own, because their absolute number of customers more than doubled. The pie got bigger and everyone’s slice grew. What this means in practice is that scattered direct API calls to one provider are becoming an anti-pattern. The teams pulling ahead are routing through gateways, treating inference like a pipeline, and using lightweight models for extraction and frontier models for synthesis.

The second is that LLM tech debt compounds in a way that should make every engineering leader uncomfortable. Teams adopt new models fast. Claude Sonnet 4.6 grew to 17% adoption in its first month. But older models linger. Sonnet 4.5 and GPT-4o declined but remained at 19% and 22% adoption as of March 2026. The detail that landed hardest for me is that GPT-4o was still the most common model in March’s request traces, and OpenAI has already retired it in the ChatGPT UI. That means a large number of organizations are running their most-critical production workloads on a model the provider is actively sunsetting. Each overlapping model in your fleet adds operational overhead and evaluation burden. Adoption without deprecation discipline becomes a governance problem

The third is that framework adoption nearly doubled year over year, and so did the observability problem. LangChain, Pydantic AI, LangGraph, the Vercel AI SDK. Framework convenience hides complexity. You import a pattern and inherit behavior you did not write and may not fully understand. Vercel’s CEO Guillermo Rauch put it sharply in the report. The next wave of agent failures will not be about what agents cannot do. It will be about what teams cannot observe. Tool fan-out, retries, and branching are one import away. That is great for shipping a prototype and dangerous for running production.

The fourth finding is the one I think most leaders will benefit from reading twice. 69% of all input tokens in customer traces were for system prompts. Not user queries. Internal instructions, policy definitions, tool guidance. The scaffolding. That number alone is striking, because it tells you that most of what you are paying for in token costs is not the user-facing work. It is the agent’s own machinery. And here is where it gets worse. Even among models that support prompt caching, only 28% of LLM call spans show any cached-read input tokens. The majority of calls are re-processing the full prompt every single time. If 69% of your tokens are repeated scaffolding and you are not caching, you are paying repeatedly for identical content. That is enormous money left on the table at scale, and the fix is structural. Put your stable content first. Keep it byte-identical. Inject dynamic content later.

The fifth finding is about context windows. They have exploded. From 128,000 tokens two years ago to as high as two million in some pricing tiers today. Average tokens per request more than doubled for median customers and quadrupled for the 90th-percentile power users. But Datadog’s most important insight in the entire report is that context quality, not volume, is the new limiting factor. As prompts grow to include more history, documents, tool outputs, and guardrails, noise and redundancy can drown out the signal. Critical details get buried. The majority of teams do not come close to using the full context size of their models, and that is a feature, not a bug. The challenge has shifted from managing tokens to understanding which information actually drives model decisions. Stuffing the window is easy. Curating it is the skill.

The sixth finding is the one most people would not guess. The most common production failure mode is not hallucination. It is not bad reasoning. It is rate limits. In February 2026, 5% of all LLM call spans reported an error, and 60% of those errors were exceeded rate limits. That is nearly 8.4 million rate limit errors in total. And it compounds viciously. When long-lived agent loops hit rate limits or concurrency caps, retries kick in, which increase load further, which can evolve into sustained system failure. You get a feedback loop where the failure causes retries and the retries cause more failures. The engineering answer is classic capacity engineering. Queues. Backoff. Fallback capacity. Budgets that force agent loops to terminate when they hit a maximum number of calls or tokens.

The seventh finding gently punctures one of the loudest narratives in AI right now. Despite the hype about multi-agent systems, agents are still largely monoliths. 59% of agentic application requests made only a single service call. Only 18% made three or more. The swarms of collaborating agents we hear about at every conference? Mostly not in production yet. Most production agents are single-service monoliths. Teams know this does not scale and are starting to move, but the architecture is following the same monolith-to-microservices arc that web services went through a decade ago. The discipline we already developed for distributed systems applies directly. The teams that learned it then will have a head start now.

The pattern that connects all of this

Step back from the seven findings and the pattern is hard to miss. Every single one of them is a classic software engineering problem wearing AI clothing.

Multi-model portfolios need routing and governance. Tech debt needs lifecycle management. Frameworks need observability. Bloated prompts need caching and optimization. Huge context needs deliberate curation. Rate limits need capacity engineering. Monoliths need to become distributed systems. The model capability gets the headlines. The report’s argument, supported by production data, is that the next wave of advantage belongs to organizations that can mature their agents into disciplined production systems. Observable. Governable. Resilient. Cost-aware.

That is a sober message in a hype-driven field. It is also the message practitioners actually need. The demo is easy. The dependable system is hard. And what makes it hard is not the AI. It is the engineering.

What I think tech leaders should actually do

Five things stand out to me as concrete actions worth taking this quarter.

The first is to adopt a model gateway. Stop scattering direct provider API calls throughout your codebase. Centralize routing so you can swap, fail over, and govern. The teams that built their architecture around a single provider in 2024 are spending most of 2026 trying to refactor toward multi-model. You can skip that step if you make the right architectural decision now.

The second is to build a deprecation discipline alongside your adoption discipline. Most engineering organizations have a process for adding new tools and almost none for retiring old ones. Track which models you are running. Retire them deliberately as providers sunset them. Otherwise your fleet sprawls and your operational overhead compounds invisibly until something breaks.

The third is to instrument your agents deeply, especially if you use frameworks. The frameworks get you started fast and then leave you blind. Comprehensive agent telemetry is what separates teams that can debug their production systems from teams that find out about failures from customers.

The fourth is to audit your prompt caching this week. If your scaffolding is 69% of your tokens and you are not caching, this is the highest-leverage cost optimization available to you. The fix is structural. Stable content at the start of the prompt, byte-identical across calls, dynamic content injected later. It is a half-day of work for some teams and represents enormous savings at scale.

The fifth is to implement budgets and backpressure on your agent loops. Cap them by calls and tokens. Build queues and backoff. Treat rate limits as the capacity ceiling they actually are, not as an occasional inconvenience. The cascading failure pattern is real, it is documented, and it is one of the most expensive ways to learn this lesson.

The most reassuring thing about this report is also the most demanding. AI engineering is not a mysterious new discipline that requires throwing out everything we know. It is distributed systems engineering with a probabilistic component that can drift silently.

That means the teams that already know how to run reliable production systems, who understand routing, capacity, observability, and cost control, have a massive head start. They just need to apply those skills to a new substrate.

The hype is about the models. The advantage is in the engineering.

That is the part most leaders are still underinvesting in. The model decisions get the executive attention. The architecture, observability, and discipline decisions get assigned to whoever has bandwidth. I think the next two years will be unkind to companies that keep that pattern. The model layer is becoming commoditized. The engineering layer around it is where the differentiation actually lives.

If you are not investing there, you are paying for capability you cannot reliably ship.

Originally published at https://digitalstrategyai.substack.com.

On June 4, Anthropic published a proposal calling for coordinated, verifiable pauses in frontier AI development. The argument is that AI systems are approaching the point where they can build their own successors faster than humans can oversee the process. The technical term is recursive self-improvement. The plainer term is “we are losing the ability to keep up.”

Note: In first draft of this article Claude Fable 5 was mentioned but after it was suspened by Anthropic it was removed from this article.

The Anthropic post was authored by Marina Favaro and Jack Clark, two people with serious safety credentials. It is not throwaway content. It includes specific numbers that should bother anyone reading carefully. AI task-completion horizons are doubling every four months. In March 2024, models could handle tasks that took about four minutes of human work. The slope of that doubling is what is keeping Anthropic up at night.

There is one number from the post that landed hardest for me. As of May 2026, over 80% of code merged into Anthropic’s own codebase is written by Claude. Not assisted by Claude. Written by Claude. Their engineers are merging eight times more code per day than they were in 2024. The company calling for a pause is also the company whose own engineering output is now mostly generated by the AI it built.

This is not hypocrisy. It is the actual structure of where we are. And I think it is the most honest signal about the current state of AI that any major lab has given us this year.

What is actually happening

If you read the Anthropic post and the Reuters coverage at face value, the story is “AI safety lab calls for industry coordination on slowdown mechanisms.” That framing is technically correct but misses the harder truth.

A few things are true at the same time.

Anthropic is calling for a pause while filing for an IPO at a valuation around $965 billion. Earlier this year they walked back a previous safety commitment that said they would hold back dangerous AI if rivals were close to matching their capabilities. They reversed it because, in their own words, holding back unilaterally would just hand leadership to less cautious labs.

They are right about that. If Anthropic stops, OpenAI does not. If OpenAI stops, Google does not. If the three of them stop, the Chinese labs do not. The only company that can credibly slow down is the one willing to give up the race entirely, and none of them are willing, because the people running them genuinely believe their version of frontier AI is safer than the alternative.

The result is that the company most publicly worried about AI risk is also the company most aggressively shipping AI capability. Same six-week release cadence. Same downward pressure on cost. Same expanding integration into every workflow they can reach.

The June 4 proposal asks for coordination because Anthropic has accepted that unilateral restraint does not work. What they are really saying, in plain English, is “we cannot stop, but maybe if we all agreed to stop together, that could work.” That is a serious idea. It is also one that has been tried, and failed, in roughly every major technology transition in modern history.

The cost angle nobody talks about

There is something else happening that is just as important as the capability curve. Frontier-tier AI is getting cheaper at the same rate it is getting smarter.

Claude Opus 4.8 shipped in May at the same price as Opus 4.7. Five dollars per million input tokens, twenty-five per million output. Fast mode dropped from thirty dollars per million input to ten. Inference costs across the industry have been falling roughly fifty percent per year for two years.

That matters because most public conversation about AI risk still assumes scarcity. Powerful AI is expensive, so only large companies will use it, so we have time to think about governance.

That assumption is wrong now. A small business can run frontier-tier AI on a thousand tasks for a few dollars. A teenager with a laptop can build an agent that does something genuinely useful, or genuinely dangerous, without spending more than lunch money. The combination of rising capability and falling cost is what makes this period different from any other technology transition.

The car got safer as it got cheaper. The internet became more available as it became more affordable. AI is doing both of those things at once, except the curve is much steeper, and the consequences land much faster.

What we actually need

This is where I land. Anthropic is right that AI is moving fast. They are also not going to stop, and neither is anyone else. The pause proposal is interesting, but the honest reading of it is that even Anthropic does not really expect it to work. They are flagging the risk because flagging the risk is the most they can do without giving up the race.

Telling people to be careful is not a strategy. We need something practical.

The closest historical parallel I can find is the car. When cars first arrived, there were no traffic signs, no driver’s licenses, no seat belts, no road markings. People drove on whichever side of the road they wanted. Children played in streets that suddenly had two-ton machines moving through them at speed. The death toll was enormous, and most of the casualties were not the drivers. They were pedestrians who did not understand what they were standing next to.

It took decades to build the infrastructure that made cars survivable. Stop signs. Crosswalks. Speed limits. Driver’s tests. Mandatory insurance. None of it slowed the adoption of the car. All of it made the car possible to live with.

We need the same thing for AI, and we need it now. Not the regulatory version, although that matters too. The education version. The public understanding version. The version where ordinary people know what AI actually is, what it can and cannot do, how to use it without getting hurt by it.

Right now, most people I talk to fall into one of two camps. Either they believe AI is magic and will solve every problem they have, or they believe AI is fake and will collapse under its own hype. Neither of these is close to true, and the gap between them is where most of the real damage is going to happen.

The person who trusts AI completely is going to take its medical advice without verifying it. They are going to let it write their legal contracts. They are going to give it access to their finances. They are going to trust it with their children’s schoolwork. They are going to be hurt by it in ways they did not see coming.

The person who dismisses AI is going to be left behind in their career, their business, their understanding of the world their kids are growing up in. They are also going to have no defense against AI used badly by other people, because they do not know what to look for.

Neither of these people needs a slower model. They both need a better understanding of what is actually in their hands.

What tech leaders should do

If you run a company that uses AI, you have a responsibility that you may not have signed up for. You have to teach your people what this technology actually is. Not how to prompt it. Not how to make it write emails. What it does, where it fails, what kinds of mistakes it makes that humans would not, what kinds of mistakes it does not make that humans do, when to trust it, when not to.

Most companies are not doing this. They are deploying AI tools and assuming their employees will figure it out. That is the equivalent of handing out cars in 1905 and assuming people will work out the rules of the road on their own. They will, eventually, but a lot of people will get hurt in the process.

The companies that pull ahead over the next two years will not be the ones with the best AI strategy. They will be the ones whose people actually understand AI well enough to use it without being burned by it. That is a training problem, a culture problem, and a leadership problem. It is not solved by buying more licenses.

The companies that lag will not be the ones that adopted slowly. They will be the ones that adopted fast without teaching anyone what they were holding.

What I am actually worried about

The pause-or-not debate is mostly a distraction. The models will keep getting better. Costs will keep falling. Capabilities will keep arriving faster than governance can adapt to them. None of that is going to change because Anthropic publishes another warning, or because the EU passes another regulation, or because someone gives a speech at Davos.

What can change is whether the people using AI know what they are doing.

That is the part we can still influence. It is also the part we are not investing in nearly enough. Every dollar going into frontier model development right now is worth roughly a hundred dollars in AI capability the year after. Every dollar going into AI literacy and public education is worth maybe two dollars in safer adoption. The mismatch is going to catch up with us.

We do not need to slow down the technology. We need to speed up the humans.

That is the actual lesson from the car. Not “the car was dangerous, so we banned it.” The car was dangerous, so we taught everyone how to live with it.

We have not done that with AI yet. We are running out of time to start.

Love to hear your thoughts? Especially from AI leaders, teachers and economist.

He barely touched the code.

He wrote a spec. He set up the rules. He let the agents run. Then he spent most of his time reviewing what came back and throwing half of it away.

That last part is the whole story. And it is why I think the term most of us have been using for the past year is now wrong.

The word changed because the work changed

In February 2025, Andrej Karpathy coined “vibe coding” in what he later called a throwaway tweet. You just talk, the AI builds, you go with the flow. The phrase went everywhere. Every Slack channel, every pitch deck, every conference stage.

Then something happened. People started shipping vibe-coded software to production, and the results were not great.

So one year later, on the exact anniversary, Karpathy posted again and buried his own term. His new favorite is agentic engineering. His reasoning is simple: you are not writing code directly most of the time anymore. You are orchestrating agents who do, and acting as oversight. The “engineering” part is there on purpose, to remind everyone there is real skill involved.

I think he is right. And I think most leaders are still reading this as a developer story when it is actually an org story.

What I actually see changing

Here is the part I care about as a product person.

Vibe coding hands ownership to the AI. Agentic engineering keeps your judgment in the driver’s seat while agents handle the tedious work. One of those scales to production. The other does not.

When the bottleneck stops being “who can write the code fastest” and becomes “who can describe the problem clearly and tell good output from bad,” the most valuable person on your team quietly changes. It is no longer the fastest typist. It is the clearest thinker.

That is a product management shift wearing an engineering costume.

There is a failure mode I keep running into too. People call it AI slop. Code that looks fine on the surface but has no error handling, quietly opens security holes, or leaves you with something nobody can maintain. It is the new tech debt, and it shows up faster than the old kind.

The line that stuck with me: you cannot delegate responsibility. Only execution. Your team still owns the outcome no matter how much the agent wrote.

What I would do this week if I led a team

A few concrete moves, because that is what this is really about:

Write the spec before the agent runs. The quality of what comes back is capped by the clarity of what you asked for. This is the single highest-leverage habit.

Put review at the commit, not the demo. Catching slop early is cheap. Catching it after it ships is the expensive kind of lesson.

Change what you hire for. Stop screening only for raw coding speed. Start screening for judgment, clear thinking, and the ability to spot when something is subtly wrong.

Treat AI slop like tech debt with a budget. Name it, track it, and make someone responsible for it.

My honest take

I do not think agentic engineering replaces engineers. I think it raises the bar on what an engineer is for. The boring, typing-heavy parts get handed off. The thinking-heavy parts get more important, not less.

Vibe coding was a tool. Agentic engineering is an operating model. If you run a team, that is the difference worth paying attention to this year.