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