You plan to perfom a Tech DD? We are happy to share insighs from our data-driven approach and strong experienced CTOs.
We have been told by multiple deal teams over the past year that they plan to run their technology due diligence by prompting an LLM directly: paste in the repository, ask for the assessment. Some have tried it. The outputs look like DD findings. They are not. They are plausible-sounding narratives with numbers that were not computed, observations that were not traced to specific code, and gaps the reader cannot easily identify because the format obscures them. The mistake is the same one investors are learning to watch for in targets: using an LLM is not the same as having built something with it.
There is a more basic problem too: code cannot be the single source of truth for a Tech DD. Team structure, engineering processes, and delivery practices determine whether an organisation can execute, and none of that is visible in the repository.
This article is an account of what we built instead, and why the simpler approach fails. The short version: a multi-agent system that breaks a codebase into coherent units and runs specialist passes over each, rather than a single prompt over the whole thing. We have been running LLM-assisted code analysis across live engagements for the past year. Where we have something concrete to say about what works, we say it. Where we have not solved a problem, we say that too.
Why a raw prompt can't analyse a codebase
Three problems come up on every naive attempt at LLM code analysis in DD. None of them are edge cases.
Context window limits distort emphasis, not just scale. We routinely handle repositories having many millions of lines. No commercially available context window accommodates that. When you force an oversized codebase in, the model attends more heavily to the beginning and end of the input and compresses the middle. The parts of a codebase that carry the most risk (tangled service boundaries, undocumented legacy modules, implicit dependencies) tend to sit in the middle.
LLMs do not compute; they estimate. Ask a model for a count of critical CVEs, a dependency version, commit frequency for a specific author, or test coverage. You will get a number. That number may have no basis in fact. LLMs generate statistically plausible outputs. For any claim that requires computation over actual data (and DD has many of those), this is the wrong tool. We have seen assessments where the LLM-stated vulnerability count was off by a factor of three compared to what a scanner returned on the same repository.
Broad prompts produce broad outputs. A single prompt covering architecture, security, dependencies, team structure, and development process does not do the work of five separate analyses. Attention is distributed; depth is not. The output reads as comprehensive and is not.
The most expensive failure mode we have observed: an assessment that looks authoritative, gets accepted without verification, and turns out post-close to have missed something material. The format created the confidence, not the content.
Where LLM code analysis does add value
There are specific tasks where LLMs outperform deterministic tools, and where that difference matters for DD. The four cases below are drawn from live engagements.
Legacy technology
Deterministic analysis tools are built for the languages in current use. They have limited or no support for Visual Basic 6, Delphi, FoxPro, legacy COBOL, or older ABAP. In mid-market buyouts, targets running on precisely these stacks are not uncommon, and the investment thesis often turns on migration cost and feasibility. LLMs can read and reason about these systems. On two recent engagements, our system produced module-level architectural assessments of VB6 codebases that were used directly to scope migration effort. The standard tooling we run in parallel returned nothing useful on the same repositories.
Integration scoping in M&A
Questions about how two systems would be integrated (how difficult, where the coupling points are, what the dependencies look like across service boundaries) require reasoning about design intent, not just structure. A dependency graph tells you what exists. It does not tell you where the seams are or which ones will generate integration cost. LLMs handle that class of question better than any deterministic tool we have tested. For bolt-on acquisitions where integration complexity is a valuation input, this is a direct contribution to the analysis.
Depth at scale
Standard DD code review is a sampling exercise. An analyst has days; the codebase has millions of lines. The consequence is that architectural observations that would change the investment view sometimes only surface in the PMI phase, after close, when the options are narrower. A systematic LLM-assisted pass over the full codebase, handled module by module rather than in one oversized prompt, moves some of that work pre-close. It increases coverage and lets the analyst spend the same time more effectively, reviewing a consolidated analysis and verifying findings across the whole codebase rather than a slice of it.
Heterogeneous and polyglot codebases
A polyglot monorepo with fifteen services, each with its own architectural history, is where the multi-agent approach is most clearly the right tool. A single LLM pass would compress it into a flat summary. The decomposition stage identifies each service as a distinct analysis unit; specialist agents then work on coherent subsystems rather than an undifferentiated mass of code. The heterogeneity becomes an input to the structure, not a problem for it.
Where deterministic tools beat LLMs
There is a common mistake in AI-assisted DD: over-using the LLM because it is the more exciting tool to use. Deterministic tools are more reliable for certain tasks, and should be used for them.
In our pipeline, deterministic tool output feeds the LLM layer as structured context. The model reasons about verified data rather than estimating it. A finding that cites a specific CVE identifier confirmed by a scanner is defensible in a vendor management meeting. A finding where the LLM inferred the vulnerability count is not. The same principle applies to technical debt: the LLM can characterise the nature and distribution of debt across a codebase in a way a scanner or metrics tool cannot, but the translation of that assessment into financial terms still requires verified inputs, not inference.
The architecture we built
The right unit of analysis for an LLM is not a codebase; it is a module. Structure the decomposition correctly and the context window and prompt-depth problems are largely solvable. Structure it incorrectly and they compound.
The decomposition stage determines the quality of everything that follows. Splitting a repository into arbitrary file-size chunks produces incoherent analysis units: an agent reasoning about half a service boundary sees an incomplete system. We use a preliminary LLM pass to map logical module boundaries before the deeper analysis begins. This adds a step but changes what the specialist agents are working with.
Each specialist agent has a narrow focused brief: dependency and licence risk, architecture and technical debt, security posture, legacy technology indicators and migration complexity. Running them in parallel keeps total processing time manageable. The synthesis stage aggregates agent outputs into a structured report: findings organised by risk category, each grounded in specific evidence from the analysis. For a mid-sized engagement, this typically runs to several dozen pages. Code analysis is one input into a broader assessment; for context on how TechMiners structures the full engagement, that is covered here.
A separate reviewer agent sits between the stages as a quality gate. It judges each stage's output, returns a PASS or FAIL with specific feedback, and on a fail triggers a retry that incorporates that feedback. This matters because it catches the failure mode that makes naive LLM use dangerous: a plausible but unsupported output moving downstream unchallenged. Nothing reaches synthesis without passing review.
Making findings defensible
DD findings get shared with target management, sometimes with sellers, and ultimately influence deal terms. They need to hold up when challenged. "The model said so" does not hold up.
Our approach: quantitative claims trace to deterministic tool output, not LLM inference. Architectural observations reference specific files and modules an analyst can open and verify. In practice, every claim carries a provenance record of the form { path, symbol, note }, tying it to the exact location in the codebase it came from. This is the anti-hallucination mechanism: a claim that cannot point to a path and a symbol does not become a finding. Risk ratings are explained by disclosed methodology. Where a finding cannot be independently verified (where the LLM is interpreting rather than reporting), it is labelled as an observation or an estimate, not a confirmed finding. That distinction is marked in the report output, not buried in a footnote.
A side effect of this discipline: target management engagement tends to improve. Assessments that cite specific evidence rather than general impressions are harder to dismiss and easier to have a productive conversation about. Targets can dispute a specific finding. They cannot usefully engage with a narrative that lacks traceable sources.
The non-negotiable: IP protection
🔒Code analysis requires access to a target's most sensitive IP. We do not process any repository without explicit written authorisation scoped to the engagement. Every analysis runs under a defined data handling protocol covering which repositories are in scope, how the code is transferred, where it is processed, and how it is deleted after the engagement closes. For software businesses where the codebase is the primary asset, this is not a legal formality: it is the basis on which the engagement is permissible. And where a target prefers it, we can run the entire engagement the traditional way: data-driven, CTO-led Tech and Product due diligence with no LLM involvement at all.
Where this still falls short
Two limitations are worth stating directly.
Runtime behaviour. Static analysis, whether LLM-based or otherwise, reads the code as written. It does not observe how the system behaves under load, what failure modes occur in production, or how data flows at runtime across service boundaries. Architecture interviews and access to monitoring data remain necessary for a complete picture.
Novel frameworks and proprietary infrastructure. Targets that have built substantial custom tooling on unconventional foundations produce lower-confidence assessments. The model's architectural reasoning depends on recognising known patterns. Where those patterns are absent, the output requires more analyst validation before it can be used as a finding.
None of this is a reason to avoid LLM-assisted code analysis. It is a description of where human judgement is still required and where an experienced analyst changes the outcome.
Questions to ask any provider
If you are evaluating DD providers who claim to use AI in their code analysis, the questions that matter are specific: what does the LLM layer produce and what does it not produce? How are quantitative claims verified? What is the IP handling protocol, and is it technically enforced or only contractually stated? Can they show you a finding with its evidence chain intact?
LLM code analysis in due diligence is an engineering problem. Solved properly, it expands what is knowable before close: coverage of legacy systems that standard tooling cannot assess, integration complexity that only surfaces in PMI (post-merger integration), architectural observations that a sampling-based review misses. Those are real outputs that change investment decisions. They surface a class of risk that a thorough Tech DD is expected to cover but that is often underserved by time-constrained manual review. They require a workflow built around the constraints of the technology, not a prompt and a hope.
We are happy to walk through how the pipeline works and what it would produce on a specific engagement. You can schedule a call below or contact us directly.
