Evidence at a glance
The Constraint Was Tool Access as Well as Analysis
In a case study published by OpenAI in October 2026, Anant Kumar, a portfolio manager at Benefit Street Partners (BSP), used Codex while building internal tools. BSP is a credit-focused investment manager, and the tools address two kinds of work: comparing how different business development companies value the same loan, and analyzing credit agreements. They do not decide whether the firm should invest. Instead, they support information gathering and analysis during diligence and investment committee follow-ups.
The case describes two different waits in the old workflow. To build a data dashboard that colleagues could share, Kumar previously needed someone with software expertise to create a website and bring in the data. A round of investment committee comments, meanwhile, could take days or even weeks to address. Kumar says analysts can now usually complete a round of feedback in a day and often answer follow-up questions during the meeting. These are the participant's account, and the material provides no independent measurement or comparison group.
BSP's stated use of the time saved is also important: the firm says the added capacity is intended to increase the rigor and volume of underwriting review within the same timeframe, rather than to do more deals. The aim, in other words, is not simply higher deal throughput. It is to let the team process more information and respond to more questions within its existing deal cadence. For technical leaders, this is more specific than a story about AI replacing a job, and it points to where the tools actually enter the work.
From Using Tools to Building Them as a Specialist
The BDC valuation tracker is the clearest example of a specialist building a tool for their own work. It uses public filings that business development companies submit to the U.S. Securities and Exchange Commission (SEC), helping the team compare the marks different holders assign to the same loan. Kumar used AI to draft code and Codex to review it, creating an internal dashboard that previously would have required help from a software developer.
The reported development time comes in two different measures, which should not be conflated. Kumar estimates that the first version took about a day. After adding features and refining the interface, he puts the total development time at roughly 10 to 12 hours. That suggests a lower barrier between identifying a problem and producing a usable prototype. It does not separately tell us how long it took to extract data from public filings, interpret and reconcile valuation conventions, or maintain the tool over time.
The distinction matters for engineering management. When a domain specialist can quickly produce a prototype, a team can decide earlier whether a recurring task merits productization, with less translation back and forth between requirements and day-to-day work. But generating code does not by itself solve data quality, access control, exception handling, or ongoing maintenance. The case gives no details about the tracker's design in those areas, so it is evidence of faster prototyping, not proof that a production system is mature.
Twenty Minutes Covers Only the First Pass
The second tool works on material that is longer and more dependent on interpreting clauses. Credit agreements often run to 300 pages or more, and investors need to identify provisions that could shift value away from lenders. BSP assembled law-firm memos about clauses and risks as reference material. After a user uploads an agreement, the tool produces a first-pass analysis in about 20 minutes. Kumar calls it a “second brain” within the organization, but that describes assistance, not independent authority.
An hour or more of human review still follows the first pass. So 20 minutes should not be presented as the time needed to complete an agreement review, much less as the time needed to make an investment decision. The tool first shortens the step of organizing candidate risk information from a long document. People must still check the output, interpret clauses in the context of a deal, and make the final investment judgment. The material explicitly says that the ultimate investment decision remains with a human.
It is also important to be precise about which tool does what. The case says Kumar used Codex for code review, while the agreement analyzer was later refactored with GPT-6 Astra and is now live in a company-hosted portal. It does not say that Codex performs all of the agreement analysis, nor does it explain exactly what the refactor changed. Collapsing coding assistance, the analysis tool, and its underlying model into a story about “Codex automatically reviewing contracts” would obscure the division of work in the actual system.
Validate Before Expanding Review Capacity
The case supports a bounded conclusion: some internal work has become faster, and specialists can turn recurring needs into tools more directly. It provides no error rate, missed-clause rate, sample size, or independent accuracy assessment for the agreement analyzer. It also offers no comparison of costs before and after deployment. Kumar says that having more information gives the team greater confidence in its decisions. That describes the team's experience, but does not establish that credit judgments improved or risk declined.
The deal timeline does not provide an average that can serve as an outcome comparison either. The material says only that deals typically take from a few days to a few weeks, and that the number of diligence rounds varies with the deal. Kumar's account that committee feedback can now be handled in a day describes the current process. It does not mean every deal has been shortened by the same amount. Technical leaders should break “speed” into measurable workflow steps rather than extrapolate overall returns from timing figures in one case.
For organizations considering a similar approach, a prudent starting point is a repetitive task with relatively clear boundaries. Let domain specialists build an internal prototype, keep human review in place, and record which outputs are accepted, revised, or rejected. Deployment in a company-hosted portal does not by itself prove that agreement data protection, access permissions, audit trails, or compliance arrangements are adequate, and the case does not describe those details. Only when quality checks and