[3Qs with AI CoE] Guest Chintan Parekh
A deep dive into Probabilistic Architecture, the “Survey Room” method, and why ROI is the wrong metric for AI.
Most podcasts are 45 minutes of fluff wrapping 5 minutes of insight. We skip the weather, the “how are yous,” and the generic bios.
Welcome to 3 Questions with Trilogy AI Center of Excellence.
The rules are simple: I ask the guest three rigorous, tailored questions based on their actual work. They ask me zero to three questions back. We are done in 15 minutes.
For this episode, I sat down with Chintan Parekh. Chintan is an AI Innovation Specialist with a background that offers a distinct advantage in our current landscape: he is a former Financial Engineer (Goldman Sachs, Barclays). While traditional software engineers often struggle with the unpredictability of AI, Chintan spent his early career building models for markets that are inherently volatile.
Here is what we uncovered.
1. The Fundamental Flaw of “Software Engineering” in AI
In our conversation, Chintan identified a critical friction point in the industry: Computer Science graduates do not automatically translate to the AI systems architects .
Why? Because traditional software engineering is Deterministic.
A developer expects Input A + Input B to always equal Output C. If it doesn’t, it is a “bug” that must be fixed.
But AI is Probabilistic. It behaves less like a calculator and more like a volatile stock market. Chintan argues that you cannot “debug” a probability distribution; you can only “hedge” against it.
The “Hybrid” Architecture (The Pricing Example)
Chintan shared a specific architecture he uses for a renewal project involving price hikes.
The Problem: The system needs to quote a renewal price with a specific increase (25%, 35%, or 45%) and send a persuasive email.
The Mistake: A standard engineer might ask the LLM to “calculate the new price and write the email.” This is dangerous because LLMs are bad at math and might hallucinate the number.
The Solution (Segregation of Duties):
The Rails (Deterministic): Chintan wrote a Python Lambda function to handle the math. It hard-codes the 25% increase. It is 100% accurate, 100% of the time.
The Brain (Probabilistic): He passes that calculated number to the AI and instructs it only to write the email body around it.
You cannot “debug” an LLM into being a calculator. If you aren’t building “wrappers” to hedge against the model’s variance, you are exposing your system to unnecessary risk.
Spiky Point of View:
A robust AI system requires a “Hybrid Architecture” where the AI is treated as the Creative Director, but deterministic code acts as the Compliance Officer.
2. The “Survey Room” Pattern (Consensus Architecture)
One of the most innovative concepts Chintan introduced was his method for eliminating hallucinations without fine-tuning. He calls it the “Survey Room,” a concept borrowed from marketing focus groups.
If you ask one person a question, they might lie. If you ask three diverse people and compare their notes, the truth emerges. Chintan applies this to LLMs:
Room A (Homogeneity): He might run the prompt through three instances of GPT-4 to check for consistency.
Room B (Heterogeneity): He runs the same prompt through GPT, Claude, and Gemini.
Room C (The Evaluator): He uses a separate model to act as the “independent evaluator.” This model reads the outputs from the other models, cross-examines them, and synthesizes the final answer.
Loyalty to a single model provider is a strategic error. Gemini might be better at financial context; Claude might be better at creative nuance.
Spiky Point of View:
The most reliable systems don’t just prompt a model; they arbitrate a debate between multiple models to filter out hallucinations.
3. The Dashboard Experiment (Speed vs. Debt)
We discussed the danger of “Vibe Coding” - using AI to generate code without understanding the requirements. Chintan shared a real-world experiment involving two engineers tasked with building a dashboard using Cursor.
Engineer A (The Speed Demon):
Method: Immediately prompted the AI: “Build me a dashboard.”
Time: 30 minutes.
Result: A visually stunning dashboard that was completely hollow. The backend was fake (placeholder data), the database wasn’t connected, and it had massive security flaws.
Engineer B (The Architect):
Method: Spent the first hour just talking to the AI. He “quizzed” the AI to help him write a detailed Product Requirements Document (PRD). He defined the data sources, the security schema, and the architecture before writing a line of code.
Time: 6 hours.
Result: A fully functional, secure, production-ready application connected to the database.
Speed is a vanity metric if the architecture is hollow. The 5.5-hour difference wasn’t wasted time; it was Architecture Time. If you skip the PRD because the AI makes coding fast, you are just generating technical debt at high velocity.
Spiky Point of View:
The human role has shifted from “Writer of Syntax” to “Architect of Requirements”.
The Reverse Card (The ROI Paradox)
Chintan challenged me with a difficult question: “We spend a fortune on AI tools like Cursor and BrainTrust. If we can’t strictly measure the ROI, how do we know we are an AI-first company?”
1. The “Tuition” of Failure
Traditional ROI is a lagging indicator. In the early stages of a tech shift, you are not paying for efficiency; you are paying tuition. We are actively paying to find the dead ends before anyone else does.
While other companies spent a year forming committees to debate whether to use LangChain, we deployed new AI tools daily, brake them, learned the limits, and moving on.
Spiky Point of View:
The true ROI isn’t in the dollars saved today; it is the Speed of Learning. We are buying the privilege of making mistakes faster than the market. The company that fails fastest wins.
2. Organizational Neuroplasticity
The biggest return is invisible and unquantifiable on a balance sheet: it is the rewiring of the workforce’s brain. This is Organizational Neuroplasticity.
Before AI, I would receive a task and immediately burn mental energy on low-level execution -worrying about syntax, libraries, and “how” to code it.
Now, I assume the AI can handle the syntax. My brain immediately jumps to System Architecture. I spend 80% of my time designing systems rather than writing functions.
Spiky Point of View:
You cannot put a dollar value on a workforce that consists entirely of Architects rather than Coders, but it creates an insurmountable competitive moat.
3. AI as the “Debt Killer”
There is a pervasive fear that AI generates technical debt. I argued the opposite. AI is the ultimate tool for reducing debt - but only if you have the ego to use it correctly.
I don’t just use AI to write code. I use it to roast my code. I explicitly tell tools like Claude: “Act as a hostile Senior Engineer who hates me. Find every flaw in this logic.”
Spiky Point of View:
Used this way, AI ceases to be a shortcut and becomes a 24/7 Quality Assurance layer that raises the bar for every single line of code we ship. It doesn’t lower standards; it enforces them ruthlessly.