Steve Taplin talks with Rational Exponent VP of AI Products Brian Bauer about building AI products for regulated industries, how re:agent helps banks map regulations to policies and improve adherence, and how vibe-coded UX prototypes (including tools like Lovable) speed up validation and reduce SDLC iteration. Brian also shares why he prefers problem-first product design over “tech-first” invention and advises leaders to narrow AI use cases into a few high-impact, reusable capabilities.
In this episode of Software Leaders Uncensored, host Steve Taplin (CEO of Sonatafy Technology and author of Fail Hard Win Big) speaks with Brian Bauer, a multi-time CTO and VP of AI Products at Rational Exponent. The conversation covers why Rational Exponent was formed, how the company applies AI to regulated industries (starting with banking), how their product supports compliance teams, and how prototyping tools are changing product development.
Rational Exponent’s origin and focus
Brian says Rational Exponent was started about two years ago, and that he has been there from day one as employee number one. He explains that he and the other founders have worked together multiple times over the last decade, including at a company that later exited via sale to a large GSI. After doing separate work for a few years, they regrouped due to what Brian describes as a major technology shift driven by AI—something he characterizes as larger than the internet or the rise of cloud computing.
When asked about industry focus, Brian explains that the company started with a banking-first approach. He says he has 30 years of capital markets and investment banking experience, and that the founding team has similar backgrounds. Instead of building technology first and then searching for a problem, he describes their approach as starting with known problems and opportunities in banking—across revenue generation (“first line”), risk management (“second line”), audit (“third line”), and regulatory oversight—and then building AI solutions for those needs.
The company’s flagship product: re:agent
Brian identifies Rational Exponent’s flagship product as re:agent (styled “re colon agent”). He describes it as a product that supports regulated organizations, with a primary example centered on helping a bank’s second line of defense (risk management) address regulatory and policy alignment challenges.
Brian describes the problem: banks are overseen by regulators such as the OCC, which publishes large volumes of regulations in handbooks that can change over time. Risk teams must create and maintain bank policies, standards, and procedures that align to those regulations. Brian says large banks may employ large numbers of people to read regulations, locate related internal policies, and evaluate whether policies adequately cover regulatory requirements—then repeat the process when regulations change.
He explains that re:agent is designed to read and interpret regulations (which Brian describes as difficult to understand due to government language), map a bank’s internal policy library to the relevant regulations, evaluate whether each policy adheres to regulatory requirements, identify where a policy is insufficient and explain why, and provide suggested replacement or updated language that users can accept or edit. Brian states that their interpretations are “heavily tested using evals” in their lab to ensure correctness. He contrasts the manual effort (days or months) with the product’s output speed (seconds or minutes).
Impact on compliance teams
Brian says customers describe the product’s value in practical terms—removing what they consider the worst part of their job and freeing time for higher-value work. He suggests that, especially during periods he calls “deregulation,” banks want risk and compliance teams to spend less time maintaining the status quo and more time supporting growth, new product initiatives, or M&A activity. He adds that some customers describe the outcome as “amplifying” their resources.
Team size, distribution, and “follow the sun” execution
Brian says Rational Exponent has around 30 engineers and operates as a distributed company, with team members across the United States, Latin/South America, and Europe. He describes this as enabling a “follow the sun” model, where work can progress across time zones for extended daily coverage.
How product and engineering stay aligned
Steve asks about typical product/engineering friction. Brian describes a structure where he communicates product needs in business terms, then a product team (“intermediaries”) translates those requirements into developer-ready specifications—turning functional and non-functional requirements into items such as JIRA tickets and user stories. He says this helps reduce friction by ensuring translation happens close to engineering and architecture.
Brian also says alignment requires direct and continuous communication, especially in a fast-moving startup. He emphasizes addressing dysfunction quickly rather than deferring it. He describes a culture of openness and honesty—sometimes blunt—aimed at resolving issues quickly.
In addition to video calls, he says the company brings pods of developers, engineers, and architects together in person, as frequently as once a month, sometimes flying people to Pittsburgh for a couple of days.
Vibe-coded UX prototypes and rapid iteration
Steve asks about “vibe coded” UX prototypes. Brian references a recent Andreessen Horowitz (a16z) article discussing “forward deployed engineers” and says he has a strong negative reaction to that model. He explains he prefers subject matter experts close to the business who understand the domain, rather than deeply technical people being pushed forward to learn the business.
He says new tools—including vibe coding—enable business-oriented product leaders to produce higher-fidelity UX concepts. As an example, he mentions using Lovable to describe a UI/UX concept and quickly generate a rendering, then iterating on it through prompting.
Brian says the quality depends on the depth of the prompt and documentation. He gives an example of producing 95 pages of documentation to guide the tool toward a specific UX. He says providing both the written requirements and a visual prototype helps engineering teams better understand intent and reduces iteration time in the SDLC.
He also describes using prototypes for early customer feedback. With a visual experience in hand, he says it becomes easier to validate direction with selected customers and rapidly incorporate changes before handing off to engineering.
Common mistakes Brian says organizations make
When asked about mistakes, Brian points to a pattern he sees in some AI startups: building a technology “gadget” first, then trying to find a problem to solve. He distinguishes between invention and innovation, arguing that innovation requires applicability, viability, ROI, and a clear business case. He states his preference for starting with who will buy the product, why they will buy it, and what it changes for them—then crafting the technology to fit.
Advice on AI use cases: fewer, better, and foundational
Brian’s closing advice focuses on AI use case selection. He says some organizations generate extremely large AI use case backlogs (he cites examples of “a thousand”), but in his experience many of those do not require AI. He further suggests that some of the remaining ideas may not have sufficient ROI to proceed.
He recommends carefully reviewing use cases, using common sense, and looking for ways to consolidate many use cases into a smaller set of foundational capabilities that can be built well and reused broadly. He references an MIT article stating a high percentage of AI projects fail to show revenue or ROI and are abandoned, and ties that to poor use case selection.
