He was almost sure, and that was the problem.
Daniel has spent 6 years on the payments platform of a mid-sized fintech company. It has 14,000 files in 3 languages, with code that was written by people who left long ago. He knows it better than almost anyone, and that's why everyone turns to him.
Last spring, in an architecture review, the team asked whether anything besides the settlement job wrote to the balances table. The others didn't want to wait while he searched, so Daniel said what he believed: "Only settlement." He was wrong. A refund path wrote there too. It had been added 2 years earlier for chargebacks. The migration that they planned that afternoon broke refunds for a whole weekend.
The alternative wasn't much better. Every time he said "Let me check and come back to you", the discussion moved on without him. The decision was then made on someone else's guess.
"In a design review, you can't stop the room to search the code. And you can't afford to be confidently wrong about it either."Daniel
Chapter 2 · A Scenario that knows the codeHe linked 14,000 files in 5 minutes.
Daniel created a Scenario called Architecture Review · Payments. He linked the repository from the folder where it lives on his disk, and limited it to the file types *.cs;*.sql;*.md;*.yaml. He linked the folder of architecture decision records too, and added the team's service map. OnSubject.AI indexed everything on his PC. The repository's README explains what lives where. It became a core document, so every answer knew where to start looking.
Then he wrote down the rules that mattered most to him:
- Always name the file and the method. A claim about our code without a location is a guess.
- Say only what the code, a test, a comment or an ADR shows. If it isn't there, say "not in the code" and tell me how to check.
- When someone asks why, quote the comment, the ADR or the test that explains it.
- Keep it short and precise, because I'm talking to engineers.
"It's only the settlement job, right?"
The idea was back on the table: move balances into a new ledger service. Elif, the staff engineer who was leading the review, turned to him and asked, "Daniel, it's only the settlement job, right?"
Daniel pressed his keyboard shortcut. The status line read Opening RefundService.cs while OnSubject.AI opened the file that it needed. He had the answer 2 seconds later, with the proof:
- ONSUBJECT.AI · 0.7 sSay: "No, 3 places write to balances:
SettlementJob.Run,RefundService.Applyand the nightlyFxRevaluationJob. Refunds have written to balances directly since chargebacks were added (ADR-017). If we split the ledger, refunds have to move first."
He said it, then opened RefundService.cs on the shared screen to show the line. The plan changed in 5 minutes: refunds would move to the ledger first, then balances. The team didn't have to come back to it the next week.
After another 40 minutes, Marco suggested dropping the order lock timeout from 30 seconds to 5. He said, "A 30-second timeout feels arbitrary." Daniel didn't remember why it was 30 seconds either. He typed Why is the OrderLock timeout 30 seconds? into the box under the transcript:
- ONSUBJECT.AI · 0.6 sSay: "It isn't arbitrary. The card acquirer retries a capture after 25 seconds, so the lock has to last longer than the retry. The comment above
OrderLock.Acquiresays so. ADR-022 records the incident behind it: duplicate captures. At 5 seconds, they come back."
Then Elif shared a sequence diagram from the design document, and Daniel used Answer + screen. The diagram showed refunds calling the ledger directly. But in the code, RefundService publishes a RefundApplied event that the ledger consumes. The diagram was fixed before the meeting ended.
It remembered what they had decided.
A week later, someone asked what they had agreed about refunds. Daniel's Scenario remembered the previous review word for word, so the answer quoted the decision and the file that it was about. The new ledger shipped a month later, with refunds first, and this time the team didn't lose a weekend.
"I stopped saying 'I think the code does this'. Now I say where it does it."Daniel
Source code and AI. Check your company's rules before you use its code with an AI service. OnSubject.AI indexes the repository on your PC. When you ask for an answer, it sends only the passages that the answer needs.
An illustrative story: the names and companies are fictional. OnSubject.AI works the way the story describes.
