“Context is the New Code Review”, Optimizely CTO Aniel Sud on What Actually Slows AI-Accelerated Teams Down

Aniel Sud has held nearly every job at Optimizely except the one he doesn't call himself: a CTO who sits behind the org chart.

Since joining in 2006, he's worked field marketing, run expert services, and spent the last five years leading engineering, and he says that path is exactly why he now spends more time in pricing conversations and board reviews than in pure technical work. “I think about my job as GM first, CTO second,” he says.

That instinct shapes how he thinks about AI's real bottleneck. As code generation accelerates, Sud argues the constraint isn't writing speed, it's whether a team can articulate intent clearly enough for AI to execute against it well. In this conversation, he explains why he believes integration, not just individual product strength, is what makes AI agents meaningfully more capable, how he decides where to move fast versus where a mistake becomes unrecoverable, and why he thinks most enterprise websites quietly reveal that they were designed for the org chart instead of the customer.

You've worn multiple hats at Optimizely, from field marketing and expert services to leading engineering. How have those two decades shaped the way you approach your role today?

The through-line is that I've always been closest to the customer problem. Field marketing taught me that positioning only sticks if the product actually delivers. Expert services taught me that what customers say they want and what they need are rarely the same, you only learn the gap when you're doing the implementation. Engineering is where you reconcile both.

What that shaped in how I run things today: I'm not a CTO who sits behind the org chart. I stay personally engaged with customers at the escalation level. That's not a failure of delegation, it's how I maintain signal on where the product is actually breaking in the real world. When you've done the field work, you know what "good" looks like from the customer's seat, and you can tell immediately when engineering is building something that'll create downstream pain.

The other thing those years gave me is commercial instinct. My role today is as much GM as CTO, I'm in pricing conversations, partner strategy, board reviews. That breadth is what makes the engineering decisions meaningful. You can't make good technology choices without understanding the commercial context they have to succeed in, and you can't make good commercial choices without understanding what's actually possible to build.

Why was it important for Optimizely to bring content, experimentation, commerce, personalization, analytics, and AI onto an integrated platform? What customer pain points does that solve better than a fragmented stack?

The honest answer is that integration isn't primarily an architectural convenience, it's what makes the AI meaningfully more capable. An agent that only has access to one discipline can only act within that discipline. A content agent can write. An experimentation agent can test. But neither one can reason about why an experiment won, what content change to make in response, and how that change will affect personalization downstream. That kind of reasoning requires the full picture.

When you build agents on top of a platform that spans content, experimentation, personalization, commerce, and analytics, those agents can actually close the loop and not just surface an insight, but take the next action, and the action after that. The scope of what they can do is directly proportional to the scope of what they can see and touch. That's a fundamentally different class of capability than you get from agents built on top of point solutions, no matter how good those point solutions are individually.

The other dimension is expertise diversity. Optimizely has deep capability in disciplines that most vendors treat as separate categories which includes rigorous statistical experimentation, high-volume content management, real-time personalization, commerce decision logic. When those disciplines are unified in a single platform, they sharpen each other. Experimentation rigor makes personalization more defensible. Content expertise makes AI-generated variants better. The integration multiplies the value of each discipline in a way that's very hard to replicate by stitching tools together after the fact.

Innovation is exciting, but enterprise customers also demand stability, security, and reliability. How do you decide where to move fast, where to slow down, and where not to compromise at all?

My mental model has three layers. The infrastructure layer which includes data integrity, security, reliability, the things enterprise customers built their businesses on, which is a "non-negotiable", never compromise there. The feature layer like new capabilities, UI, content workflows  move fast, experiment, ship and iterate. The connective tissue between systems, the APIs and integration points is where you have to be most deliberate, because mistakes there propagate in both directions.

The practical test I apply: who bears the cost of a mistake here, and can they recover? If a new feature ships with a rough edge, the customer notices and we fix it, that's recoverable. If an API contract changes in a way that breaks integrations, or a data pipeline produces incorrect results quietly for two weeks, the cost is much higher and the trust repair takes much longer. The severity asymmetry tells you where to slow down.

I think about this through the lens of two-way versus one-way doors. A two-way door is a decision you can walk back, which is a UI change, an internal API or a content workflow. Ship it, learn from it, iterate. A one-way door is a decision where walking back is expensive or impossible like a public API contract, a data schema change, a security boundary. Those get a different level of process and scrutiny, not because we're being conservative for its own sake, but because the cost of getting it wrong is asymmetric. The goal is to apply overhead only where it genuinely matters, so we're not slowing everything down to protect the things that don't need protecting.

What AI changes is the calculus on the feature layer; you can move significantly faster without sacrificing quality if the tooling is right. But it doesn't change the calculus on the foundation. If anything it raises the bar, because customers are now trusting AI-driven decisions that are only as good as the data underneath them. The infrastructure has to be more reliable when AI is acting on top of it.

You've often spoken about building resilient systems and teams. What's one engineering principle that's become even more important as AI accelerates product development and customer expectations?

Context is the new code review.

When AI accelerates code generation, the bottleneck shifts. It's no longer "how fast can we write code?",  it's "do we understand what we're building and why?". The teams I've seen struggle with AI adoption are the ones where engineers can describe the implementation but not the intent. AI is a brilliant executor of poorly-specified requirements, which means it amplifies unclear thinking, not just clear thinking.

The direction we're investing in is codifying intent in machine-readable formats like knowledge structures mapped to code that maintain decision context across the codebase. So when AI or a new engineer picks up a piece of work, they're not starting from scratch on the "why." That shifts your competitive advantage from who can generate code fastest to who has the best-structured institutional memory.

The CTO's job today reaches well beyond engineering. Which part of the role consumes more of your time than people probably expect, and why has that become so critical?

The honest answer is that the role is much closer to a general manager than most people expect. I think about my job as GM first, CTO second. This means I'm as accountable to revenue, customer trust, and commercial outcomes as I am to the engineering org. The customer conversations, the partner relationships, the commercial decisions, the board communication — those aren't things I do in addition to the CTO job. They are the job, and they consume more time than any purely technical work does.

Most engineers who move into the CTO seat are surprised by this. The title sounds like it's about technology, and it is, but the leverage isn't in the technology decisions themselves. It's in connecting engineering output to business outcomes, and making sure those two things are actually pointed at the same thing. When they're not, you feel it in retention, in partner trust, in sales cycles. Staying close to all of that isn't a distraction from engineering leadership; it's what makes engineering leadership meaningful.

If you looked at the average enterprise website today, what's the first thing that tells you it's designed around internal processes instead of customer needs?

The navigation reflects the org chart. When a company's website organizes itself by department like Products, Services, Solutions, Company, in that familiar left-to-right hierarchy, that's the org chart rendered as a sitemap. No customer arrives at your website thinking "I need to find the Solutions section." They arrive with a problem. If your navigation doesn't map to problems, it maps to you.

The second tell: content is structured around how it's produced, not how it's consumed. Landing pages that lead with awards and analyst recognition before they explain what you actually do. Product pages organized by feature list instead of by what a customer is trying to accomplish. Blog content timed to internal editorial calendars rather than to moments when customer questions are actually live.

The third: no visible experimentation. A homepage that hasn't meaningfully changed in a year is telling you the company has no feedback loop between what they publish and what works. Enterprise customers deserve digital experiences that get smarter over time. If you're not running experiments, you're just decorating it and you're making it impossible to know if the decoration is helping.

The through-line is a room full of people making decisions for the organization, not for the visitor. Someone approved that navigation because they wanted their product line represented. Someone set the content calendar around quarterly targets. Someone never ran an experiment because being publicly wrong felt risky. None of it was malicious, it was just optimized for the wrong audience.

Finally, if every CEO, CMO, and CTO could leave this conversation remembering just one idea about building AI-powered digital experiences, what would you want it to be?

 The thing AI has genuinely changed in digital experiences isn't how much content you can produce, it's how fast you can learn what's actually working. That's the shift I think gets underappreciated.

The best companies have always invested in understanding their customers deeply. What's different now is the speed of that feedback loop. Tests that used to take weeks to design and run now happen in hours. Personalization that required a data science team now happens directly in the workflow. The gap between publishing something and knowing whether it worked has compressed to the point where it changes how you operate, not just how fast you operate.

The framing I'd leave every leader is with "how do we use AI to produce more" rather "how do we use AI to learn faster." That's where the compounding happens: a continuously updated understanding of your customer that improves every decision downstream. The companies getting this right start with what their customer needs to hear, not with what they want to say.