Staying Involved When AI Writes Code

One of the most motivated developers at a company I worked with kept discarding the code changes his AI tool produced.

Why it matters: Delegating code changes how we contribute. AI’s value depends on what the team delivers, what it learns and whether it can understand and maintain the result.

We judge AI through different experiences

#

The developer’s resources limited him to cheaper models, although some tests with more capable ones had worked better. He was keen to use AI, yet his everyday experience gave him reasons to doubt it.

In his April post, Andrej Karpathy describes that gap. People who tried a free or older chatbot can reach different conclusions from professionals using recent models in programming and mathematics.

These professionals use agents that can edit code, run tests and debug with some autonomy. Both experiences can coexist.

Karpathy argues that progress is uneven. Code and mathematics offer verifiable results, such as a test passing or failing, which provide clear signals for training. He also points to their commercial value.

In October, he describes a funnel of experience:

• People with little exposure to these systems.
• Casual users of basic tools.
• Professionals using advanced models in programming and mathematics.
• People with access to internal systems.

He adds that problem size, ambition and how long an agent can work affect what we observe. Colleagues can form their opinions from very different experiences.

Delegation changes the craft

#

Access explains part of the disagreement. What people enjoy about their work explains another part.

Among developers who defend programming as a craft, I have seen the pleasure of tackling a problem directly and making decisions while writing code.

Delegating execution can feel like moving from illustrator to art director. You still define the direction and guide the work, but someone else makes the thing you imagined.

That role can be fulfilling. You can also understand the result perfectly and still miss having made it yourself.

For me, staying involved means supplying context and intention, deciding what we want to achieve and reviewing the result. I can delegate the writing and still make decisions about what we build.

In a shared review, the person proposing a change should explain the problem, their decisions and the alternatives. The team can then examine the reasoning together.

At work, our choice of how to build should serve the impact we seek and the quality we need. I would limit delegation to work the team can understand, review, correct and maintain.

Measure improvement through to the user

#

I would look at three signals together:

• Measure the time from starting the work to delivering it to users, including review, tests and corrections. Faster code generation can leave more work waiting for review.
• Track the experiments we try, what we learn and which decisions change. Rejecting a hypothesis can save us from investing in something that adds little value.
• Check what improves for the people using the product. We can ship a lot and achieve very little.

AI can help us build a prototype quickly enough to challenge an idea. Before building, I would define the problem, its context, what we want to learn and the criteria for continuing or discarding it.

The prototype needs to represent the problem well enough for a test with users to inform the next decision.

User outcomes also depend on factors outside AI. Looking at these signals together helps us judge its contribution.

Give teams room to develop judgment

#

The company should provide suitable tools and protect time to learn how to solve problems and make decisions as roles change.

I would accept delivering less for a while if that investment helped the team develop judgment and autonomy. The aim is to strengthen its ability to make better decisions later.

Professionals have responsibilities too: try the tools with an open mind, review what they generate and take responsibility for the result. Sharing what we learn and adapting how we work helps the team finish.

AI also gives us a reason to revisit the boundaries of our specialties. T-shaped professionals combine depth in one area with the ability to collaborate across others.

I see an opportunity to contribute across more of the work, from defining the problem to building, experimenting and reviewing. That breadth requires learning and knowing when we need a colleague’s expertise. Depth remains valuable.

I want us to stay involved: bringing context and intention, learning from each other and taking responsibility for the impact we achieve as a team.