LLMs don't have "skin in the game"

LLMs don't have "skin in the game", so you need to take responsibility.

I'll start this week's synthesis by bringing up a METR study on AI-assisted software development performance in open source projects. The results show that total time may have increased.

Obviously, it's an initial study with few developers not using the most powerful models, but the feeling I get is that we've indeed started delivering code faster, but we're taking longer to ensure it actually works.

What "skin in the game" means in practice

My opinion is that, more than just writing code, we need to ensure it works. This aligns with the argument that writing code was never the real bottleneck.

Even though LLMs generate code quickly, someone needs to have "skin in the game." A human needs to take responsibility for ensuring the delivered software:

• Meets established requirements
• Actually works in production
• Is secure and doesn't introduce vulnerabilities
• Can be maintained by the team

Experienced professionals know that delivering bad software or software with invisible problems is shooting yourself in the foot, hence the need to spend more time doing code reviews, testing, documenting, etc.

The real bottlenecks remain

Pedro makes a very interesting analysis in the article "Writing Code Was Never the Bottleneck", emphasizing that writing code was never the bottleneck. The real limiting factors have always been:

• Code reviews
• Knowledge transfer
• Testing
• Debugging
• Team coordination

LLMs can accelerate initial implementation, but they don't solve the fundamental collaborative aspects of software engineering.

The future is still about amplification, not substitution

In the same vein, I recommend reading the article "The Uncertain Future of Coding Careers and Why I'm Still Hopeful" which discusses the uncertainties of the current moment and the future of software development careers.

The author's perspective is balanced: yes, there are legitimate anxieties, but the future isn't about substitution, but it's about amplification. Programmers will prosper as "shepherds" of AI agents, providing context and strategic guidance, reviewing, testing, guiding.

Conclusion

The METR study on AI-assisted development corroborates what many experienced professionals already suspected: code generation speed is not the limiting factor in development productivity.

While LLMs can be powerful tools for accelerating certain tasks, they cannot take responsibility for the software they help create. This responsibility - the "skin in the game" - remains fundamentally human.

Just as we don't blame the hammer for hitting the wrong place, we can't blame AI for the code it generates. The tool is neutral; responsibility for its proper use always belongs to whoever wields it. LLMs are very sophisticated hammers, but they're still tools that depend on human expertise and judgment to be used effectively.

The key is understanding that our role is evolving: from code writers to curators, reviewers, and those responsible for software quality. And this, ironically, might mean we spend more time ensuring code works than generating it.