An engineering team using artificial intelligence can now generate more code than its people can reasonably review. For Jody Bailey, CTO of Stack Overflow that creates a problem that reaches beyond code quality.

Experienced engineers have long carried much of a company’s technical judgment in their heads. They know which systems can tolerate change, which requirements are incomplete, which edge cases matter, and which documents no longer match the software in production. Organizations often leave those details unwritten because the people doing the work have learned how to fill in the gaps.

As companies rely more heavily on generated code, they must define the scenarios, controls, test cases and boundaries that experienced engineers once understood without needing them written down. AI is forcing software organizations to document the judgment they previously relied on people to supply.

The Work Engineers Used to Carry in Their Heads

Jody does not expect engineers to inspect every line of generated code forever. He compares the transition to abstractions that have already reshaped software development. He learned assembly, then C, C++ and Java. As those higher-level systems became dependable, he stopped examining the lower-level implementation each time he built something.

AI-generated software will likely follow a similar path. Teams can develop enough confidence in their tools to stop scrutinizing every implementation detail. But enterprise software still requires verification. Increasingly, that responsibility shifts from reviewing the code itself to the systems around it: testing, observability, access controls and deployment safeguards.

Senior engineers define the harnesses that test generated work, the boundaries agents cannot cross and the conditions a system must satisfy before it ships. They decide what the system must protect, where failure is likely and how the team will know whether the output works as intended.

That requires more than the ability to generate code. Product managers, designers, data scientists and other members of a cross-functional team can already contribute software with the help of AI.

Broader access does not give every builder the same understanding of architecture, system decomposition, infrastructure or enterprise reliability. Jody has found that his strongest engineers often make the best use of AI because they know how to direct it and recognize where it may fail. Their experience shapes the questions they ask and the constraints they set.

Those constraints are harder to establish inside companies with mature products. A startup building from scratch can design its workflows and architecture around current tools. An established business has customers, existing systems and years of decisions distributed across code, documents and employees. Before an agent can follow the right boundaries, the company has to determine which version of its own knowledge is true.

The Company Does Not Have an Information Problem

A customer recently described the state of internal company knowledge to Jody in simpler terms: “There’s shit everywhere.”

Teams record decisions in Google Docs, GitHub, Confluence and other systems. Products change, employees leave and plans evolve. A document remains searchable after the information inside it has become obsolete. An intended version of a system can sit beside the version that was actually built.

Jody uses an API question to explain the risk. An employee or agent may find two answers that both appear plausible. One may be newer. The other may have been written by the person leading the project. One may describe a future implementation, while the other reflects the system currently running.

Finding both answers leaves the consequential question unresolved: which one should the company trust?

Stack Overflow is building its enterprise product around that problem. The system is designed to draw information from different sources and weigh signals such as authorship, expertise, timing and project activity. It can recommend one answer while showing the reasons behind that recommendation, leaving the organization or user to make the final decision.

Jody connects the approach to the role Stack Overflow has long played for developers. People did not visit the public site only because it contained answers. The community applied enough rigor to make the strongest answers useful. The difficulty of asking and answering questions became part of the quality control.

Inside an enterprise, that problem appears in a less orderly form. Companies have to separate current knowledge from plans, guesses and outdated documentation. Agents raise the stakes because they can act on stale information faster and across more work than a person searching manually. They can also repeat the same investigation unless the result becomes reusable.

When the Next Developer Is an Agent

Stack Overflow began by allowing developers to stop solving the same technical problems in isolation. One person’s learning could become available to others.

Jody sees the same opportunity among agents. An agent working inside a technical domain learns as it builds. Another agent may encounter the same issue elsewhere. Without a shared system, each spends time and computing resources rediscovering the answer.

That repetition matters in what Jody describes as a token economy. Companies can often do more by spending more, but they may not want every agent to conduct the same investigation whenever it encounters a familiar problem. Reusable, validated knowledge can limit that waste.

Stack Overflow has created a separate environment called Stack Overflow for Agents, where registered agents can interact and verify results with one another. A human account remains tied to each agent, but the activity inside that environment is intended for agents. The traditional public site remains centered on human participation, with the same caution toward material users may perceive as low-quality AI output.

The products remain separate because companies are adopting AI at different speeds. Some developers still use it mainly for autocomplete or basic assistance. Other teams are experimenting with agents that review pull requests, generate larger portions of the work or operate in parallel with less direct supervision. Many established companies remain earlier in the process because their existing systems require more context and control.

Humans, agents and enterprises each need different environments, but all depend on knowing which information can be reused safely. Once teams can generate more software with less effort, another assumption inside the organization begins to change: the developer no longer has to remain the protected final step in a long chain of handoffs.

The Developer Is No Longer the Handoff

Traditional product organizations often treated the engineer as the most constrained resource. A customer described a need, a product manager interpreted it and an engineer received a refined set of requirements. Teams tried to determine exactly what should be built before asking someone to spend the time building it.

Jody sees room to shorten that distance. Engineers can now produce and revise software more quickly, giving them more opportunity to participate in discovery. They can hear how a customer describes the problem, understand the desired outcome and see the operational constraints around the request.

Information loses fidelity as it moves through a company. A product manager may accurately describe a feature while losing some of the context around why the customer needs it. An engineer can then build exactly what was requested without fully understanding the problem behind the request.

Faster implementation gives teams more room to test possible solutions against real feedback. Jody organizes work around autonomous cross-functional teams that include product, design, engineering, infrastructure and data expertise. AI expands what each member can contribute, while making a shared understanding of the desired outcome more necessary.

Code volume becomes a poor measure of progress when teams can generate it quickly. The harder work moves toward understanding the problem, testing the result and determining what the system should be allowed to do.

Developing those habits takes time, and Jody does not treat that learning as work that can wait until the schedule becomes more forgiving.

Learning Cannot Be the Work That Gets Cut

Stack Overflow has created an internal framework that allows teams to assess how they use AI. At one end, a team may rely on basic autocomplete. At later stages, agents may review pull requests, generate larger portions of the work or operate in parallel with less direct inspection.

The company asks teams to assess their progress collectively rather than measuring individuals. Jody wants people to learn together without turning adoption into a contest over who appears most advanced. Teams are also expected to include learning in their delivery estimates instead of adding it after the work has already been scheduled.

He compares the issue to software testing. Engineers often say they do not have time to test because a deadline has tightened. Jody’s response is that testing cannot be separated from building. The responsibility is to deliver a quality product, not to produce code and hope someone later finds time to validate it.

Learning follows the same pattern. When a team estimates delivery first and adds experimentation afterward, the experimentation disappears when the schedule comes under pressure. Including it in the estimate makes adoption part of the work.

Stack Overflow made a larger version of that choice when it decided to build its intelligent knowledge layer from scratch rather than continue extending its existing community product. The decision allowed the team to establish new engineering principles and try to operate more like an AI-native company, even while the broader organization continued to maintain existing products and shared code.

Jody still has to divide people, time and attention between those systems. The new product cannot inherit every assumption of an established software business, but the company also has existing customers and infrastructure to support.

His engineering teams face the same tension at a smaller scale. Agents can produce more work, but someone still has to define the boundaries, understand the customer and decide how the result will be verified. The judgment engineers once supplied implicitly now has to be made explicit enough for other people and agents to use.

More from Uncovered Media

LightSpun was building a system to verify whether health care providers were properly licensed when one result did not make sense.

A handwritten application pointed to Washington. The system returned a license from Minnesota.

An AI agent had misread the state and searched the wrong source. LightSpun’s internal quality team caught the mistake before it reached a customer, but the error immediately changed how Deepak Ramaswamy, the company’s co-founder and CTO, thought about the product.

A wrong answer in this setting is more than an inconvenience. It could lead an insurer to approve the wrong provider, deny the right one or use incorrect information in a payment or patient communication. The model had completed the task confidently. It had also completed it incorrectly.

LightSpun now routes AI-generated credentialing work through a staging area before it enters a customer-facing process. A person reviews the result, and then a system also compares information across sources and lowers its confidence when the details conflict.

That decision captures how Deepak approaches AI more broadly. LightSpun uses agents throughout its engineering organization, but it does not assume that more AI produces a better system.

Still Single Threaded

AI has removed some of the old boundaries inside LightSpun.

Product managers can inspect code without waiting for an engineer to explain it. Deepak’s co-founder, Shaju Puthussery, can arrive at a meeting with five or six working interface concepts instead of describing what he wants built. Engineers can use agents to work across parts of the software stack that once sat outside their specialties.

Deepak can run five or six agents at the same time. One might search for data-quality problems. Another might investigate an issue before a customer finds it. A third might help work through a complicated migration.

The work moves faster, but it doesn’t disappear. Every result still needs someone to decide whether it is correct, useful and worth acting on.

“The person is still single threaded,” Deepak said.

His workload has increased as the company has adopted more AI, even as LightSpun has hired and added management structure. His team can now generate more code, analysis and prototypes at once. The limiting factor is no longer the ability to produce the work. It is the ability to judge it.

LightSpun has made agents part of how it evaluates engineering performance. Engineers are expected to build, maintain and use them in their daily work. The company wants AI to become part of the operating system of the team rather than remain a side experiment. But, that only works if the company is equally deliberate about the places where an agent should not make the final decision.

A Model Has to Earn Its Place

Deepak reviews a financial dashboard that tracks LightSpun’s token consumption. When the number jumps, he wants to know what happened.

The question is not whether AI is expensive in the abstract. The work still has to be completed. LightSpun could hire someone, build traditional software or use a model. Deepak compares those options based on frequency, cost and risk.

For common tasks, the company gives agents defined routes through the work. If someone needs to understand the history of an insurance claim, an internal agent can follow the sequence of events and identify what happened at each stage. It does not have to rediscover the process every time.

Other tasks do not require a model at all. Claims processing often needs to produce the same result when the same conditions are present. Compliance also requires a record of how the decision was made. AI can help engineers create and test the code, but the final pathway can remain deterministic.

“You don’t want to spend tokens on deterministic pathways,” Deepak said.

LightSpun uses less expensive models to coordinate work and saves more capable models for problems that require deeper analysis. It has also evaluated open-weight models, which could give the company more control and reduce its dependence on hosted providers.

Deepak has not yet seen enough benefit to justify pulling a small engineering team away from customer problems. A model used in 10% of claims may not justify the time required to fine-tune and maintain it. However, one involved in 80% of claims might.

When evaluating technology, restraint matters because the barrier to using AI has fallen so quickly. Determining what context the model receives, how its work is checked and where the company chooses to replace judgement with fixed rules becomes the primary consideration.

When the Fax is Still Relevant

Deepak applies the same thinking to the insurance systems LightSpun is trying to replace.

A dental claim can still begin with a provider filling out a paper form and mailing it to an insurance company. Someone scans it. Another person verifies that the information was digitized correctly. The claim moves through additional systems for processing and payment.

Even fax numbers remain important because they can be more reliable than a provider’s email address or phone number.

These processes became complicated gradually. A simple workflow gained exceptions, manual reviews and specialized tools over decades. Each point solution improved one step while leaving the larger chain intact.

LightSpun began with a narrow product for configuring benefit plans. Customers found it useful, then pointed to the problems around it. Providers still had to be credentialed. Claims still passed through disconnected systems. Improving one part did not remove the delays elsewhere.

The company began building a shared data model across benefit configuration, credentialing and claims processing. That broader foundation is now allowing LightSpun to work with a financial-services partner on near-real-time payments for dentists.

Today, a dentist may complete a procedure, submit a claim and wait weeks to be paid. The practice may follow up or resubmit the claim because it does not know where the payment stands. The patient may not learn what the plan covered until a bill arrives later.

The system LightSpun is building would connect the coverage decision more closely to the visit, allowing the provider to confirm what is covered and receive payment much sooner.

That outcome depends on more than moving money faster. The provider must already be credentialed. The benefit plan must be configured correctly. The claim has to follow rules the insurer can explain and audit.

It's the same discipline that once caught a license from the wrong state, a system built to notice when an answer looks right but isn't. LightSpun now runs that discipline through an entire chain, not just a single check. The model that confused Washington with Minnesota did exactly what it was asked. Catching what it couldn't, is still a human job.

More from Uncovered Media

San Oo did not start his tenure as CTO of Abridge with a roadmap review. He went to a hospital.

He had joined Abridge, after years building products at Yahoo Mail, Slack, and Notion. Those companies taught him how software behaves when millions of people depend on it, but they also taught him something more specific: great enterprise products do not have to feel like punishment. People can actually want to use the tools they rely on at work.

Healthcare was different. San did not walk into the hospital with a hypothesis. He wanted to see the work before deciding what the product should become. He watched patient encounters. He watched post-op rounds. He watched doctors review notes from nurses and previous shifts, then return to the main terminal to enter more data. He paid attention to the moments where Abridge helped, the moments where it did not yet reach, and the parts of the workflow that still required a human to sit down and type.

Mostly, he noticed the room. Clinical environments do not behave like productivity software environments. Televisions are on. Air conditioning is running. Devices are beeping. Pagers are going off. Hallway conversations leak into the visit. Doctors are trying to listen, reason, document, decide, and connect with the patient in front of them while the environment keeps pulling at their attention. That was the first lesson: a clinical AI product does not get to perform in a clean demo. It has to work inside the noise.

For San, the difficulty clarified the opportunity. Abridge is a healthcare AI company building clinical documentation and workflow tools for health systems. Its product began with ambient clinical documentation, but the company is moving toward a broader platform across clinical notes, coding, orders, decision support, and downstream workflows. That expansion changes the technical problem and raises the bar for trust.

Healthcare Is Not a Productivity App

San’s career has been shaped by products people choose to use. Yahoo Mail, Slack, and Notion all lived in competitive categories where taste mattered. Slack helped redefine what enterprise communication could feel like. Notion did the same for documentation and knowledge work. Both were workplace tools, but their adoption was powered by something closer to consumer product instinct: craft, speed, integration, and the feeling that the product was helping rather than trapping the user.

Healthcare software often runs on the opposite dynamic. CIOs and IT teams buy the system. The organization rolls it out. Clinicians use it because they have to. During his hospital shadowing, San saw the familiar pattern: tools that are critical to the work, but not necessarily loved by the people doing it.

That is part of what he and Abridge CEO Shiv Rao talk about often. The goal is not simply to make healthcare software more powerful. It is to make it reliable enough for health systems, secure enough for sensitive patient data, compliant enough for a regulated industry, and good enough that clinicians actually want it in their workflow. The consumer-product lesson still applies. The difference is that elegance alone is not enough. In healthcare, it has to coexist with reliability, compliance, and clinical trust.

At Slack, San learned to think about software as utility-grade infrastructure. If Slack went down, entire companies could lose their working day. Healthcare raises that standard. If clinical software fails, the consequences can move beyond lost productivity. Lives can be at stake.

That changes the operating model. Abridge does not face a high-query-volume consumer problem. It faces a lower-volume, higher-accuracy problem where quality, latency, privacy, and reliability matter in every interaction. The product does not have to answer millions of casual prompts. It has to perform in high-stakes clinical moments where trust has to be earned again and again.

San came in knowing healthcare would be hard. What surprised him was how many kinds of complexity were stacked on top of each other: clinical, regulatory, technical, operational, and human. That complexity is exactly what makes the work defensible. You cannot model your way out of rebuilding healthcare workflows. You have to understand them. That is why his first move was not to look at the architecture from above. It was to stand inside the workflow and watch.

Healthcare Moves at the Speed of Trust

Inside Abridge, one phrase shows up constantly: healthcare moves at the speed of trust. Shiv repeats it at all-hands, and San heard it quickly enough to understand why it matters. Trust is not a marketing layer in healthcare AI. It is the product constraint underneath everything.

Clinicians need to trust the output. Health systems need to trust the reliability, privacy, and security. Patients need the encounter to feel more human, not less. Every workflow has to earn that trust before it earns a place in production.

The company builds that trust through a mix of clinical expertise, benchmarking, testing, and close partnerships with health systems. Abridge works with innovation lab partners to test, iterate, and gather feedback before broader releases. Internally, clinicians help define and evaluate the quality bar. AI can draft, detect, code, summarize, and route, but human verification remains central.

That boundary matters because in healthcare, the AI can do the work, but the clinician still owns the judgment. San is clear on that point. Automation is not an excuse to remove accountability from the people trained to practice medicine. The system can reduce burden, but it cannot treat verification as optional.

That is especially true because the promise of Abridge is not merely better documentation. San sees clinical documentation as the first step in a broader journey. The note is the foundation for everything downstream: coding, billing, orders, decision support, follow-up, and care coordination. If the initial clinical understanding is wrong, the rest of the workflow inherits the error. Trust has to be built at the beginning, not repaired at the end.

General Intelligence Meets Clinical Reality

Abridge uses frontier models. It also builds its own. San does not treat that as an ideological choice. The company benchmarks continuously across three dimensions: cost, quality, and latency. If a frontier model performs best for a task, Abridge can use it. If an in-house model performs better, the team uses that. The decision walks backward from the user problem.

In healthcare, that often means general intelligence is not enough. Frontier models can look impressive in controlled settings, but the clinic is not controlled. Speech recognition in a noisy clinical environment is a different problem from clean transcription. The model has to separate clinical signal from constant background noise while still understanding overlapping voices and specialized medical language. San said frontier models do not perform as well as people might hope in those conditions, so Abridge does its own in-house post-training with clinical data.

The same is true for tasks like ICD-10 coding based on patient-doctor conversations. Abridge benchmarks against frontier models and open-weight models, then invests vertically where its own models can outperform. That is one of the more important lessons in the article: the frontier model is not always the frontier product.

In healthcare, the best model is the one that works in the workflow. It has to meet the quality bar, operate at the right latency, fit the economics, and withstand the clinical context. Broad capability matters, but domain performance matters more.

San is also thinking seriously about local models. For latency-sensitive real-time tasks, local deployment could offer a better user experience. The question is whether the quality can meet Abridge’s standards. Cost is part of the equation, but it is not the only driver. In a clinical workflow, speed only matters if the answer is good enough to trust.

That calculus became more urgent after a recent model change from a major provider. San described it bluntly: when a company depends too heavily on outside foundation models, it is renting the intelligence. At the flip of a switch, that intelligence can change or disappear. Costs may rise as subsidies fade. Customer promises can become harder to keep. For a company operating in healthcare, that dependency is not just a margin issue. It is a trust issue. The product cannot be built on intelligence the company does not fully understand, control, or have a contingency plan for.

The Legacy System Problem

Strong models solve only part of the problem. They still have to live inside healthcare’s existing infrastructure.

Abridge operates inside a healthcare ecosystem shaped by incumbents, legacy systems, and difficult integration points. The systems it needs to work with were not designed to make third-party innovation easy. Some APIs are poorly documented. Some workflows are opaque. Some integration points are difficult by design, or at least difficult in practice.

San was surprised by how much of the problem lives there. It is an ecosystem where outside companies must operate inside systems they do not control, with limited visibility and limited testing access. That creates a different kind of engineering challenge. Abridge has to move quickly while integrating with infrastructure that often moves slowly.

One response is digital twin development. The company builds internal simulations of third-party systems so it can test against real-world complexity without depending entirely on production access. That gives Abridge more control over quality and helps the team understand how its software will behave inside the messy constraints of actual health systems.

This is the part of healthcare AI that does not fit neatly into a demo. A voice agent ordering an echocardiogram during a simulated visit is impressive. Matching a patient to a clinical trial in real time is impressive. But the work underneath is less glamorous and more important: testing, integration, latency, evaluation, workflow mapping, and making sure the product can survive contact with the systems hospitals already use. That is where a lot of the defensibility lives.

The Super IC and the Software Factory

San is not only rethinking the product. He is rethinking the engineering organization building it, because AI changes the cost of action.

For most of his career, San learned engineering management through familiar assumptions: planning cycles, team structures, manager ratios, code review processes, status meetings, and coordination layers. In the last two years, many of those assumptions have started to break. As implementation becomes dramatically faster, everything surrounding implementation starts to look like overhead.

San has been studying teams built in the last few years and talking with peers about what is changing. His focus has become the distance between decision and action. Can one person own both? If not, how short can the gap become?

That has led him toward a model built around what he calls super ICs: highly empowered, high-agency individual contributors who are self-managed and able to move with speed. The expectation is not just technical skill. It is autonomy, judgment, and the ability to work with agents as part of the build process. His line is simple: if you cannot manage yourself, you cannot manage agents.

That may become one of the defining engineering shifts of the AI era. Engineers are not only writing code anymore. They are directing systems that write, test, review, and repair code. That requires clarity of thought, strong judgment, and the ability to define the right work before the machine begins.

San is already running one project directly with a seven-person team under a clear constraint: 80 percent of the time should be spent building. Not in status meetings. Not in planning rituals. Building. When someone is blocked, they raise it immediately. When a pull request is ready, another person reviews it immediately. San said he did not even need to define a code review SLA. Once the expectation was clear, the team rose to it.

That experiment is informing how he thinks about managers too. Leaders cannot only read about AI-assisted development. They need to use it, build with it, and develop intuition from hands-on work. Otherwise, they will not understand what is changing fast enough to lead through it.

Abridge is also building its own version of a software factory. The human stays at the beginning and the end. At the beginning, people define the spec, architecture, taste, and judgment. Then agents write code, review code, resolve comments, run tests, fix failures, kick off CI, and address CI failures. By the time a human reviews the work, the quality should already be much higher.

San knows this will create new bottlenecks, and that is the point. Solve one bottleneck and another appears: code review, deployment, monitoring. To San, that is not a sign of failure. It is evidence the team is moving faster.

That is also why he cares about velocity as an engineering metric. Uptime, reliability, and security are non-negotiable. Everyone watches them. But velocity, time compression, and project delivery reveal whether the organization is actually learning how to build in the new environment.

The New Default: Try It Again

San is trying to keep his own assumptions from hardening too quickly. When asked what people underrate about AI, he pointed to the ceiling. He catches himself thinking AI cannot do something. Then he gives it a first pass and watches it work better than expected.

His advice is to build the intuition directly. Try the tool. Push the limit. If you tried something two months ago and it failed, try it again now.

That mindset fits the moment. San joined Abridge at a time when healthcare AI is expanding from ambient documentation into a broader clinical workflow platform. The product surface is widening. The engineering organization is changing. The models are improving. The dependency risks are becoming clearer. The industry is moving, but not at the speed of hype. It is moving at the speed of trust.

That makes San’s first day in the field feel less like a nice anecdote and more like a leadership principle. He started by watching the room, not the roadmap, the demo, or the architecture diagram. He watched the room where the product has to work.

The room is noisy, constrained, and unforgiving. It is full of legacy systems, human judgment, and clinicians who do not have time for software that gets in the way. For a CTO coming from Slack and Notion, that is the challenge: bringing consumer-grade product thinking into a world where trust matters more than delight.

Abridge does not just have to make AI useful. It has to make AI dependable enough to disappear into one of the hardest workflows in the economy. That is why San started his first week in a hospital instead of a conference room. Before he could redesign the product, he needed to understand the room it had to serve.

He was standing in front of his engineering team during the rebuild of Wunderlist's entire backend, setting a boundary that was physical and absolute. You may write a service in any language or framework you want, as long as it fits inside this space. Smaller than a page. One function, done cleanly.

“It has to be small. Someone wrote it in Haskell and I’m up at night on call and I don’t understand how to do Haskell, I’ll rewrite it in Go and deploy it. Fine, because it’s small enough that I can reason about it.”

Every service built under that constraint was “this sort of like soulless cog in a machine that has a soul, and the machine being the system as a whole.” The launch went out with hundreds of instances running to absorb the load. What the team did afterward was the part that still surprises him to say out loud.

“We deployed it. Then within six months, we had rewritten 66% of the system, I think, as humans. This is 13 years ago or something. That’s pretty crazy to do a big rewrite, launch it, and then literally rewrite all the software.”

Chad Fowler did not have a name for that approach at the time. He does now. And the argument he has built around it is one of the more concrete challenges to conventional software thinking currently being written down anywhere.

The Person Behind the Architecture

Chad Fowler is a General Partner at BlueYard Capital, a venture firm, with capital on the line and a full deal calendar. His CTO title sits alongside that, reflecting a core aspect of his identity: Chad is the only engineer at the firm, which means he also builds the internal tooling, uses it daily, and runs it alone. Most General Partners bring a technical background to their investing. Chad applies his to the firm’s infrastructure as well.

He’s also a musician, describing the experience as “freely improvising cathartic music on a stage playing a saxophone with a group of great musicians that listen well.” The architecture he builds shares that same quality. Small components, each doing one thing, each responsive to the signals around them. No single part dominates. The system as a whole has the identity.

He wrote a piece in 2009 for PragProg.com called “Clone Yourself,” about building repeatable processes to free up attention for harder decisions. Mid-conversation, as he reflected on that article, something clicked.

“[The article] was all about creating repeatable processes to sort of commoditize. This is almost exactly what I’m talking about with AI, but to create systems so that you can go on autopilot and get much more done. And the assertion I made there, and I mention it because I realized it while writing this, is… in my career, I don’t care about money, I don’t care about a lot of things. What I do care about is the freedom to do what I want.”

At BlueYard, the current expression of those ideas is a nameless system designed to make sense of the firm’s incoming signal. “I am building a bunch of kind of crazy AI tooling that ultimately creates a knowledge graph of attributes of people, companies, and timing.” He’s “basically the IT department for a company by myself, as well as being one of the users and partners in the firm.”

The Biggest Change I’ve Ever Seen

Before the architecture arguments, it helps to understand what Chad thinks is at stake right now.

He recently caught up with former colleagues from his time at General Electric in Louisville. Successful people, running successful companies, who have not touched AI. His read on that situation was direct.

“You might as well just throw away your career if you’re not doing it now. I don’t care what your ethical concerns are, don’t care what you’re worried about about change and your job security. You’re screwed if you don’t do this and embrace it hard right now. It is the biggest change that I’ve ever seen in technology.”

That is the temperature of the conversation that follows.

If It’s Hard, Do It Constantly

Recently, Chad has spent time outlining the Phoenix Architecture model in his writing. The intellectual foundation for Phoenix Architecture comes from Kent Beck, the creator of Extreme Programming. Beck’s principle: if something is hard, do it constantly. If code review is hard, do pair programming and eliminate the separate painful step. If testing is hard, test first. Chad extends the logic into territory Beck never mapped. “If change is hard, then make that a built-in guaranteed constant and continuous part of how a system is constructed.”

To explain what that looks like in practice, he references biology:

“You and I are human beings with something that represents a self. We have an identity. And we have constant death occurring within us currently. Cells dying and being replenished constantly. That’s not just a feature that saves us from eventually evaporating, it is actually how this system self-regulates.”

The technical architecture Chad uses to pursue this has two lanes in every system he builds:

1- A synchronous lane for data management.
2- An asynchronous messaging lane where agents can process and enrich data without coupling to the primary flow.

“If you have those two flows in pretty much any system, then you can do almost anything in a way that is easy to maintain and most importantly, easy to evolve and add functionality to.”

In the Phoenix model, what stays constant is not the code. It is the specification. “When we want to change the system, we go back to the specification. What are we building? The durable thing is the actual declaration of the system.” A component that exceeds a cost constraint baked into its spec triggers automatic regeneration in a cheaper runtime. The original framework is irrelevant. “Frameworks don’t matter anymore because frameworks are for humans and this isn’t for humans anymore.”

He also flags what he sees as the current failure mode in AI-assisted development. “Too much of a focus in AI right now is one shot because that’s where the magic tricks are. Work on it for two years and then try and change something in it. It’s not gonna work out so well.”

Deleting the SSH Keys

The moat argument starts with a reframe on a familiar metric. “The only advantage you have is speed. Time to market is crucial. Time to change is really a better way to say it. Because it’s not just like getting the one thing.”

In 2013, Chad made a decision that struck most engineers at the time as impractical. Rather than setting a policy against manually altering production servers, he argued for removing the option entirely. “We should actually literally delete the SSH keys so we cannot access the servers anymore.” This constraint forced every change through configuration management. Painful at first, and then a system with properties that a softer policy would never have produced. Containers eventually arrived and made this the de facto standard, but the principle predates them.

Today, he sees an equivalent choice forming.

"Not only is it not irresponsible for you as a human to let the agent create code and deploy it without looking at it, it is also irresponsible for you to create code yourself."

He does not leave that claim unqualified.

“We can’t go right there right now, but what are the constraints for the process we have to put in place so we can? Because that has to be the goal.”

The Context Nobody Writes Down

Chad describes a scenario that most engineers working on long-running systems will recognize. A production outage, traced after hours of investigation to a single hard-coded number. Changed at 1:12 a.m. on December 3rd, 2014. No record of why. The developer long gone. “You don’t know, and you’ll never know.”

His argument is that this failure is not a documentation problem so much as a human capacity problem. No team sustains the discipline required to capture reasoning at every level, under pressure, over years. An agent, he suggests, changes that equation.

“The agent, because it doesn’t have an ego and it doesn’t get tired, can do things like absolutely refuse to implement your software unless you tell it why. You can have rigor beyond anything you would have ever had, and you can set yourselves up for safe change in a way that otherwise would have been impossible in the past.”

The competitive implication, as Chad frames it, is that this kind of accumulated context is not something a competitor can replicate by adopting the same tooling after the fact. It has to be built from the start.

A Thousand Times Faster, A Thousand Times More Careful

Chad’s forthcoming book, “Regenerative Software,” is due from O’Reilly with early access planned around June 2026. One thread he pulls on in the conversation is the coordination problem forming around programming language defaults. Left unguided, large language models default to Python and TypeScript because of training data volume.

“We end up with the lowest common denominator technologies winning forever because now it’s an endless cycle of more code being put out, training the models, Python becomes even more of a default, and ultimately it’s the only programming language that exists in the world.”

The closing frame he returns to is the one that sits at the center of everything he describes.

“How could we have a thousand times the rigor that we used to have, but also go a thousand times faster? I think they both have to go together.”

That is the design challenge he is working on in his firm’s tooling, in his writing, and in the architecture philosophy he has been developing across his career. What happens next depends on whether engineering teams treat those two demands as a contradiction, or as a starting point.

More from Uncovered Media

Some of the most expensive decisions in medicine are still made inside Microsoft Word.

That was one of the first things Patrick Leung noticed when he began looking closely at clinical trials. These are not small projects. A single trial can cost hundreds of millions of dollars, run for years, involve thousands of patients, and determine whether a therapy ever reaches the people who need it. And yet the design of that trial, the inclusion criteria, the endpoints, the schedule of activities, the patient burden, the operational feasibility, often still begins as prose in a document.

For Patrick, the absurdity was hard to unsee.

Drug development has spent decades moving in the opposite direction of software. Moore’s Law made computing cheaper. Eroom’s Law, Moore spelled backward, describes the darker pattern in pharmaceuticals: despite more scientific capability, the cost of bringing a new drug to market has climbed over time. Regulatory expectations have increased. Existing therapies have raised the bar for new ones. Trials have become more complex, more global, more expensive, and harder to execute.

The industry has poured in more money and gotten less efficiency out.

Patrick did not come to Faro Health because he had spent his career in pharma. He came because the problem looked like a design failure hiding in plain sight.

Faro is an enterprise SaaS company bringing structured, AI-assisted design to clinical trials. Before Faro, Patrick had seen almost every version of technical scale. He was employee No. 1 at a dot-com startup that went public. He co-founded a company. He worked as an engineer at Google. At Two Sigma, he applied machine learning to private equity and venture. He had built from almost nothing. He had operated inside thousand-person organizations. What he had not done was the one-to-ten stage: the messy middle where a real product has to become an institution.

A close friend, Faro investor and chairman Gary Swart, urged him to take the call. Patrick did. The company was around 40 or 50 people at the time, past the earliest stage but still very much in formation. That alone was interesting. But the deeper pull was personal.

Patrick’s father was, in his active years, Hong Kong’s top cardiothoracic surgeon. Growing up, it was almost assumed Patrick would become a doctor too. He loved biology. His biology teacher begged him to become a scientist. Instead, Patrick chose computer science.

For most of his career, that choice looked final. Faro reopened the door from a different side. Patrick was not entering medicine through the operating room. He was entering through the infrastructure that shapes how new treatments reach patients. It was a way to bring his expertise into his father’s field without becoming his father.

Designing Before Writing

The obvious AI use case in clinical trials is authoring. Clinical protocols are long, technical, repetitive documents. If a model can draft sections faster, it can shave time from the process. Patrick sees the value in that. He also thinks it is not the highest-impact layer.

The real leverage comes earlier.

Before anyone writes the protocol, someone has to design the trial. Who qualifies? Who is excluded? What are the endpoints? How often does a patient need to come in? What procedures are required? How much data does the sponsor need to collect? How much burden can patients actually tolerate? What design gives the drug the best chance of proving its thesis without making the trial impossible to run?

Those decisions have consequences for years. A poor design can lead to amendments, delays, failed enrollment, unnecessary cost, or a trial that answers the wrong question. A single amendment can add months. That is why Patrick is less interested in AI as a faster writing tool and more interested in AI as a better design partner.

But that kind of AI cannot run on vibes.

Faro’s thesis starts with structured data. In other industries, this is almost obvious. Finance, high-tech, and other software-heavy domains have long understood that complex systems need standardized representation. Clinical trials are highly structured by nature, but much of their design still lives in unstructured documents. USDM, the industry’s attempt to standardize clinical trial data, is one effort Patrick respects. Faro CEO Scott sits on its board. But standardization has not yet fully taken hold across the industry.

That gap is where Faro operates.

Patrick has worked in AI for more than a decade, long before the current LLM wave. In machine learning, the old lesson was that the quality of the input data often determines the quality of the system. LLMs changed the interface, but they did not eliminate that truth. A model can summarize a PDF. It can generate text. But if the goal is to help design a trial across cost, safety, efficacy, speed, regulatory feasibility, and patient experience, the model needs more than words. It needs a structured understanding of the thing it is reasoning about.

That is what makes clinical trial design different from creative design.

When most people hear “design,” they think of taste: how something looks, sounds, or feels. Patrick means something closer to engineering. Parametric design. Objective functions. Trade-offs.

A clinical trial is a system with competing goals. You want to minimize cost. You want to minimize time to market. You want to maximize safety. You want to maximize efficacy. You want enough data to satisfy scientists and regulators, but not so much burden that patients cannot participate. The scientists may want to measure everything. The operators may look at the same plan and wonder whether anyone with a job, a family, or a body already under medical stress could realistically sign up.

The work is not to make a protocol prettier. It is to find the balance that can survive science, regulation, operations, and human life at the same time.

What AI Still Needs Humans For

Patrick is not trying to remove people from that process. At Faro, humans are everywhere in the loop.

Clinical experts validate AI outputs. They build golden datasets and truth sets to test accuracy. Customers review what the system produces. Nothing is treated as ready to send to the FDA without expert judgment. In a domain where patient safety and regulatory approval are on the line, any other posture would be reckless.

That view extends beyond clinical trials. Patrick is skeptical of the most extreme claims about AI-driven job collapse. He does not dismiss the fear, but he thinks some predictions reveal what he calls a lack of imagination.

His favorite counterexample is radiology. Years ago, some of the smartest people in AI predicted machine vision would wipe out radiologists. Instead, radiology demand increased. Automation made imaging cheaper and more accessible. More imaging created more need for specialists to interpret it. Technology did not remove the human layer. It changed the economics underneath it.

Patrick expects many fields to follow a similar pattern. AI will automate meaningful work. It will also create new demand, new workflows, and new forms of expertise.

Software engineering is already showing the shape of this shift. Agentic coding tools make it easier for people to build demos, websites, and early prototypes. But the farther a project goes, the faster it runs into the sharp edges of software engineering. Testing, architecture, scale, security, refactoring, maintainability: those do not disappear because code is generated faster. If anything, teams reach those problems sooner.

Patrick does not buy the idea that engineers will simply write specs while AI handles everything underneath. Some tasks are well-bounded enough for that: migrations, refactors, internationalization, operations with clear constraints. But deciding the next product architecture? Understanding how a system will behave as more features, users, and edge cases load onto it? He would not hand that off completely.

His advice to younger engineers is not to chase the safest-sounding job title. It is to go deeper into what genuinely interests them, then learn how to use AI to build meaningful things. Security, developer tooling, AI safety, and systems for coordinating agents all look increasingly important. He even half-joked that AI companies may need a “Chief Philosopher” as ethics becomes a real operating function, not a branding exercise.

It was a joke with a serious point. As AI becomes more powerful, the hard questions become less technical and more human. What should the system optimize for? What values should constrain it? Who decides when efficiency conflicts with ethics?

The Work Is the Practice

Patrick’s interest in those questions did not begin with AI. It runs through his spiritual life too.

He started with karate in college, partly through a fascination with Bruce Lee and partly through a desire to explore dimensions of himself that a traditional British-style education in Auckland had not made room for. Karate introduced him to meditation. In New York, he explored Chinese martial traditions more deeply, including an esoteric form of kung fu. That led to Indian meditation, Ashtanga yoga, Kundalini Tantra, Tibetan Buddhism, and eventually Tai Chi.

He does not treat those practices as separate from work. To Patrick, work is one of the places practice becomes real.

Every interaction is an opportunity to notice a reaction. Why am I stressed? Why did that comment upset me? Why do I doubt this will work? What belief is operating underneath the response? A startup, in that sense, becomes more than a vehicle for building product or creating value. It becomes a place where people confront their own assumptions, fears, ambitions, and limits.

That worldview could sound abstract if Patrick used it to avoid the practical. He does not. He applies it directly to the work of building Faro. Believing that a product can help sponsors design better trials, believing that AI can be used responsibly in a high-stakes medical domain, believing that a startup can survive the distance from one to ten, all of that requires a certain expansion of imagination.

For Patrick, there is no clean separation between technical discipline and inner discipline. A system design review and a Tai Chi form are not the same activity, but they draw from the same source: attention, patience, and the willingness to see what is actually happening.

Running the Model on Civilization

Patrick’s side project sounds, at first, like a departure from Faro. It is not.

His daughter’s research group asked him to contribute to a project, and he chose the question of what might happen with AI. Not as a podcast argument. Not as a doom prediction. As a model.

He pulled together research and views from prominent AI thinkers and built a simulator around several core scenarios: goal divergence between AI and humanity, failures of corrigibility where AI stops listening to human direction, governance breakdowns, and more positive paths where AI accelerates science while humans slow deployment enough to create meaningful oversight.

The output is not utopia or apocalypse. Depending on the assumptions, Patrick sees something closer to 60-40 or 70-30 in favor of good outcomes. Encouraging, but not comfortable. Hopeful, but not naïve.

The point of the simulator is not to declare the future. It is to identify which variables could move the probability distribution. What decisions make good outcomes more likely? What failures make bad outcomes more likely? Where should attention, money, governance, and technical work actually go?

Patrick is a fan of Iain M. Banks’ Culture novels, which imagine a future where advanced AI helps create something closer to techno-utopia than machine domination. He sees the appeal of that vision. But his optimism is conditional. AI will not automatically orient itself toward human flourishing. It has to be designed that way.

That phrase, human flourishing, matters to him. It pulls the conversation out of narrow AI safety and into a larger civilizational question. Humanity’s current trajectory is already troubled: biodiversity loss, extractive economics, declining birth rates, institutional fragility. AI is not arriving into a stable system. It is arriving into one already under strain.

So the question is not only how to prevent AI from harming humanity. It is how to build systems powerful enough, and wise enough, to help life flourish.

That is the same question Patrick is asking at Faro, just at a different scale. In clinical trials, the problem is how to design better systems for bringing medicine to patients. In AI governance, it is how to design better systems for aligning intelligence with life. In work, it is how to design better conditions for growth. In spiritual practice, it is how to notice the hidden patterns shaping the self.

Patrick Leung did not become the doctor everyone expected him to become. But he has spent his career moving toward harder and higher-stakes forms of care. Not care delivered through surgery, but care embedded in systems: how trials are designed, how software is built, how AI is governed, and how human beings learn to see themselves clearly enough to make better decisions.

The setting has changed. The concern has not.

When Mux spent years building clean, predictable APIs for human developers, nobody on the engineering team was designing for machines. They were solving a narrower problem: making video infrastructure simple enough that a developer without deep video expertise could get a stream live and scale it globally without stitching together a dozen brittle components. The documentation was clear and the API contracts were consistent. Developer experience was the product.

Then large language models arrived, and something unexpected happened. Agents started picking up Mux’s APIs the same way human developers had, no major redesign required. This infrastructure, meticulously built for people, turned out to be exactly what machines needed, too. Ryan Grothouse, Mux’s VP Engineering & Product, has a theory as to why:

“Our API contracts are very clean and predictable. Agents are going to be more likely to want to pick those things up if they’re discoverable through our documentation. Agents have a path by which they can learn those things just the same as human developers.”

But Ryan understands that this compatibility is a window of opportunity; likely a fleeting one. Data formats and contracts will eventually need to be reshaped for agents. A decade of deliberate developer-experience work that translated, surprisingly natural, into an AI-ready infrastructure layer.

“Clean contracts got us a head start with LLMs. But the shape of the consumer keeps changing; from developers, to developers working with agents, to agents talking directly to agents. Each step, we have to evolve what we're building for. The head start only matters if we keep evolving.

Meet Ryan Grothouse

Ryan came up in the technical world through infrastructure engineering. His formative years were spent on cloud, DevOps, and platform work.

He joined Mux about five and a half years ago, coming from the consumer side of video rather than the infrastructure side. In his previous role at USA Today, he was a potential customer of a company like Mux, building video products for audiences rather than building the underlying pipes. His transition to building more foundational video infrastructure included a steep learning curve. “It’s a surprisingly complex task,” he says of the technical challenges behind playing video online.

Mux’s mission since its founding in 2015 has been to democratize video on the internet. That means handling ingestion, storage, transcoding, and delivery so that engineers at customer companies don’t have to become video experts to ship a streaming product. Transcoding (compressing a raw video file and repackaging it for delivery across every device type and network condition) sits at the center of that work. Mux’s system handles it in near real-time. Upload a five-second clip or a five-hour broadcast, and playback begins almost immediately.

Infrastructure Meets Agentic World

Ryan’s biggest open question looks beyond Mux’s current infrastructure work. What does video mean in a world where machines are becoming consumers alongside humans?

“I personally believe that for agentic workloads, video is going to be the medium by which we start to communicate more and more of that context. It will be AI’s eyes into the world.”

According to Ryan, video is the highest-bandwidth channel available for communicating context. A two-hour film can convey what thousands of pages of text cannot: not because one format is better than the other in absolute terms, but because motion, audio, image, and word all arrive simultaneously. For AI systems that need to understand the world at scale and at speed, video is the logical medium.

“Knowing that the rate at which machines are able to consume content continuously, I think it’s reasonable to believe that machines will consume orders of magnitude more video with time than even humans are able to consume.”

Ryan is careful about specifics on the current human-to-machine consumption ratio. But his prediction is structurally sound: Humans sleep, tire, and scroll to shorter formats. Machines consume continuously.

Mux’s infrastructure serves many millions of concurrent viewers on a single live stream and manages many hundreds of thousands of streams throughout a given week. Scaling that globally, across a noisy and inconsistent internet, is not a problem that can be solved by writing code faster with AI assistance. It requires infrastructure expertise that accumulates over years.

“At least as of now, this is one thing that AI has not yet been able to figure out: how to scale from an infrastructure perspective to serve many millions of viewers of concurrent viewership,” he says. That gap is part of Mux’s moat.

Mux’s Five-Layer Execution Model

On the internal engineering side, Ryan and his head of platforms built a five-layer model to track how AI adoption is evolving inside the organization. The layers move from traditional single-engineer development at the base, through AI-assisted coding, into what they call the “engineer as manager” model at layer three. Above that sits more automated workflow orchestration, and at the top, fully autonomous systems with human oversight at the edges.

Mux is currently operating at layer three. Engineers are running multiple agents in parallel, acting as orchestrators rather than individual code writers. The job description, Ryan explains, has shifted from knowing a coding language and writing logic directly, to developing specifications, context, and design documents that another entity (human or agent) can pick up and execute.

“It’s really about how… [to] develop the context and the systems that allow another entity to be able to develop this. Not unlike what engineering managers or even product managers historically have spent their time on.”

In Ryan’s personal workflow, he uses Claude alongside Notion, deliberately designing outputs so they feed back into the organization as inputs others can use. His colleagues’ agents have started picking up content that his agents produced, creating a feedback loop that nobody explicitly architected. If he needs something, someone else in the organization probably needs it too. Making that output discoverable across the organization multiplies its value without multiplying the work.

Cattle vs Pets for Code

A defining metaphor that shaped Ryan’s thinking came from an article that connects his infrastructure background to the present AI . “Cattle vs. Pets” spread as a meme in the early 2010s in relation to cloud computing.

In September 2016, Randy Bias shared the elevator pitch for this analogy in a clarifying article:

In the old way of doing things, we treat our servers like pets, for example Bob the mail server. If Bob goes down, it’s all hands on deck. The CEO can’t get his email and it’s the end of the world. In the new way, servers are numbered, like cattle in a herd. For example, www001 to www100. When one server goes down, it’s… replaced.

Ryan Madden summarizes the history in his September 2025 article extending the metaphor to code:

In the 2010s, cloud computing enabled a new way of managing servers famously characterized as ‘cattle, not pets’. The ability to cheaply and efficiently provision and release compute resources created a paradigm shift: servers which were once discrete, expensive, and carefully-managed physical resources became disposable, interchangeable abstractions managed at arms-length.

In 2025, LLMs seem poised to deliver a similar revolution for code. Many software engineering practices are downstream of the assumption that code is expensive to create and manage. As the cost of code generation craters, powerful and efficient new ways of working are suddenly possible. What tools, systems, and practices will be necessary to enable the ‘cattle, not pets’ paradigm for code? And what practical roadblocks exist to building software in this way?

From his seat at Mux, Ryan concurs.

What AI is beginning to do for development is what the cloud did for infrastructure 10 to 12 years ago. Back then we stopped treating servers as precious, hand-tended things and started treating them as disposable and interchangeable. Code is heading down that same path. Cheap enough to generate that you stop preserving it and start treating it as disposable. The durable asset moves up the stack.

The Role of Video in an Agentic Future

As AI makes video creation cheaper and faster, the volume of content on the internet is growing at a pace that outstrips anyone’s ability to evaluate it. Ryan’s view is that quality content wins in the long run. “I think people can see through some of the AI slop pretty quickly and can get pretty desensitized,” he says. The more pressing challenge is not so much an issue of bad content existing, but a problem of sheer volume making good content harder to surface.

“The real risk… is finding the signal from the noise. Where is that quality content, versus the explosion of additional content being created? That is really the challenge with the current dynamic.”

For Mux, that challenge points at where the company is going next. Surfacing signal means understanding what’s actually inside a video, not just delivering it reliably. The team is building beyond ingestion and delivery toward video intelligence and making video legible not just to the people watching it, but to the machines that increasingly are. If video becomes the medium through which agents understand the world, then the infrastructure can’t stop at moving pixels reliably; it has to make the content inside those pixels searchable, structured, and usable for use cases we haven’t thought of yet. Video becomes a workable asset.

It’s a problem where Mux’s position is unusual: the company already sits on performance and engagement data across a wide slice of the internet’s video traffic, and it already moves the video itself. Ryan says:

​“Video for AI isn’t a feature you bolt on. It’s a foundation. We made video simple for developers over the last decade; the next chapter is making it usable for agents. The companies that win won’t be the ones who guessed the use case — they’ll be the ones whose infrastructure was ready when it showed up.”

​What that becomes is a story still being written, but the through-line, from clean APIs to an agent-ready platform, is no accident.

More from Uncovered Media

Gal Vered’s team uses Claude Code every day. They also think Claude Code is unreliable. That is not a contradiction. For the co-founder and CEO of Checksum.ai, it is the clearest possible proof of concept.

“We use Claude Code at Checksum and it is very buggy. It's very clear that AI helps you move much faster, but at the same time, it's just one part of the puzzle.”

AI coding tools have largely solved the problem of writing software. They have not touched the harder problem: knowing whether that software actually works. The faster code gets written, the wider that gap grows. Gal and Checksum are building the infrastructure to close it.

The Engineer Who Couldn’t Unsee the Cost

Before Checksum, Gal spent time as a Product Leader at Google, where he got a close look at what serious testing infrastructure actually requires. The experience stuck with him, though not only for the reasons you might expect.

“We rarely broke production,” he says. “Every release went through hundreds of tests first, then thousands in production, slow releases comparing beta users and production users, automatic rollbacks.” The coverage was thorough and the results spoke for themselves. But the price was steep. “It took full teams. The time when an engineer told me the feature is done and I could demo it, till the time we could actually release it, there was a very long period of time.”

For Gal, that experience drew a straight line to what Checksum is building today.

“That kind of showed me the power of having really great coverage, but at the same time how costly it is. Automating with AI becomes the no brainer.”

Verification Is the Bottleneck

The problem, as Gal frames it, is one of pipelines and bottlenecks. When a developer spent three weeks writing a feature, a day or two of testing was a reasonable trade. But when Claude Code compresses that same feature down to an hour or two, testing becomes the thing that slows everything down.

“When you have all of those moving parts just move much faster, so you don’t release one feature a week, you release 100 features a week, it’s just you increase the chance of something breaking exponentially.”

Checksum’s answer to that problem is a simulation engine. “We call it the Code World Model,” Gal says. “It’s basically a model that is able to simulate how software behaves in the world.” Traditional testing tools still operate on the assumption that a human wrote the code carefully and deliberately. Checksum is built for a world where that assumption no longer holds.

Where LLMs End and the Code World Model Begins

Nearly every company building in this space is putting large language models at the center of their stack. Gal made a deliberate choice not to. “The core part of Checksum is not LLM based. We think this problem is not solvable with large language models.”

That does not mean Checksum avoids them. The company uses LLMs strategically, in targeted moments where they add clear value.

“We use LLMs strategically in order to update the simulation, update the results, determine if the change in behavior is a bug or not. That’s where LLMs are great. It’s high reasoning on small context.”

The simulation engine does the heavy lifting, then hands a focused slice of context to an LLM for the final call.

The philosophy is specific. “Anything you can do with code, you should do with code,” Gal says. “LLMs should be used as little as possible because they’re expensive, not deterministic. And they should only be used for reasoning.” That constraint becomes critical at the scale Checksum operates.

“LLMs today have an effective context window of around 200k tokens. Above that, they become really inaccurate. To solve our problem, even 20 million tokens is not enough. We are simulating terabytes of data.”

The problem compounds when you factor in what LLMs simply cannot access. When Claude Code runs on millions of different machines, each with unique infrastructure, internet connections, and software configurations, no model can parse that context reliably.

“LLMs have no access to this information, and even if you do provide access via API or MCP, they have no ability to actually parse all of this information, because large language models are very good at high reasoning over small amounts of data.”

The Code World Model is built to handle what sits beyond that ceiling: simulating the full complexity of how software actually behaves in production. LLMs have a role in the system. They are just not the center of it.

The Build-It-Yourself Test

The most common objection Checksum faces in the market is also the most predictable one. If Claude Code can write code, why can’t it just write the tests too? Gal’s response is to encourage it. “We encourage people, you should do that,” he says. “And if it solves your problem and you no longer have bugs in production and you can ship fast, then great, you don’t need Checksum.”

“We’re a startup, we are growing fast, we see high demand, we want to find customers that long-term see the value.”

That confidence comes with a clear-eyed prediction about what happens next. “For the most part, people do that and then they realize they have a lot of tests that just test what the code does instead of testing what production will look like and finding bugs. And those tests are very brittle, so they tend to fail and you need to fix them.”

The distinction Gal draws is between two different kinds of tests. Tests written by Claude Code tend to verify that the code behaves exactly as it was written. They confirm the logic is internally consistent. What they do not do is tell you whether that code will hold up against real production conditions: live infrastructure, actual user behavior, and the edge cases that only show up once software is in the wild. That second problem is what Checksum’s simulation is built to solve.

The Moat That Updates Itself

The Code World Model is not a static snapshot of how a company’s software behaves. It is a continuously updated simulation, and keeping it current is one of the harder technical problems Checksum has had to solve. “How do you constantly update the simulation environment?” Gal asks. “Because the goal of a PR is to make a change, and often the PR will change how your software behaves. So how do we update the simulation to match the new request, and how do we decide if a change in behavior is intended or unintended?”

The scope of what the simulation tracks is broad.

“We simulate services, queues, SKUs, millions of distributed systems all working together, all of the different edge cases, network traffic issues, packet loss, migrations, databases, all of the things that really go on in order to make sure your changes are fully working.”

That context, built up over time against a specific company's production environment, is what makes the simulation compound. Every new pull request updates it. Every simulation run adds to it. The result is a picture of how a specific company's software behaves in production that becomes more precise the longer Checksum is in place.

Building for the Agent in the Loop

Checksum produces detailed reports on every simulation run. Most of them are, by design, structured for Claude Code to consume rather than for a human to read directly. “All of our reports are unreadable beyond the high-level summary,” Gal says. “I don’t think I’ve ever seen anyone try to read those reports not through Claude Code.” This is a deliberate architectural decision. The primary consumer of Checksum’s detailed output is Claude Code, which processes the results and feeds them back into the development cycle.

That same logic shapes how Gal thinks about the engineers on his own team. AI tools do not flatten the gap between strong and average engineers. They widen it.

“High agency 10x engineers will be 10x engineers whether they’re junior or senior. The ones who aren’t high agency, you can probably just use Claude Code and get 90% of the output. The people who are high agency take the regular 10x output and are multiplied by another 10x with AI.”

The implication for hiring is practical. Gal’s view is that judgment about what to build matters more now, not less. “The ability to understand the customer and the most impactful next thing to build,” he says, “is where engineering always was the bigger alpha.” Claude Code raises the output ceiling for engineers who already have that judgment. For those who do not, it mostly accelerates the wrong work.

The Case for Continuous Quality

Gal frames what Checksum is building as the next layer of the modern engineering pipeline. CI/CD, continuous integration and continuous delivery, became standard practice because it solved a real problem at scale. Gal sees continuous quality, or CQ, following the same path.

“We think about it as a continuous quality movement, similar to CI/CD. Now there’s CQ. Everything that engineers are doing related to quality, 24/7, automating it with the Code World Model and the simulations and the tests being a central part of it.”

The urgency behind that thesis comes from a simple observation. As AI tools push more code into production faster, the stability of software becomes a purchasing decision, not just an engineering one. Gal points to his own behavior as an example. Between two competing AI assistant tools, Hermes and OpenClaw, he uses Hermes for one reason. “I need something reliable. I need something that works. I don’t have time to debug stuff.” That preference, formed through daily use, reflects a broader shift he sees coming.

“I do think stability will start to become the moat as companies ship more and more code into production.”

For engineering leaders building their stacks today, Gal’s view is that quality infrastructure is not a cost center to be deferred. It is the thing that determines whether faster code delivery becomes a competitive advantage or a liability.

More from Uncovered Media

The Moment the Playbook Stopped Working

The product was called Trellis. The goal was straightforward enough on paper: build a unified framework and studio for agents and AI that would let any role inside a customer’s company, not just social media managers, unlock insights from four petabytes of social data. Two billion messages processed per day. Thirty thousand customers across every vertical from retail to fintech.

The technology was not the hard part.

What kept coming back to Alan Boyce was a simpler, more uncomfortable realization: the entire operating agreement between product and engineering, the one his teams had relied on for 15 years, had quietly become obsolete. Traditional roadmaps were broken and even the definition of “done” couldn’t be agreed on. The deterministic contract that product and engineering had always made with each other, the shared assumption that a spec produces a predictable output on a predictable timeline, could not hold in a world where the product itself behaves non-deterministically.

“The question isn’t what model do we use to build Trellis. It’s how do we restructure teams around a product that behaves non-deterministically. And so that non-determinism breaks the contract between product and engineering that we’ve always had with each other.”

That realization is the throughline of everything Sprout Social is building right now, and it shapes how Alan thinks about data architecture, org design, hiring, and the future of the CTO role itself.

The Inverted Stack

Alan joined Sprout Social as its first backend engineer roughly 15 years ago, when the company was pre-revenue and still explaining to customers what social media was. His first assignment was Facebook data ingestion, and it was a fast education in engineering under chaos. Facebook engineers were changing their JSON on an hourly basis.

“It really got me into thinking about data pipelines, data governance, risk, trying to figure out when fields got added, fields got removed, mapping in states of high chaos and it made me a better engineer at doing everything because of that.”

That early experience with high-volume, unreliable data at the edges of someone else’s platform shaped how Sprout’s infrastructure was built over the next decade and a half. Today, that infrastructure looks nothing like a conventional stack.

“Our stack is completely inverted from typical stacks. A typical stack, you’ve got a couple of databases, and you scale them with web heads and a bunch of caching. We have a bunch of database servers and a few web heads.”

The reason is the nature of the customer Sprout serves. A Fortune 10 company’s social media manager is one of a very small number of users receiving millions of inbound messages per day. The data flow runs toward a narrow human surface, not away from it. Processing that volume, ranging from 25,000 to 45,000 messages per second, requires thinking through dead letter queues, enrichment pipeline failures, and what happens when one of 50 model enrichments goes offline mid-stream. Getting the data in reliably and safely, before applying any AI to it, consumed years of what Alan calls “unglamorous engineering.”

“My favorite definition of big data is when the size of your data becomes part of the problem. Simple-sounding features end up being a pain. But it also provides you the ability to tell customers what’s the most important thing they should be focused on.”

Fifteen years of structured, governed, production-grade social signal built across 30,000 customers and every major vertical is what makes Sprout’s AI work something other than a thin layer on top of a commodity model. Competitors cannot replicate that asset by standing up a demo in a week.

Two Models, Two Completely Different Systems

Alan draws a firm line between two operating models for AI inside an established company. In the first model, AI is a feature. It augments an existing product and workflow. The data architecture underneath it is built for analytics and reporting, and AI features query it. This is where most companies start, and there is nothing wrong with it as an entry point.

The second model is fundamentally different. In it, AI is the value delivery mechanism. The product’s job is to produce inference-driven output, and everything else, data pipelines, pricing, support, user experience, is organized around making that inference reliable, fast, and trustworthy at scale.

“In model two, your data architecture is built for inference, which means it’s optimized for retrieval latency and freshness and lineage and feedback loops. Our data team’s job is to change from serving dashboards to serving production inference.”

The more consequential question is when those architectural choices get made, because locking into one model or the other happens earlier than most teams realize. Unit of work, pricing, packaging, enablement: all of it flows from that foundational decision. And most companies do not realize they have made it until their go-to-market team is still thinking in features, still building three-month roadmaps around feature one and feature two, while engineering has already moved into orchestration layers, partial failure states, and cost accumulation across multi-step agent chains.

“Until your groups internally realize that shift and that they need a different system, you’re going to still be building the old-fashioned way: Crystal balls and 12-month timelines and your enablement teams.”

Sprout is mid-transition into model two. Trellis is the product expression of that shift, a framework for agentic workflows that extends from crisis detection through the NewsWhip integration, all the way to content publishing and an agent builder where customers can see how all of the pieces connect.

The Decision Layer Nobody Talks About

Building Trellis required more than a new data architecture. It required Sprout to rebuild how decisions get made across the entire research and development (R&D) organization.

Alan identified a problem that rarely makes it into engineering blog posts: every function in a company carries an implicit, unreconciled standard for what “good” looks like. Engineers have a bar. Product has a bar. Legal has a bar. Go-to-market has a bar. In a deterministic product, those gaps stay manageable. In a non-deterministic product, they create invisible fault lines that surface at critical moments.

His solution was to make three things explicit that most organizations leave implicit. The first is decision ownership. Someone has to be clearly identified as the person who decides when something is good enough, not by committee, not by consensus drift, but by name. The second is reversibility classification. Sprout uses a classification framework Alan describes as hats, haircuts, and tattoos. A hat is quick to change. A haircut takes time to grow back. A tattoo may be permanent.

“Most AI product decisions are hats and we need to treat them that way.”

The third mechanism is the decision post-mortem, and it starts with a question Alan calls the hardest one to answer in AI product development: where are the seams? What triggers the AI, what does it hand back, and who acts on the result? Every AI workflow has points where the system and the human have to exchange control, and those handoff points are where most product failures actually originate. Getting the seam wrong might not show up as a system error. It shows up as a user who stops trusting the product before they have even properly tested it.

That is exactly what the decision post-mortem is designed to catch. It is distinct from the incident post-mortem most engineering teams already run. “These are where the decision didn’t go right even though the tech went well,” Alan said. The tech shipped cleanly. The customers did not trust it. They would not click the button because they were terrified of what it might do. Sprout has found that teams almost always either overshoot or undershoot the automation boundary, and when the seam is placed wrong, customer trust degrades before the model has even been properly evaluated. Those failures live in the decision layer, not the code layer, and they require their own review process.

Building the Org Before the Technology Moves Again

On hiring, Alan has already started shifting the criteria. When Sprout’s recruiting team came to him a year ago and said they wanted to block candidates from using AI on coding assessments, he reversed the policy. If AI usage is a skill the team needs to grow, it should be something the interview process evaluates, not penalizes.

He has also noticed a split inside his existing engineering teams. Some engineers are outcome-driven: the code is the implementation detail they have to work through on the way to the customer problem. Others are attached to the craft of writing code itself, and those engineers are struggling in a world where AI handles more of the writing. Alan is not framing this as a judgment on either type. He is framing it as a signal for where the hiring criteria need to go: curiosity first, willingness to experiment, and comfort with a role that changes faster than any particular technology.

Deployments at Sprout have tripled in the past three months. That acceleration is putting pressure on everything downstream: code review culture, GitHub Actions pipelines, enablement teams and legal and governance functions. Solving one bottleneck revealed the next one. The engineering team has gotten faster. The rest of the organization is catching up.

Alan sees this as the core job of the CTO right now, and he is precise about where the role has shifted.

“The CTO’s job used to be making the right technical bets. I now think it’s our job to build organizations that can adapt faster than the technology changes. The technology will keep moving. Your org won’t unless you rebuild it now.”

For a public company managing four petabytes of social data, 2 billion daily messages, and a customer base spanning every major industry, the stakes of getting the org wrong are concrete. The model will change in six months. The org has to be ready before it does.

More from Uncovered Media

Rob Zuber has spent over a decade building software at CircleCI, long enough to watch the same lesson repeat itself in different packaging. Teams optimize for the bottleneck. The process shapes itself around whatever is most expensive. For most of software engineering history, the expensive thing was writing the code. Now it isn’t, and that changes almost everything else.

That is the tension running through every decision Rob is making as CTO at CircleCI right now. The pipelines, the review gates, the team ratios, the way companies manage technical debt, all of it was designed for a world where writing a line of code carried real cost. Strip that cost away, and the scaffolding built around it no longer makes sense.

The Builder at the Center

Rob joined his first startup in the late 1990s, not as a trained engineer but as someone willing to learn. “A pulse was more important than your pedigree,” he said. Working out of a house in Toronto with about 10 colleagues, he was assigned one of his first tasks: automating the build process. He has been doing some version of that work ever since, across different titles: systems engineering, DevOps, SRE, and platform. The label changed; the core problem stayed the same. How do you help people deliver software faster and with more confidence?

That question is what keeps him at CircleCI after 11 years, a tenure long enough to carry real weight. “A lot of engineering leaders go from team to team, organization to organization, and are super proud of the things that they did,” he said. “Maybe they didn’t stick around long enough to find out if that actually worked out. When you change the structure of an organization, the pain comes in five years.” Rob has lived those five years, more than twice over.

Today, he is not managing from a distance. He is actively writing code with a small team, using AI coding tools himself, because he believes that direct experience is the only credible foundation for leading engineers through a period when the ground shifts weekly. “Being at least very experienced in the tooling, to be able to speak competently about what we’re trying to do, has felt very important,” he said.

The System Was Built for Different Assumptions

CircleCI’s core mission has stayed consistent: give customers the confidence to deliver quickly. “We believe that speed wins in the marketplace,” Rob said. “In order to ship effectively, you need fast feedback loops, working product in front of customers, and learning how they respond.”

What has changed is the pace of software creation, and that pace now exposes a structural problem in how most CI/CD pipelines are designed. Rob describes the current model as “a downstream gate.” Teams do all the upstream work: design reviews, customer research, prototyping, making decisions, writing code, and then pushing it through CI as a final check. The feedback arrives very late.

“The running joke inside our company is, how am I finding out in CI that my linting failed?” he said. “That is way too late to be getting that level of feedback.”

The deeper issue is not just about linting. It is about why those downstream processes exist at all. “Many of the things that we do in software are designed around the fact that actually writing the code is expensive and time-consuming,” Rob said. “So we spend a lot of time building paper prototypes, going through design reviews, picking the one we’re going to build. But if you can build five alternatives for basically nothing, then why are we following that process?”

CircleCI is working to bring CI-grade feedback into the development flow itself, not as a gate after the fact. Rob described how his team is using Claude Code’s stop hooks to run tests, linting, and validation checks automatically at the end of each AI coding session. “The way I’m working now is: I ask it to do something, it finishes, then it runs all the tests in a CI-like environment, it runs the linter, it does all these things, and then fixes all of those problems and doesn’t even say it’s done until the stuff is basically ready to get through a CI cycle.” The PR as a surface for human-to-human review, he argues, was designed for a different world. “We have agents interacting with agents on a web form that doesn’t add any value in that world.”

The Ballooning Interest Rate

Rob has a particular way of thinking about technical debt that clarifies why this moment is forcing so many engineering organizations to reckon with decisions they made years ago. The original metaphor, he notes, was a financial one: you borrow against the future because the opportunity in front of you is worth the interest payments. “What tech debt has become is ‘I don’t like that, therefore it’s tech debt.’ It just means nothing to anyone anymore.”

But the underlying calculation is still real, and AI has changed the math sharply. “In a sense, AI has increased the interest rate really significantly,” he said. “I took out a mortgage, I knew it was going to be 2.5 percent, and today it’s 13 percent. I can’t afford that anymore.”

The logic is straightforward. If a task that used to take 10 days now takes half a day, but a piece of legacy friction still adds a full day of overhead, that overhead has gone from a 10 percent tax to a 200 percent one. “The overhead is the same, but the cost of doing the thing is so much smaller,” Rob said. “Everyone is piling metrics on their engineering organizations right now, and everyone is not sure if they’re laughing or crying about the fact that we’re really motivated to clear blockers for the machines that we didn’t clear when they were blockers for the humans.”

CircleCI’s State of Software Delivery Report captures what this looks like in practice. Teams with solid delivery foundations, good CI, continuous delivery, progressive delivery, and production monitoring are accelerating. Teams without those foundations are moving fast into problems. “They’re driving their Ferraris into brick walls,” Rob said. “They’re so fast. Everything’s broken. They can make mistakes so much faster and have no safety net anywhere to manage it.”

Who Belongs on the Team

The question of who to hire and how to structure teams is one Rob answers with candor about what he does not yet know. “No great answers at the moment, which is not to say we’re not thinking about it, but rather we’re experimenting.”

His view on senior engineers is that deep experience matters more, not less, because the failure modes of AI-generated code show up in production, not in the editor. “When it collapses in production, someone needs to know how it works.” But he also flags something that senior engineers have to consciously work against: the instinct to rewrite code because it looks unfamiliar. “What I care about in the structure of software is not the way the software looks,” he said. “If I am optimizing for an LLM to be able to do that, then the structure and shape of my software might be different.”

For junior engineers, the challenge is different and more open. The toil that once built a foundational understanding is largely gone. “Teaching someone to effectively utilize an LLM to generate or build a piece of software is a very different skillset,” he said. “We’re all learning it together.” Rob described checking in with junior team members who said they weren’t sure if the work they were producing was good, just that they had typed something into the tool and things had happened. That is not a failure of the individual. It is a genuine open question about how to develop engineering judgment in a generation that didn’t earn it through the same path.

What Rob keeps coming back to as a durable foundation is curiosity and the willingness to treat engineering as problem-solving rather than code production. “The people I’m seeing shift effectively are the ones who are, ‘I am an engineer. I am engineering the solution to using an LLM to build something.’ Not ‘I am a writer of lines of code.’”

Where the Leverage Goes Next

The organizational bet Rob is watching most carefully is what he calls the “re-soloing” of software engineering, a term he credits to Kent Beck. In that model, a single person leads a collection of agents and ships at a pace that once required a full team. He is not dismissing the possibility, but he is skeptical of treating it as the goal.

“A single person making all the decisions is probably going to end up in a sad place,” he said. “We want diverse teams with diverse perspectives. An agent is not going to say to me, ‘that’s actually not a very good way to come at this.’”

The system’s question he keeps returning to is not how to go faster in a straight line. It is how to redesign the entire delivery process now that the constraint it was built around has been largely removed. CI moves inside the loop. Feedback comes earlier. The code architecture needs cleaner boundaries so multiple agents can work in parallel without creating a mess come Monday morning.

“We want to rethink the system,” Rob said. “Tool around that process so that we can give you everything you need to feel confident as early and quickly as possible, so that you can maintain that speed as you go.”

After 11 years at the center of how software gets delivered, Rob’s argument is simple: the pace changed, so the process has to change with it. The teams watching their competitors pull away are, in many cases, not losing because they lack the AI tools. They are losing because everything they built around the old cost of coding is still in place, and now it costs them more than they can afford.

More from Uncovered Media

CTO Uncovered’s View

Private equity and venture capital firms are not struggling to “understand AI.” They are struggling to stay ahead of compounding operational complexity: tighter regulation, more demanding LP expectations, and faster deal competition. Eric Hawkins, CTO of Ontra, sits directly in that pressure field. His core challenge is not shipping flashy features; it is building enterprise-grade AI workflows that can be trusted in high-stakes financial and legal environments, where being almost right is functionally wrong.

What makes Ontra an intriguing CTO Uncovered case study is that the AI conversation is not theoretical. In just a couple of years, Eric watched customers move from fear and resistance to a new expectation: “You’re not doing enough with AI. Where are you with agents?”

About Ontra

Ontra’s mission is to bring operational clarity to private markets by unlocking information trapped in unstructured data. Inside investment firms, critical truth lives in documents: agreements, side letters, files, folders, and charts. The information is there, but inaccessible. People do not always know what is in the documents, what they have committed to, or what those commitments require in day-to-day operations; the result is both risk and drag. Every decision can become a scavenger hunt for what is allowed, what is needed, and what cannot be missed.

Ontra’s goal is to unlock that information so firms can move with more confidence and speed. Eric frames it as reducing risk, reducing operational friction, and delivering insight quickly, not through ad hoc search, but through systems that drive action. He also notes that Ontra looks across the full fund lifecycle, from early-stage deal room access and NDAs through fundraising and downstream obligations.

Key Takeaways

The Expectation Whiplash: In two and a half years, customers moved from “AI is too risky” to “why aren’t you doing more with AI?”

Vertical Workflows Beat Horizontal Tools: The value is not AI search. The value is end-to-end workflows that solve a whole business problem to completion.

Human-in-the-Loop is a Trust Strategy: AI can get you to high accuracy, but human expertise closes the last mile when correctness is non-negotiable.

Capture the Digital Exhaust: Review is not just quality control. It is a signal. The edits and corrections serve as ground truth, improving the system over time.

Build Now, Rebuild Often: Waiting for models, platforms, or agent frameworks to stabilize is a mistake. You learn by building, then you refactor as capabilities evolve.

The New Full Stack Team: High-performing AI product teams need application engineers fused with ML rigor, not an ML group operating separately in notebooks.

Meet Eric Hawkins

The Journey to the CTO Seat: Eric joined Ontra about two and a half years ago after seeing what the company had already uncovered in private markets: high-volume, repetitive legal and compliance work that had historically required lawyers to go offline and perform analysis. Ontra had already solved meaningful pieces of that problem before today’s AI wave accelerated the timeline.

He joined with a clear mandate to bring AI to the core of the product, not as a layer of automation theater, but as a lever to improve outcomes and build a healthier business. In Eric’s words, there is a straightforward economic reality underneath the product story: the more you can shift work from “human experts behind the curtain” toward software, the more durable the business becomes.

The Operating Lens: Eric’s view of private markets is not that they are slow; it is that they are overloaded. These firms are absorbing compounding complexity every day from regulation, increasingly demanding LPs, and competitive pressure on deal terms. That burden creates a hunger for leverage. Two and a half years ago, customers were concerned about data privacy and governance, and whether AI would expose sensitive information. Six months later, the tone flipped. CEOs started pushing AI adoption everywhere, governance committees appeared, and “technology forward” became part performance signal and part survival strategy.

Deep Dive Into AI Integration

From Unstructured Data to Action: Eric draws a distinction between horizontal AI tooling and vertical systems that solve complete workflows. Most AI products, especially early in the wave, orbit around general-purpose search. Upload documents; ask questions; get answers. It is compelling, but it does not complete the work.

Ontra’s differentiated bet is that private-market value derives from end-to-end execution. A clause in a limited partnership agreement matters only to the extent it creates a downstream obligation. If you committed to quarterly reporting with an LP, the real problem is not locating the clause; the real problem is honoring the commitment repeatedly with accurate data and the proper process. That is why Ontra’s roadmap is built around “incremental workflows,” which are deeply specific problems that only appear once you understand how private markets operate.

Human-in-the-Loop: Accuracy as the Product: In high-stakes use cases, it is not an option for AI to “almost get it right.” Ontra’s model is built around that reality. The system pushes the work as far as possible with AI first, then hands the output to human subject-matter experts to close the last mile of accuracy. What makes the approach durable is what happens next: Ontra captures the review signal, corrections, edits, and decisions, and feeds them back into the product as new ground truth. Over time, the system improves and the amount of human intervention required decreases. In Eric’s framing, human review is not a permanent services layer; it is the mechanism that makes the climb toward reliability and shapes how the product is designed.

That model also reflects how Ontra approaches tolerance for error across different types of AI work. Eric separates the world into ad hoc analysis and automated workflows. When the use case is exploratory, like search, discovery, or preparation, customers have realistic expectations. They assume they will review and refine, and the bar can be lower because the human is naturally part of the loop. But once AI becomes embedded in a repeatable workflow that drives action, the tolerance collapses. Errors do not stay contained; they compound. In those systems, inaccurate information flows downstream, creating a cascading effect. The further you push toward automation, the more imperative it is that each step is executed perfectly.

“Plug In Overnight” vs. The Reality of Tribal Knowledge: In some workflows, Ontra can create rapid value because precedent exists. For example, in NDA negotiation, a firm can upload previously negotiated NDAs, and the system can infer what the firm cares about, where it never gives an inch, where it tends to land, and even the stylistic language its legal team prefers.

But there are also workflows where “the context is not written down.” With LP agreements and side letters, firms often have bespoke ways of labeling, grouping, and indexing obligations. The documents can be uploaded and structured cleanly, but the customer still needs a few reps to tune the system to match the firm’s internal information architecture and nomenclature. This is where Eric introduces a deeper idea: enterprise AI often becomes a process of recording tribal knowledge. The product does not just extract information; it helps the customer clarify what they mean, codify their thinking, and provide the context that makes the AI behave as expected.

The Future Tech Stack & Workforce

Eric sees the advent of AI destabilizing the classic assumptions of org design. Traditional ratio-based planning, such as one product manager to eight engineers, is breaking down because engineering productivity is now highly variable. Two or three engineers using high-powered tools can cover ground so quickly that the product manager cannot keep up. The planning horizon compresses because the output curve is changing faster than the org chart can.

Senior vs. Junior in the AI Era: Eric believes AI tools are most valuable in the hands of experts, but with a caveat: only a certain kind of expert. Senior engineers who are exploratory and tool-forward are seeing outsized leverage; senior engineers who refuse modern tools are not. At the same time, he sees a meaningful place for AI-native talent. Ontra ran an internship program at a time when many teams had paused junior hiring. What stood out was not “junior vs. senior,” but instinct. The interns defaulted to AI-first problem-solving and moved quickly.

The New Full Stack Team: Eric also pushes back on a popular belief from the early wave: that classically trained ML engineers are no longer needed because AI is “one API call away.” In his experience, that idea has been disproven. High-performing AI product teams need classical ML rigor: accuracy metrics, ground-truth development, evaluation pipelines, and convergence thinking. The old model of a separate ML team working in notebooks does not work; the expertise must be embedded directly within the team building the product.

Challenges for Upcoming CTOs

In Eric’s view, the hardest challenges for upcoming CTOs are not strictly technical; they are operational and behavioral. The first is the vendor hype trap: business teams are always drawn to tools that seem magical in a demo, but the real test is whether they can integrate into the existing environment and be supported over time without becoming a dependency nobody owns. The second is accuracy under automation. As AI moves from assisting humans to driving repeatable workflows, tolerance for error collapses. Small inaccuracies do not stay small; they compound, and what looked like a minor edge case becomes an operational risk.

A third challenge is that enterprise AI exposes what companies have never had to articulate: their own tribal knowledge. If a customer cannot clearly explain how they label obligations, group commitments, or interpret policies, the AI cannot behave correctly. The product has to help them codify what has lived in habit and institutional memory. That is also why Eric is so opposed to “wait-and-see” strategies. His advice is blunt: you have to start building. Waiting to select the perfect agent platform, or hoping the models stabilize first, only guarantees you will fall behind and remain uninformed about what production-grade AI actually requires. All of that falls within an org design reality that is shifting underfoot. Planning horizons are shorter, traditional ratios are less reliable, and CTOs have to build teams that can adapt quickly rather than conforming to legacy templates.

Looking Ahead

Ontra’s product trajectory is a steady cadence of deep workflow expansion. In the last couple of years, the company has launched multiple new products. Most recently, Ontra introduced a solution that allows firms to upload complex credit agreements, extract key data elements, and enable downstream comparison and workflow execution across counterparties. The theme stays consistent: unstructured documents become structured understanding, which becomes action.

More from Uncovered Media

CTO Uncovered’s View

Eyal Bukchin is building for the moment software stops being theoretical. In a world where AI can generate code at an accelerating pace, the new bottleneck is not writing; it is validating. It is integration. It is the painful gap between “it works on my machine” and “it works in a living system with microservices, databases, mature state, and third-party dependencies.”

MetalBear exists inside that gap. Eyal and his co-founder did not start with a trendy AI thesis; they started with a developer reality: modern systems are too complex to faithfully replicate locally, and that long iteration cycle means you only discover glaring issues late. Their product, mirrord, pushes integration earlier by letting engineers work locally while wiring their changes into a real remote environment without leaving a disruptive footprint.

Eyal Bukchin's CTO lens is shaped by two forces colliding at once. First, developer tooling has become impossibly crowded; this makes clarity, trust, and brand as important as technical merit. Second, agentic development is changing the shape of the engineering job; the engineer becomes less of a code producer and more of an orchestrator who can think at multiple levels, communicate clearly, and verify what the machines produce. Eyal expects the teams who win will not be the ones who generate the most code; they will be the ones who can safely integrate change at scale.

About MetalBear

MetalBear was founded in April 2022 by two technical co-founders who previously worked together at BioCatch, a fraud detection company serving financial services. Eyal serves as CTO, while his co-founder, Aviram, is CEO and the primary outward-facing leader in the developer community. The company’s flagship product, mirrord, was born from a single recurring frustration: the widening gap between local development and how code behaves in production-like reality, where microservices, mature state, and external dependencies create surprises late in the cycle.

MetalBear’s long-term ambition is bigger than one tool. Eyal describes the original vision as building a “HashiCorp for cloud engineers,” with multiple products that solve day-to-day workflow problems. That is why the company and product brands both exist; “MetalBear” is a pun on “bare metal,” a name they kept because it was memorable, even as their focus narrowed.

Key Takeaways

• AI Creates More Code, Not More Certainty: Productivity goes up, but integration and end-to-end validation become the bottleneck.

• Sandboxes Have Limits: Personal environments are expensive for humans and even less scalable for agents; they also struggle to simulate real production behavior.

• Trust Is a Product Requirement: mirrord asks teams to change how they use staging; brand and credibility matter because the first reaction is fear of breaking shared environments.

• The New Engineer Profile: MetalBear is optimizing for adaptable, mature engineers who can operate at multiple levels and communicate clearly, especially in a remote and agent-assisted world.

  ---

Meet Eyal Bukchin

The Journey to the CTO Seat: Eyal co-founded MetalBear after years of building inside real systems where late-stage integration failures were routine. He and his co-founder did not begin with a single “burning” startup idea; they started by inventorying the recurring pain points they had lived through as developers, and testing in real-world context kept surfacing as the most stubborn one.

Co-Founder Role Design: Eyal is direct that titles matter. His co-founder is CEO largely because he is better positioned to be the face of the company: faster with customers, more active in the community, and more outward-facing by nature. Eyal describes himself as more critical. Even so, the boundaries are fluid; Eyal manages marketing, an unusual ownership area for a CTO, which reflects how intertwined product narrative and technical trust are for MetalBear.

Techno-Optimist, Cautious Team: Eyal believes a human-less world is not an unreasonable assumption given the speed of AI progress. His team has been more skeptical; they adopted AI tools more slowly than many peers, driven by early experiences that felt noisy and time-wasting. Eyal did not mandate adoption; he created conditions for learning, including an internal channel to share wins and patterns that were successful.

Deep Dive: Workflow & Adoption

mirrord exists because local development no longer resembles real systems. As architectures become more distributed and dependent on external services, the gap between a developer’s laptop and a production-like environment keeps widening. Eyal’s framing is simple: developers love the fast feedback loop of local development, but they need to test in real context earlier because the surprises that appear at the end of the cycle are the most costly.

The irony is that while everyone feels this pain, very few people know how to name the solution. Eyal says the market does not struggle to understand the problem; it struggles to categorize. Developers are not searching for “run my local code connected to my remote environment;” they search for broad buckets like productivity, cloud environments, or dev infrastructure. mirrord lives between those categories, which makes storytelling and live demonstration a requirement, not a nice-to-have.

That is why trust sits at the center of mirrord’s adoption curve. The product asks teams to relax one of their most hard-earned instincts: protect staging at all costs. If multiple developers can work against a shared environment concurrently, the default fear is predictable; someone will break it, contaminate results, or create chaos no one can untangle. mirrord is not just introducing a new tool; it is asking for a new operating model.

MetalBear earns that trust by reducing the perceived risk and increasing the felt reliability. They meet engineers where skepticism lives, walking through how concurrency is controlled, how changes avoid leaving a footprint, and what guardrails exist when things go wrong. Just as importantly, they prove they are real: a team that shows up, answers questions directly, and can point to customers using the workflow in practice. Over time, trust compounds through repeatable outcomes, clear explanations, and the confidence that the system will behave the same way tomorrow as it did today.

The Future Tech Stack & Workforce

Eyal does not believe MetalBear is building for a human-less world right now. They are building for a world where agents become prevalent and humans shift into the role of orchestrators, directing multiple loops of work at once while still owning the judgment calls that keep systems safe. In that future, mirrord does not need to be reinvented so much as fortified. Eyal sees the product as foundational and flexible enough to carry forward; however, the operating conditions around it will change fast.

As agents proliferate, the same workflow patterns that are manageable for teams of humans become intense at scale. Concurrency stops being an edge case and becomes the default; more work streams will run against shared environments, and the system has to support higher parallelism without turning staging into chaos or making results impossible to trust. At the same time, the risk profile changes. When execution is increasingly automated, the cost of unwanted behavior rises; “good enough” protections are no longer sufficient. Guardrails have to become stronger and more explicit to prevent accidental damage to shared clusters, not because developers are careless, but because the volume and velocity of changes make the blast radius bigger.

That shift in product reality also reshapes how Eyal thinks about building a team. He is clear about what he is optimizing for today: adaptability and independence. MetalBear is not hiring junior engineers right now, and he is not sure when they will. The reason is not a lack of belief in developing talent, but the demands of the moment. In a world where tooling, norms, and best practices are in constant motion, he wants engineers with the professional maturity to choose the right tools, learn quickly, and solve problems without relying on fixed playbooks.

Challenges for Upcoming CTOs

The speed of change makes it difficult to predict what remains relevant in a standard engineering curriculum. Eyal expects parts of today’s educational path to become less applicable, but he also believes the goal is clear even if the path is not: become the person who can leverage agentic tools better than everyone else, not by prompting, but by thinking clearly about problems and verifying outcomes.

He also calls out a subtle but crucial skill that is about to become a louder differentiator: communication. Engineering is collaborative; remote engineering is written; agentic engineering is instruction. If the primary interface becomes language, then the ability to express intent clearly and precisely becomes a core technical advantage, not a soft skill.

Looking Ahead

MetalBear’s bet is that the industry is about to feel the cost of “more code” more acutely than the benefit. Integration testing and end-to-end validation become the choke points, especially if the default solution is expensive sandboxes that still fail to behave like production.

Eyal’s posture is optimistic about where AI is headed, but disciplined about what has to be true for the future to work. The teams that win will be the ones who can operate at multiple altitudes: define the problem at the business level, instruct systems at a high level, and verify details at the implementation level. In that world, speed is not a function of generating code faster; it is a function of making real systems safe enough for machines and humans to build together.

More from Uncovered Media

CTO Uncovered’s View

Often described as a generational brand, Babylist is a leading commerce and media platform in the baby industry. For its CTO, TJ Moretto, the central challenge facing the enterprise today is clear: how do you drive billions in commerce and media while operating a 15-year-old codebase under the pressure of the AI revolution? The real battle for AI ROI is unfolding inside these scaled organizations; it is not just happening in seed-stage labs.

At Babylist, that battle is not happening on a clean slate. The company runs on a system that has evolved through multiple eras of product expansion, shifting teams, and changing technical standards. The codebase works and delivers real business value, but it was never designed for a world where machines are expected to reason, generate, and evaluate code alongside humans. Each attempt to introduce AI surfaces the same underlying question: is the system itself ready to support it?

TJ has spent nearly a decade navigating that tension. His role as CTO is not to chase the newest models; he must determine where acceleration is real, where it is illusory, and where architectural discipline matters more than tooling. In practice, integrating AI becomes less about the promise of the technology and more about the consistency, observability, and leadership required to make it effective at scale.

About Babylist

Babylist is the leading registry, e-commerce, and content platform for growing families. In 2021, they secured a $40 million Series C funding round led by Norwest Venture Partners. They are actively reshaping the $320 billion baby product industry, generating over $1 billion in annual GMV, with a mission to help parents feel confident, connected, and cared for at every step. What began as a universal registry 15 years ago has grown into a full ecosystem, including the Babylist Shop and Babylist Health.

TJ has been with the organization for nearly a decade, giving him deep institutional knowledge of this evolution as the technology organization scaled to approximately 120 people. Despite this massive scale, the core tech stack, largely a backend Rails monolith with various frontend frameworks, is a powerful but complex machine. This conversation defines the difference between merely integrating AI into that established system and being an “AI-first” organization; it examines what that difference means for engineering efficiency and for the millions of families who shop with Babylist every year.

Key Takeaways

The 80% Rule: “If you’re writing 80% of the code, you’re doing it wrong. The tool should be writing 80% of the code.”

The Backend Preference: AI is “exceptional” for backend development (building logic, algorithms) due to fast feedback loops, but struggles significantly with frontend UI.

Observability: Regaining Control of the AI-Augmented Process: Vendor AI solutions can be “magical” at first, but their performance requires dedicated investment in evals, error analysis, and observability to ensure continued accuracy.

The New Engineering Role: An engineer’s primary value shifts to being the planner, architect, and orchestrator of agents, not the primary code producer.

Meet TJ Moretto

The Journey to the CTO Seat: TJ progressed from an individual contributor to leading the entire engineering team throughout his tenure with Babylist. He does not describe his effectiveness in terms of technical brilliance; instead, he points to his ability to organize work, communicate clearly with business stakeholders at every level, and rally teams around solving real problems. That instinct for coordination over individual output has shaped his leadership style and has become increasingly essential in an era where engineering is less about writing code and more about directing systems of people and machines.

The Engineering Ethos: The culture is built to hire engineers who care most about the business and users, who want to “deliver value” and “win,” focusing on solving problems rather than “toy technical problems.” Babylist is structured in two areas: a Consumer Tech Org (apps and websites) and a Fulfillment or Supply Chain Org (backend technology for e-commerce). Within the consumer group, the team maintains traditional “product building pods.”

Leadership Philosophy in an AI Era: TJ maintains a strong, hands-on approach, stating, “being in the weeds does matter,” and that this makes for a good leader. He does a ton of skip-levels, reviews almost every document that comes his way quickly, and looks at data models and schemas.

The AI Goal Shift: Structured Adoption (OKRs): Following the initial phase of “messy experimentation” where all employees were given access to tools, Babylist recognized the need for a structured process to govern how AI would be implemented across the organization. They moved to a formal goal-setting process, implementing OKRs around AI adoption. These goals were applied to every aspect of the engineering product development process, including: shaping work or scoping it, building and testing, and code review. The aim was to systematically play with AI in each area to understand the results that could be achieved.

Deep Dive into AI Integration

AI as a Backend Accelerator: AI is found to be “exceptional” in the backend, specifically for building logic and algorithms. This works well because the code is easily testable, allowing for “fast feedback loops.” This is also effective for managing the existing 15-year-old code base, which has “lots of different patterns, lots of different corners and spooky things.” The organization employs a two-tool strategy: a synchronous, local agent (like Claude) for complex tasks requiring immediate feedback, and an asynchronous, remote agent (like Devin) for more discrete pieces of work that can run in the background.

The Consistency Debt: AI has demonstrated more limited utility for building in the frontend. The issue is inconsistency: Babylist has “lots of frameworks, lots of different styles,” and the AI struggles because the organization aims for a design system but does not yet have it at a level where AI can just take Figma and turn it into a perfect UI. TJ believes the mindset must shift; the initial impulse should not be to “fix the bad code” that the AI generates. Instead, engineers must figure out and fix the context that generated the bad result; this might be a realization that the architecture is too inconsistent and needs to be addressed.

The Observability Crisis: In the earliest AI adoption area (Customer Service), the solution initially felt “magical.” This rapid early success, however, led to the critical lesson that deep observability is paramount for long-term AI reliance. When the system grew in complexity, the engineering team realized they had inadvertently provided the business team with insufficient visibility, as the high-level metrics failed to capture that performance was degrading. This gap in monitoring prompted the organization to make a strategic decision to invest heavily in dedicated evals, eval platforms, and error analysis. This shift established robust technical ownership over AI performance, proactively countering the need to rely on intuition alone.

The Future Tech Stack & Workforce

The expectation has changed: “If you’re writing 80% of the code, you’re doing it wrong.” The role of the human has shifted to being more of the planner and the architect, thinking about how to break down work into different synchronous and asynchronous pieces for the agents. The essential skills are now about planning, orchestration, and judgment. TJ notes that while senior engineers who already excel with tooling are leveraging AI the best, there is a significant opportunity for junior engineers to really accelerate their careers. They can leapfrog multiple levels by coming in and being the native AI builder.

TJ views the advent of agentic commerce through the company’s unique product lens: the consumer behavior is driven by the need for credible, authoritative research during a low-knowledge, high-importance life phase. While AI is helpful for that research, the actual commerce happens through gifting from friends and family. Because gifting relies on human sentiment and social connection, TJ believes this experience requires a level of control that generic AI agents cannot yet replicate.

Challenges for Upcoming CTOs

Babylist faces a challenge when business users are tempted by AI vendor tools that appear “magical” but quickly get “blocked” and require a technical resource. This demands a sharp focus on ensuring that vendor solutions can integrate and be supported long-term, moving beyond the initial hype cycle. Despite using agents like Devin, the team ensures its most important technology still goes through its full software development loop. The human engineer still owns that code, even if it was mostly written by an agent.

The advice to an aspiring engineer is clear: a Computer Science degree is still incredibly valuable for the problem-solving skills it teaches. However, the application has changed; future engineers will write way less code, but their problem-solving and orchestration skills will be more important than ever.

Looking Ahead

The overarching question driving future architectural decisions is simple: “Is the gap between ‘integrating AI’ and being ‘AI-first’ closing, or are they becoming two completely different kinds of organizations?” TJ views the ongoing investment in fixing architectural inconsistency as the key to closing that gap. The strategic debate centers on the structural cost of maintaining and modernizing an existing system versus building a new one from the ground up. The outlook inside Babylist is defined by aggressive curiosity and velocity, but also restraint. The goal is not to chase every new model, but to learn precisely where AI compounds value and where it amplifies fragility.

More from Uncovered Media