The VP Geek Speaks

Comprehension Debt: When Your Team Can't Explain Its Own Code

Technical debt is a concept every engineering leader understands. You take a shortcut now, knowing you’ll need to come back and fix it later. The debt is visible: you can point to the code, explain what’s wrong with it, and estimate the cost of fixing it.

AI-generated code is introducing something different—and arguably worse. Researchers have started calling it “comprehension debt”: shipping code that works but that nobody on your team can fully explain.

Vibe Coding: The Most Dangerous Idea in Software Development

Andrej Karpathy—former director of AI at Tesla and OpenAI co-founder—coined a term last year that’s become the most divisive concept in software development: “vibe coding.”

His description was disarmingly casual: an approach “where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” In practice, it means letting AI tools take the lead on implementation while you focus on describing what you want rather than how to build it. Accept the suggestions, trust the output, don’t overthink the details.

OpenClaw for Engineering Teams: Beyond Chatbots

I wrote recently about using OpenClaw (formerly Moltbot) as an automated SDR for sales outreach. That post focused on a business use case, but since then I’ve been exploring what OpenClaw can do for engineering teams specifically—and the results have been more interesting than I expected.

OpenClaw has evolved significantly since its early days. With 173,000+ GitHub stars and a rebrand from Moltbot in late January 2026, it’s moved from a novelty to a genuine platform for local-first AI agents. The key differentiator from tools like ChatGPT or Claude isn’t the AI model—it’s the deep access to your local systems and the skill-based architecture that lets you build custom workflows.

Lessons from a Year of AI Tool Experiments: What Actually Worked

Over the past year, I’ve been experimenting extensively with AI tools—trying to understand what they’re actually good for, where they fall short, and how to use them effectively. I’ve written about several of these experiments: the meeting scheduling failures, the presentation generation disappointments, and most recently, setting up Moltbot as an SDR.

Looking back at all these experiments, patterns emerge. Some things consistently worked. Others consistently didn’t. And a few things surprised me in both directions.

The Case Against Daily Standups in 2026

I’ve been thinking about daily standups lately—specifically, whether they still make sense for engineering teams in 2026.

This isn’t a “standups are terrible” rant. I’ve run teams with effective standups and teams where standups were pure theater. The question isn’t whether standups are universally good or bad; it’s whether the standard daily standup format still fits how engineering teams work today.

My conclusion: for many teams, it doesn’t. Here’s why.

AI Code Review: The Hidden Bottleneck Nobody's Talking About

Here’s a problem that’s creeping up on engineering teams: AI tools are dramatically increasing the volume of code being produced, but they haven’t done anything to increase code review capacity. The bottleneck has shifted.

Where teams once spent the bulk of their time writing code, they now spend increasing time reviewing code—much of it AI-generated. And reviewing AI-generated code is harder than reviewing human-written code in ways that aren’t immediately obvious.

From Code Writer to AI Orchestrator: The Changing Developer Role

There’s a narrative circulating in tech circles: developers are evolving from “code writers” to “AI orchestrators.” The story goes that instead of typing code ourselves, we’ll direct AI agents that write code for us. Our job becomes coordination, review, and high-level direction rather than implementation.

It’s a compelling vision. It’s also significantly oversimplified.

Research shows that developers can currently “fully delegate” only 0-20% of tasks to AI. That’s not nothing, but it’s far from the wholesale transformation some predict. The reality of how developer roles are changing is more nuanced—and more interesting—than the hype suggests.

GitHub Copilot Agent Mode: First Impressions and Practical Limits

GitHub Copilot’s agent mode represents a significant shift in how AI coding assistants work. Instead of just suggesting completions as you type, agent mode can iterate on its own code, catch and fix errors automatically, suggest terminal commands, and even analyze runtime errors to propose fixes.

This isn’t AI-assisted coding anymore. It’s AI-directed coding, where you’re less of a writer and more of an orchestrator. After spending time with this new capability, I have thoughts on what it delivers, where it falls short, and how to use it effectively.

The 32% Problem: Why Most Engineering Orgs Are Flying Blind on AI Governance

Here’s a statistic that should concern every engineering leader: only 32% of organizations have formal AI governance policies for their engineering teams. Another 41% rely on informal guidelines, and 27% have no governance at all.

Meanwhile, 91% of engineering leaders report that AI has improved developer velocity and code quality. But here’s the kicker: only 25% of them have actual data to support that claim.

We’re flying blind. Most organizations have adopted AI tools without the instrumentation to know whether they’re helping or hurting, and without the policies to manage the risks they introduce.

The AI Productivity Paradox: Why Experienced Developers Are Slowing Down

There’s something strange happening in software development right now, and I think we need to talk about it.

Recent research has surfaced a troubling finding: experienced developers working on complex systems are actually 19% slower when using AI coding tools—despite perceiving themselves as working faster. This isn’t a minor discrepancy. It’s a fundamental disconnect between how productive we feel and how productive we actually are.

As someone who’s been experimenting with AI tools extensively (and writing about the results), this finding resonates with my experience. Let me break down what’s happening and what it means for engineering teams.