AI, The Panda Strike Way (Part 2)

This is the second 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.

In Part 1, we concluded that, with the emergence of AI tools, we can translate knowledge into value. That sure sounds exciting, but you’d be forgiven if you’re a bit skeptical. After all, we’ve heard claims like this before. In the 1970s and 80s, expert systems, pioneered by researchers like Edward Feigenbaum, aimed to capture the expertise of specialists—such as doctors and chemists—and codify it into rules. This vision hit a wall known as the knowledge acquisition bottleneck: the process of interviewing experts and precisely capturing their knowledge proved elusive and costly to maintain, contributing to the subsequent AI winter.

Today’s generative AI can synthesize unstructured data, effectively bypassing the acquisition bottleneck. The goal remains the same—to capture organizational knowledge—but LLMs have the potential to do it far more cost-effectively. The lesson to take from this is not that code is cheap—although it is—but that knowledge acquisition is cheap(er). Once captured, that knowledge can help guide LLMs in generating code. Without it, LLMs lack the context to do much more than produce slop.

When generative AI is deployed to capture and disseminate the tacit knowledge of experienced employees, it doesn’t just improve individual performance—it transforms individual competence into collective organizational capability.

Knowledge Engineering Revisited Permalink

But this transformation doesn’t happen by accident. You can’t simply point an LLM at your company’s document store or chat history and expect it to magically distill that into knowledge. In practice, existing knowledge artifacts are incomplete, outdated, and scattered across purpose-built databases or spreadsheets. Moreover, much of what your team actually knows is procedural and operational—like knowing exactly which legacy database holds a specific customer record, or how to work around a quirk in a third-party API. It’s the tacit expertise that lives entirely in people’s heads.

Extracting this lore requires intention. We need to resurrect the discipline of knowledge engineering—not writing rules for an expert system, but rather curating, structuring, and verifying information. It’s closer to technical writing than writing code. We need to train developers to view documentation and test suites not as chores, but as the “railways” that guide AI coding assistants. And we need to provide the right incentives: if you’re measuring lines of code and story points, developers will respond accordingly.¹

Start Small Permalink

Despite the hype, don’t try to transform your organization overnight. Start with a pilot project: a small, low-stakes domain where the knowledge is self-contained and the outputs are easy to verify. For instance, you might document the setup and onboarding procedures for new employees, or build a (verified) knowledge base for using a single API. Once you have a working model, you can use that success as the blueprint to scale knowledge engineering across the rest of your organization.

In our next post, we’ll explore what this transformation may mean for traditional roles, including junior and senior developers.

1. Measuring token use is not the answer, either. ↩