.png)
A developer I've worked with for years told me recently that he feels like he lost a twenty-year identity overnight. He loves the deep, immersive work of building systems, finding bugs, and solving problems. Now he keeps hearing that AI can do that work without him.
His second worry is one I share. He sees smart people accept AI-generated code because it looks plausible, and fewer people stop to ask whether it's the best path forward. When a tool produces more code than anyone can review, who owns the outcome, and why should anyone trust it?
A recent Boston Consulting Group article calls this larger risk "distributed de-skilling". Skills fade when we stop using them. When that happens across an entire team at once, the organization's collective judgment erodes. Half of the leaders BCG surveyed already see it. Nearly 90% point to the same first symptom my friend described: accepting AI output without stress-testing it. BCG also found that "the AI suggested it" has become a shield for unchecked work.
People sometimes assume I have this figured out because I lead an employee-owned software consultancy and Cincinnati's first B Corp. I don't. I do know that our employee-owners' judgment and expertise sit at the heart of our business, and we owe them and our clients a thoughtful approach. Conversations with other leaders have taught me more than I could learn alone, so I'm bringing this into the open. Skepticism about AI's promises is healthy.
Trust has to be earned, and these tools haven't built the track record to deserve the blind trust many already give them. Refusing to engage, though, is a fast path to irrelevance, because the market won't wait for us to feel ready. Two practices from BCG's research stand out to me:
Think first, then prompt. Shell redesigned workflows so people frame the problem, test assumptions, and build a baseline analysis before using AI to refine it. Test-driven development taught developers to define "correct" before writing a line of code, and applying that discipline to AI makes sense. I've watched TDD make a comeback on AI-augmented teams, including ours.
We’re applying that same discipline in our own work. We treat AI-generated code as an initial proposal that earns approval through engineering judgment. The developer must understand the solution, test its assumptions and edge cases, and determine whether it fits the client’s needs and the systems around it. Code is ready to ship when we can explain why the approach is right and confidently stand behind the result.
Reward the challenge. CNIL, France's data protection authority, assesses employees on their ability to challenge AI outputs. I love this because it rewards healthy skepticism.My developer friend worries that AI made his twenty years of experience obsolete. I believe it made that experience more valuable. AI can produce a plausible answer in seconds. Deciding whether it deserves trust takes someone who has watched systems fail, knows where the edge cases hide, and understands what the client actually needs. Experience turns output into assurance.
"The AI suggested it" has no place in our vocabulary. The person who reviews, challenges, and approves the work owns the outcome. Clients trust people with their systems, and that trust requires someone willing to stand behind every answer.
