Inside the CTO Roundtable: Engineering Leaders on Building the AI-Native Organization | Technology Trends

Frontiers Aug 15, 2026

Snowflake has introduced the CTO Circle, a trusted cross-industry forum for engineering leaders engaged in AI-native organizational design. The inaugural summit assembled more than 350 CTOs to exchange first-hand transformation experience.

The CTO Circle addresses a problem for which no mature playbook exists: the construction of the AI-native organization. Verified peer practice, not theoretical extrapolation, is emphasized; Snowflake's platform provides a natural bridge between cross-industry data and applied AI scenarios.

Intended for enterprise CTOs, heads of AI engineering, and technology strategy leadership.

*Which substantive advances will agents deliver in enterprise applications in 2026?* [Download](https://www.infoq.cn/minibook/keTZm4fpOmFEzmx77Zpq) the *2026 AI and Data Predictions* whitepaper to obtain expert forecasts and adopt new working practices ahead of the curve.

As AI rewrites the rules of software, nearly every engineering leader confronts the same questions. How should engineering teams be structured? Where should capital be deployed as foundation models advance? How can engineering efficiency be improved without incurring unacceptable operational risk? And wherein lies the essential difference between an AI-augmented and an AI-native organization?

No mature playbook exists for the AI-native engineering organization, and engineering leaders seldom have occasion to compare lessons learned in public. Such conversations typically remain confined within individual companies, constrained by competitive pressure and the pace of technological change.

As the platform on which thousands of organizations construct their data and AI strategies, Snowflake is a natural convener of this dialogue. The CTO Circle was established to afford engineering leaders a trusted peer forum—a venue for drawing on the lived experience of peers undergoing the same transformation and for challenging entrenched assumptions. Held during the 2026 Snowflake Summit in San Francisco, the inaugural event assembled more than 350 CTOs across financial services, telecommunications, retail, and technology to exchange field-tested practice.

Discussion soon outgrew coding assistants and model selection, pivoting to the restructuring of engineering organizations, the production-proven practices that endure, and the allocation of investment for durable competitive advantage. In time, the conversation converged on three themes that define the AI-native engineering organization: AI in production, equilibrium between speed and risk, and the redesign of engineering teams for AI.

AI in Production: What Fails, What Scales

For many organizations, the AI journey begins with the introduction of coding assistants into existing engineering workflows. Developers write somewhat faster; documentation is produced with greater ease. Such gains are genuine, yet the underlying engineering system remains essentially unchanged.

Vivek Raghunathan, Senior Vice President of Engineering at Snowflake, urged a broader conception of AI adoption. The foundation of the AI-native engineering organization, he argued, is a change in management philosophy. Developer productivity, in Snowflake's view, was neither an engineering problem nor a cultural one, but a product to be managed as such.

"What if developers were treated as customers?" This question anchored Snowflake's internal engineering transformation. Abandoning the assumption that leadership knows what engineers require, teams applied product management principles—the same applied to external customers—to the design of the internal developer experience.

Interviews with developers were conducted first to locate bottlenecks, after which friction points across the software development lifecycle were mapped. Baseline metrics were established, and every change was measured through experimentation. The method joined explicit executive sponsorship with bottom-up adoption, ensuring that improvements mirror real engineering practice rather than leadership's assumptions about it. [IMAGE:0]

Figure 1: The AI-native approach

The outcomes were quantifiable. Within 18 months, Snowflake's internal developer Net Promoter Score advanced by more than 30 points, yielding a 4:1 ratio of satisfied to dissatisfied developers. Critically, the gain transcended experience alone: it produced an engineering organization capable of more efficient software delivery and swifter adaptation as AI capabilities evolve. [IMAGE:1]

Figure 2: Overall developer satisfaction at Snowflake

Vivek further observed that adoption alone—the mere adoption of tools—does not yield materially significant productivity gains. Leverage derives from depth of use and genuine mastery at scale. At Snowflake, the progression proceeds through three stages:

Adoption: Developers acquire facility with AI tools in daily work.

Mastery: Engineers progressively refine repeatable workflows that consistently yield superior outcomes.

Optimization: Such workflows are codified as organizational knowledge, shared and reused across the engineering body. [IMAGE:2]

Figure 3: Distinctions between the AI-augmented and AI-native organization

A representative example is found in the engineering design patterns accumulated within Snowflake. Early adopters of AI experimented continuously with prompting techniques, planning methodologies, and debugging approaches. Over time, patterns that consistently yielded superior results were documented and disseminated across the engineering organization.

Thus, although every developer is equipped with identical AI tooling, engineers operating at mature workflow levels consistently outperform those at earlier stages of use. The durable advantage lies not in the mere deployment of another AI assistant, but in the institutionalization of proven ways of working.

This focus on workflows is likewise reshaping the organization's conception of software development. As AI substantially reduces the cost of converting ideas into working software, everyone becomes a builder. Product managers prototype rapidly; designers validate concepts directly in code; domain experts supply guardrails for adjacent roles. Teams are no longer confined to debating ideas through decks and documents; hypotheses are tested by building working software. Code is fast becoming the most expedient test of an idea.

Jon McNeill, author of The Algorithm, carried the point further, urging leaders to re-examine the foundational assumptions that have governed engineering organizations for decades. Many firms proceed from technology outward, seeking applications after the fact; the successful organization, McNeill contends, inverts the sequence—business constraints of first-order importance are identified, and the engineering system is rebuilt around them. As AI moves into production, the measure of success is no longer the volume of code generated or tokens consumed, but the construction of the simplest, fastest, most effective engineering system. The ranking that merits attention, perhaps, is not of the most AI-generated code, but of the greatest number of unnecessary steps eliminated between idea and production.

Maximizing speed while containing risk

As AI becomes embedded across the software development lifecycle, a second challenge confronts engineering leaders: each increment in development velocity elevates the importance of system reliability and operational discipline. The organizations moving fastest are those investing in architectures engineered for both speed and dependability.

Jeremy Burton, General Manager of Snowflake's Observability Business Unit, observed that AI has entered a new phase: early experimentation is yielding to production deployment, and organizations are increasingly called upon to prove measurable business value rather than showcase isolated technical achievements. Concurrently, AI introduces novel operational difficulties. Agents generate more telemetry, interact with a wider set of systems, and decide on the basis of information dispersed across increasingly complex environments. Observability's mandate has thus shifted—from the monitoring of infrastructure to the provision of context required for reliable AI operations. [IMAGE:3]

Figure 4: New AI workloads generate more telemetry and greater complexity

Jeremy likewise contested a prevalent assumption in enterprise AI: that superior models require only superior data. In practice, AI's efficacy is a function of accessible context—context extending well beyond raw telemetry. It comprises the semantic layer that confers meaning upon data, relationships established via ontologies and knowledge graphs, and the business context that binds systems together. Of equal consequence is the manner of access. Reliable retrieval and manipulation of information demand standardized interfaces—APIs, CLIs, the Model Context Protocol (MCP)—while engineers require intuitive means of probing data and validating AI-generated insight.

Where rich context meets open access, fragmented telemetry is transformed into an environment in which humans and AI alike can reason, troubleshoot expeditiously, and reach superior decisions. Organizations that continue to store logs, metrics, traces, operational data, and business context in mutually isolated systems impede AI's accurate comprehension of the production environment. Engineering telemetry, by contrast, should be regarded as data resting upon a unified foundation—one in which inter-system relationships can be understood and queried.

Aditya Gaur, an engineering manager at Netflix, demonstrated the approach in practice through his team's work on automated root cause analysis. Though frequently characterized as an AI initiative, the project, Aditya explained, owed its success more to data architecture than to AI per se.

Years before the introduction of AI agents, Netflix had invested in linking dispersed telemetry, modeling system relationships through ontologies and knowledge graphs, and constructing a shared context layer. When AI arrived on the scene, the infrastructure had, in effect, long been prepared. AI agents, consequently, need not scour fragmented logs and dashboards; reasoning from structured operational knowledge, they can advance more valuable hypotheses in incident investigation.

Caitlin Colgrove, CTO of Hex, addressed "speed" from a different vantage. "Moving fast" in the AI era, she argued, demands redefinition. Partial AI nativity is ultimately unsustainable: a point is reached at which full commitment is required—teams must be restructured in how they build products, make decisions, and embed AI in daily work. The process she termed "burning the boats." AI must become a foundational capability of business operations.

Hex's initial response to generative AI was the creation of a dedicated AI product team. Useful features did result, yet so did organizational bottlenecks. In time, the centralized team was dissolved, and responsibility was dispersed across every product team. Hex's current capacity for rapid delivery and deep AI integration derives from a single source: ownership vested in the engineers nearest the customer problem.

From the large-enterprise vantage, Chris Kozlowski, Managing Director at Barclays, added a further point: speed delivers value only in conjunction with governance and trust. In heavily regulated environments, engineering teams should not be compelled to choose between innovation and control.

Corey Burke, Senior Vice President of Engineering at Dialpad, joined by Arun Rajamanickam, Vice President of Engineering at project44, described AI's effect on the rhythm of software development. Where agents can independently perform a substantial share of feature implementation, engineers devote less time to "writing code" and correspondingly more to defining intent, orchestrating multiple agents, and validating outcomes.

Maximum speed, they emphasized, presupposes engineering platforms that permit rapid experimentation without sacrificing reliability. AI shortens the distance between problem identification and solution validation—provided the requisite infrastructure, shared context, and operational discipline are in place for confident, rapid iteration.

Redesigning the engineering team for AI

If AI alters the construction of software, it must equally alter the design of engineering organizations. New team structures, new leadership models, and a reconceived understanding of where engineers create greatest value all follow.

Qi Jin, EVP of Cerebras Systems, contended that organizations optimized for the prior generation of software development frequently constitute the principal obstacle to AI adoption. Existing processes and organizational boundaries were designed to scale proven practice, not to absorb disruptive technology on a continuing basis. Successful embrace of AI, accordingly, demands more than the introduction of new tools; operating models must be reconsidered so that teams can rapidly internalize new capabilities as technology advances.

Qi framed the transformation as "Code Yellow"—a framework for organizational change organized around urgency and the customer problem. The perspective aligns with the broader leadership doctrine advanced in his essay on the "wartime manager": where external change accelerates sharply, leaders must simplify decision-making, act with resolve, and challenge entrenched norms rather than pursue incremental optimization of legacy processes.

Parvez Naqvi, Senior Vice President of Cloud Platform, Resiliency Engineering, and Enterprise Architecture at Capital One, elaborated on how these organizational shifts remake the engineer's role itself. With implementation accelerated markedly by AI, engineering value converges upon the judgments AI cannot yet render independently. The binding constraint on software delivery migrates from coding per se toward planning, architecture design, and engineering judgment.

Conventional review processes organized around manually written code erode as AI accelerates development markedly. The leverage of senior engineers derives increasingly from the definition of technical direction and the establishment of architectural patterns. Deeper engagement in system design follows, supplying the context on which engineers and AI agents depend for superior decisions. [IMAGE:4]

Figure 5: CTO Circle roundtable on the evolving role of the data engineer

This evolution likewise elevates the standing of developer platforms and engineering infrastructure. Internal tooling and deployment systems attain strategic value by reducing operational burden—freeing teams to concentrate on the design of resilient systems rather than the repeated absorption of routine labor. As product managers, designers, and domain experts join directly in software creation, the engineering organization assumes the character of a gatekeeper of quality, architecture, and operational excellence, rather than the exclusive producer of code.

Harjot Gill, CEO of CodeRabbit, described AI's fundamental transformation of the developer experience. As AI assumes a larger share of implementation, the engineer's time spent translating ideas into code diminishes; attention shifts to the definition of intent, the evaluation of trade-offs, and the shaping of system design. AI-assisted reviews enable engineering teams to maintain pace without compromising correctness, security, or maintainability.

Jordan Topoleski, COO of Cursor, turned attention to the stage after code generation. With development velocity sharply elevated by AI, code review, validation, and engineering-quality assurance emerge as the new constraint. His remarks reinforced a convergent conclusion: organizations that scale successfully construct stronger feedback loops and engineering systems to ensure AI-generated software is genuinely prepared for production. [IMAGE:5]

Figure 6: The CTO Circle roundtable in session

Viewed collectively, these discussions disclose a broader arc of transformation. AI-native engineering is defined less by the speed of tool adoption than by an organization's capacity to learn, distill, and institutionalize superior software-building practice. The swiftest firms will be those that continuously reconfigure their engineering organizations to absorb each successive advance in AI.

Looking Ahead: The Conversations Defining the Next Phase

Discussion across the event reflected an industry far beyond the experimental "trial and error" phase. Though each organization occupies a distinct stage of transformation, the challenges confronted are strikingly convergent. Attendee feedback reinforced our assessment of the CTO Circle: engineering leaders prize the opportunity for candid exchange with peers confronting comparable decisions. The event's distinctive value lies in a space for candid conversation scarcely available elsewhere.

Snowflake's distinctive cross-industry vantage enables the assembly of organizations confronting comparable challenges, yielding a trusted forum for the exchange of experience rather than the presentation of curated success stories.

The playbook for AI-native engineering remains under construction. As models advance and engineering practice evolves, these lessons assume mounting significance. Further practitioner accounts from leaders building AI-native organizations will follow, including a more granular examination of Snowflake's own transformation. Where these discussions align with the challenges confronting your organization, we invite continued engagement with our forthcoming content in examining how the next generation of engineering organizations should be built.