AI, The Panda Strike Way

This is the first in a series of posts exploring the strategic approach we take to help our clients navigate the risks and realize the massive quality payoffs of the AI era.

At Panda Strike, we’re not AI skeptics, but we may come across that way. The reality is that we’re AI optimists, but that’s overshadowed by the fact that we’re all drowning in a tsunami of hype. Indeed, LLMs are a remarkable leap forward in natural language processing. As such, they’re useful tools for a variety of tasks. That’s all well and good, and normally we could just stop there and focus on using them.

Unfortunately, it’s not that simple: AI vendors want us to believe that LLMs are much more than that. Among other things, they want us to believe that LLMs will replace developers, if not today, next year, or eighteen months from now. Thus, we find ourselves spending as much time talking about the limitations of AI as we’d like. And so we sound like skeptics.

But we’re not! In fact, we’ve been early adopters, both internally and with our clients. We’re advocates of using AI and have been since well before the current generation of LLMs emerged with the Attention Is All You Need paper. But we also believe that, as with any innovation, there’s risk that comes with the opportunity, and that risk needs to be managed.

Instead, let’s focus on how leaders can guide their organizations to harness AI capabilities now. Maybe in a year, everything I’m saying will be obsolete, but it probably won’t be, and no one knows for sure. Change is the only constant, but you already knew that.

When Code Is Cheap Permalink

For decades, producing code was widely perceived as the primary driver of cost in software development projects. Productivity was measured in lines of code or story points. Organizations with the most talent were seen as having a decisive advantage because they could produce high-quality code more efficiently.

This widely held belief inspired Brooks’ Law: adding developers to a project often slows development. (We’re paraphrasing, but that’s the gist of it.) Brooks’ insight was that software development is more than merely writing code. However, in practice, many organizations ignored Brooks’ advice, perhaps due to the Quantitative Fallacy: lines of code and story points are relatively easy to measure.

The emergence of LLMs amplifies the risk of failures due to this blind spot. Code is cheap (or at least cheaper than it used to be). Naturally, we’re producing more code: in 2025, the number of code lines submitted per developer per month skyrocketed by 76% (from ~4,450 to over 7,800 lines). And they’re almost certainly using AI to do it. For example, Copilot developers use AI to generate 46% of their code on average.

For organizations that believe the primary output of their developers is code, it follows that they need fewer developers. But Brooks’ Law tells us that simply producing more code isn’t the answer. In fact, it can potentially reduce productivity: the code might be of poor quality, extraneous, or implement the wrong thing. And, in fact, there are signs that this is the case:

• AI-authored pull requests have been found to contain 1.7 times as many issues as human-only code, with logic and correctness errors occurring 75% more frequently.
• Teams using AI have seen bug rates spike by 41%, often because the “plausible-looking” nature of AI output encourages developers to skip rigorous testing in favor of a superficial visual check.
• We are seeing a staggering 800% increase in duplicated code blocks and an 84% increase in code churn.
• We’ve also seen that 45% of AI-generated code contains security vulnerabilities.

We are not just producing more code; we are producing more “mistake code” that requires immediate, often costly revisions.

In other words, it’s more important than ever to move away from looking at stories or lines of code as metrics for productivity, at least in isolation. The risk to your business is no longer that you can’t build it—AI can usually generate a plausible implementation—but that you build the wrong thing or the right thing but the wrong way. So how can we manage that risk? And once we’ve done that, can we use AI to generate real benefits for the business? If so, how? That’s what we’re going to explore.

Managing The Risk Permalink

The data we’ve seen so far—spikes in code churn and logic errors—suggests that AI might be the greatest threat to software quality we’ve ever faced. And that may be true and probably will be true for many organizations. But it doesn’t need to be true for yours.

While the unmanaged use of AI tools degrades our codebases into slop, using them in a disciplined and strategic manner provides the foundation for a generational leap in software quality. It’s the kind of leap that can ultimately differentiate you from your competitors. You’ll be able to more directly translate your core competencies and your strategic advantages, into applications that leverage them. In other words, you’ll be able to translate knowledge into value.

To achieve this feat of alchemy, we have to look past the superficial allure of mere code generation and go back to basics. That means three things:

1. Learning the tools: as with any tool, there’s a learning curve for AI tools.
2. Building railways: tests and documentation take on new value in guiding AI coding efforts.
3. Capturing knowledge: codifying the tacit lore that lives in the heads of your people.

Once you’ve done this, you haven’t just contained the risk of turning your codebases into slop. You’ve laid the foundation for organizational transformation.

In our next post, we’ll look at what it actually takes to put these basics into practice by revisiting the discipline of knowledge engineering.