Do we even need formal technical diligence anymore?

It’s a fair question. AI can apparently do everything else, so why not this? A deal team with access to Claude or Cursor and a GitHub repository could reasonably think they can run their own technical assessment, produce a report, and cut the cost and time of bringing in a specialist. The tooling is accessible, the output looks credible, and in a world where AI is compressing every other knowledge function, it feels like a logical extension.

It isn’t. But to understand why, you need to understand what diligence actually was, what it has become, and what it still requires.

The old world

Ten years ago, getting access to a target’s source code felt like a hostage negotiation. Lawyers on both sides, NDAs that took weeks to agree, virtual data rooms with selective access, and a technical team on the other side who were nervous about showing you anything. You’d spend the first two weeks of an engagement just fighting for visibility, and you’d still end up with gaps you had to work around. Parties paranoid about code theft.

Database schemas were almost never handed over. Infrastructure details were treated like state secrets. Code was shared reluctantly and often incompletely. You worked with what you got, filled the gaps with experience, and built a view of the system under those constraints.

The tools we had were useful but narrow, and critically, they were siloed. Code scanners flagged known vulnerabilities, checked for security patterns, and identified some dependency issues. Separate tooling looked at infrastructure configuration. Something else handled dependency licensing. Each of these areas had its own analysis tools, and most of them carried a significant cost. But bringing the outputs together into a coherent picture was an entirely manual process, and it was in that manual stitching together where things slipped through the cracks. A finding in one area that connected to a risk in another would only surface if someone happened to look at both at the same time and made the connection. That someone had to be experienced enough to know what they were looking for, and even then, they were working against time and incomplete access.

What AI has actually changed

Running a modern model across a codebase, using something like Claude Code or Cursor, changes what’s possible in the first few days of an engagement in ways that are genuinely significant.

You’re not just getting an inventory anymore, you’re getting inference. What is this code actually doing. How is the business logic structured. Where are the seams, the workarounds, the parts that were built in a hurry and never properly revisited. You can chunk a large codebase, interrogate it in sections, and build a contextual picture of the system that used to take a senior architect the better part of a week to develop. That doesn’t replace the architect, it means the architect walks in on day two already oriented, asking better questions, spending their time on interpretation rather than excavation.

Code style analysis has also become a serious signal. When you run AI across a large codebase you can see quickly whether there is a consistent engineering standard at work, or whether you’re looking at ten different people writing in ten different styles with no coherent pattern holding it together. That distinction matters. A consistent codebase tells you something about how the engineering team is led and how seriously they take their own craft. A fragmented one raises questions about governance, onboarding, and what happens when key people leave. This is going to become an increasingly important lens as the volume of code explodes. As teams vibe-code their way to platforms faster than ever before, there will simply be more code to assess, and the quality signal buried in style and consistency will matter more, not less.

Dependency mapping is now fast, thorough, and surfaces things the old tools missed. And that matters because the open source license landmine is real and almost nobody sees it coming. Not all open source licenses are equal, and a codebase with significant GPL licensed dependencies has a problem that goes directly to the ownership question. You may not own what you think you own. This risk gets buried across hundreds of packages, accumulated over years of development by engineers who never thought to check. Surfacing that complete picture used to take real effort and real cost. Now it takes an afternoon.

GitHub has become its own intelligence layer entirely. Commit cadence tells you how active the codebase really is, not how active the sales deck claims it is. The ratio of bug fixes to new feature work tells you whether the team is building or firefighting. PR patterns tell you something about engineering discipline and process maturity. And contributor analysis tells you things the org chart will never show you. Who is actually doing the work, whether there is one developer who has written 70% of the commits and hasn’t pushed anything in eight months, whether there is a third party contractor doing the real heavy lifting who appears nowhere in the vendor disclosure. Key-man risk used to be something you explored in management interviews. Now you can see it in the data before you sit down with anyone.

Database schemas, when you can get them, remain one of the most closely guarded assets in any diligence process, and for good reason. A schema tells you far more than what data a company holds. It tells you how seriously they think about their data, how it flows, how it ages, and how it gets used. The presence or absence of audit trails, updated timestamps, soft delete patterns, and event logs tells you whether this company treats its data as a managed asset or an afterthought. A target claiming eight million active customers looks very different when the schema shows no record of when those customers last did anything, no way to distinguish active from dormant, no audit trail to speak of. The asset may be real. The claim being made around it may not be. Schema structure also gives you strong clues about how analytics is being done, whether the data model supports the reporting the business claims to run, or whether someone is pulling exports into spreadsheets and hoping for the best.

Infrastructure configuration rounds out the picture in a way that was previously hard to get at efficiently. Whether a target is running on AWS, Azure, or still operating out of their own data center is less interesting than how they are managing whatever they have. Network configuration, machine provisioning, security group structures, deployment patterns, these tell you about the maturity of the engineering operation in ways that go beyond any single finding. A well-managed on-premise setup can reflect more engineering discipline than a poorly governed cloud environment. What you’re reading is not the technology choice, it’s the judgment behind it.

And this is where AI changes something fundamental. These areas, code, dependencies, GitHub history, schema, infrastructure, used to produce separate outputs that required manual effort to connect. A licensing issue in the dependency scan might connect directly to an architectural pattern visible in the codebase, which connects to a contributor history that shows the person who built that part of the system left eighteen months ago. Seeing that chain used to depend on someone holding all of it in their head at once. AI allows you to bridge those gaps systematically, surface the connections that historically were easy to miss, and give the experienced technologist a lens on the platform that simply wasn’t available before.

What AI cannot do

Here is where the deal team running their own assessment hits the wall.

The report AI helps you produce is better, faster, and broader than anything we could build five years ago. It surfaces things that used to get missed entirely. But a list of findings is not diligence. Diligence is knowing what the findings mean, and knowing what to do about them.

AI can surface issues that were historically hard to find. However, what it cannot tell you is whether that finding kills the deal, changes the price, or is a six month fix the acquirer absorbs and moves on from. That judgment comes from someone who has sat in enough of these conversations to know the difference between a flag and a fatal flaw.

The same applies to the GPL finding, to the hidden contractor, to the stale customer database, to the infrastructure that looks modern but is held together by one person’s institutional knowledge. Each of those is a conversation, not a checkbox. Each one requires a remediation strategy, a realistic cost estimate, and a clear view on whether it’s worth the squeeze. That view has to come from someone who understands the business context, the deal structure, and what the acquirer is actually taking on.

So, do you still need formal technical diligence?

Yes. More than ever, and with higher expectations than before.

AI has raised the floor significantly. A less experienced team now produces a more complete technical picture than an experienced team could manage a decade ago, in a fraction of the time and at a fraction of the cost. That is genuinely good for the industry and it has changed what diligence looks like operationally.

But the ceiling has not moved. Knowing what the findings mean, knowing which ones matter, knowing how to walk into a room with a PE partner and explain clearly why this finding kills the deal and that one doesn’t, that still requires a seasoned technologist who has been in those rooms before and carries the scar tissue to prove it.

As a side project, I have been building a set of AI skills and agents that form a structured diligence toolkit, which I plan to open source on GitHub. The goal is to make the analytical layer accessible and repeatable, so that the human judgment layer is spent where it actually matters.

The deal team can run the tools. What they cannot do is replace the person who knows what they’re looking at.

AI Disclaimer: Gemini Nano Banana Pro was used to generate the photo – from the 1999 Office Space movie – from the infamous diligent friendly “What would you say you do here?” scene