Last week I watched an AI agent debug a production issue, write the fix, generate tests, and deploy. Twelve minutes. The product and tech lead was in another room with the team, working on roadmap. Two years ago this would have taken days of engineering effort.
Nearly a decade ago I wrote a 90-day plan for CTOs starting new roles. That framework focused on understanding the organization, building the team, and putting processes in place. Those activities still matter. But generative AI is changing what the CTO and CPO actually do day to day, and the old playbook doesn’t cover the new work.
The work I’m doing with Kirim and Sezer at Flatiron Software and Snapshot AI is teaching me how different this shift is from mobile, cloud, or any of the platform shifts I’ve worked through over the past two decades. The roles change, not just the tools.
The shift behind everything else
The traditional CTO job started with translating business needs into technical architecture: hire engineers, organize teams, pick technologies, manage delivery. The CPO job started with users: understand them, define features, prioritize the backlog. Both assumed the same underlying constraint: human coding capacity. That constraint is going away.
What’s replacing it is the ability for AI agents to own work that previously belonged to engineers. Not the autocomplete-and-snippet level we had two years ago, but full subsystems: agents that can read existing code, decide on a fix, write the change, ship the tests, operate the deployment. The CTO question is no longer mostly about how to staff for that capacity. It’s about how to organize a team where the production of code is no longer the limiting factor.
“Every architecture review will soon start with a new question,” Kirim says. “Which parts were written by people, which by AI, and do we trust both?”
What changes for the CTO
The traditional CTO job centered on choices about people and platforms: who to hire, how to organize them, which stack to standardize on. AWS or Azure. React or Vue. Microservices or monolith. Those questions still come up, but they aren’t where the hard questions are anymore.
The harder question is which AI capabilities to compose, and how. Claude is strong at certain code-generation tasks; GPT models excel at different ones; Gemini and specialized models cover other ground; agent frameworks change how all of these connect to your codebase and tools. The CTO job is becoming the design of that capability mix the way an architect once designed the technology stack. Not just one model. Not just one provider. A working composition that fits the product.
Technical debt has a new shape too. Traditional debt was code you couldn’t safely change. The new debt is AI-generated code that no person on the team fully understands, model behavior that drifts as the underlying model updates, capability degradation when a provider changes pricing or rate limits or training. Managing this needs different instrumentation than what most engineering organizations have today.
What doesn’t change: judgment that depends on context the AI doesn’t have. At a media company, an AI can optimize a recommendation engine; a person has to decide whether that personalization conflicts with editorial values. At a startup, an AI can scaffold a service in a weekend; a person has to decide whether building that service is the right move at this stage of the company. Connecting technical possibilities to a specific business and the people inside it is still the CTO’s work, and AI doesn’t replace it.
Building trust with the board. Partnering with peer executives. Reading the room when the CEO’s actual concern isn’t what they said out loud. These are unchanged. They are not technical problems.
The ethics question is heavier than it used to be. As AI capability expands, deciding what to build, not just what’s possible to build, is more often the CTO’s call. That requires values, cultural understanding, and the willingness to be the person who says no.
The CTO job is becoming the design of that capability mix the way an architect once designed the technology stack.
What changes for the CPO
The CPO role is changing more, not less. When AI can build features faster than users can adopt them, the discipline of product management has to reinvent itself around different questions.
Durable differentiation no longer comes from being first to ship a feature. Any feature can be cloned by a competitor with the same AI tooling, often within weeks. What lasts is the holistic experience: how the pieces fit, how the product feels, what kind of community grows around it, what it stands for. The CPO’s work shifts from prioritizing what to build next to deciding what should exist at all.
Conceptual integrity matters more in this world, not less. When the cost of building drops, the cost of saying yes drops with it, and the discipline of saying no has to scale up to match. The product the CPO ends up with depends on what they refuse, not just what they ship.
This raises a harder question than the traditional roadmap process did. Large language models trained on user behavior can predict needs with uncomfortable accuracy. But predictions of what users will engage with aren’t the same as decisions about what’s actually good for them. A short-term engagement signal can pull a product toward outcomes the team didn’t intend. The CPO has to hold the line on what the product is for.
The other change: roadmaps stop being a serialization problem. Traditional roadmaps assumed scarce engineering capacity and a queue of bets. When AI removes much of the scarcity, the constraint moves from “what can we afford to build” to “what deserves to exist.” That’s a curation problem, not a prioritization one. The skill becomes taste, not throughput.
The product the CPO ends up with depends on what they refuse, not just what they ship.
The human edge
As AI handles more of the technical work, distinctly human capabilities become paradoxically more valuable. The three areas that matter most:
Critical evaluation of AI output is now a daily executive skill, not a sideline. LLMs produce plausible-sounding text and code regardless of whether they’re correct. Knowing when to trust an AI answer, recognizing the failure modes of different models, building review processes that catch hallucinated function signatures or invented APIs before they ship: this is the new baseline. I wrote about this from the engineering side in Why Prompt Engineering Is Legitimate Engineering: A Case for the Skeptics, which generated a fair amount of debate on Reddit and elsewhere. The short version: this is a real discipline, and underinvesting in it costs you.
Synthesis across domains is the second one. AI is strong at pattern recognition within a domain, weaker at carrying patterns from one domain to another. A leader who has watched several industries adopt a new technology, or who can see the same shape in a regulatory question and an organizational one, is doing work the model can’t substitute for. The cross-context judgment I built up running technology at The New York Times, The Wall Street Journal, Hearst, Condé Nast, and Reddit is more useful now than it was five years ago, not less, because more of the in-domain work is automatable. The same is true of advisory work: I’ve watched companies like You.com and ScalePost AI work through the AI shift since their founding, and that vantage point is hard to get from any single operating role.
Emotional intelligence is the third. As teams become hybrid human-AI entities, leaders have to manage the part of the team that has feelings. Engineers feel threatened by AI capability. Boards worry about liability. Customers can tell when an experience was generated rather than thought through. None of this is solved by better tools. It’s solved by the leader spending time with the people involved.
How teams will reorganize
The boundary between product and engineering is going to thin out. Not disappear: someone still has to decide what to build, and someone still has to build it. But the functional separation that made sense when building was the bottleneck is overbuilt for the new conditions.
The engineers most exposed inside that change are the ones whose job is to translate detailed specifications into code. AI handles that translation now, often better than a tired engineer at 4 pm. The engineers least exposed are the ones whose job is to figure out what the actual problem is: to talk to a non-technical stakeholder, build a mental model of what they want versus what they need, and decide what to build before any code gets written. The “code monkey” stereotype was always unfair to the people it was applied to. It is also becoming literally obsolete.
What I expect to see more of: small interdisciplinary teams organized around an outcome rather than a function. Each team has a few people who do the human-judgment work (defining the outcome, evaluating AI output, dealing with stakeholders) and the AI tooling to handle most of the implementation. The right comparison is to a Hollywood production: a team assembled for a specific project, dissolved when it’s done. Headcount stops being a useful metric when one person with the right AI tools can do what used to take ten.
One specific practice I’ve watched work at Flatiron with Kirim and Sezer: founder-level goal reviews on every engagement, where the founders re-grade the goal against where the work has actually gotten to. Without that loop, AI-accelerated teams ship faster in the wrong direction.
There are two companion pieces I published the same day as this one: the media industry’s AI transformation, which traces what the shift looks like in news and content businesses, and the future of engineering services, which gets into how Flatiron and Snapshot are measuring productivity in human-AI teams when lines of code or story points no longer mean anything.
Headcount stops being a useful metric when one person with the right AI tools can do what used to take ten.
What to do this quarter
A few moves I would give a CTO or CPO who has read this far and wants to know where to start:
Pick one production system you ship into, and ship the next non-trivial change with AI in the loop end to end. Not a side project, not a hackathon. A real change in a real system. You will learn more from one real run than from any framework.
Look at how AI knowledge is distributed in your org. If it is concentrated in two or three people, that is a risk. Run a workshop where everyone on the team uses the tools on real work. Share what worked and what didn’t.
Rewrite at least one job description for an open role around adaptability and judgment rather than current technical skills. Hire from it. See what happens.
Write down what your organization will and won’t do with AI. Not a policy document. Three to five clear commitments your people can repeat to a customer or a board member. If you don’t write them down, someone will make them up under pressure.
What I keep coming back to: the AI shift isn’t a faster way to do the work we were already doing. It’s a change in what the work is. The CTO and CPO who do well over the next few years will be the ones who took that seriously early, and who reorganized themselves and their teams around the new shape of the job. The ones who treated this as another tooling upgrade will be doing the wrong work very efficiently.
Flatiron × Snapshot Executive Summit | Punta Cana · May 2025 Strategy took center stage thanks to Kirim and Sezer, who framed the vision, and to Hanike, Ana Clara, and Ana Laura, who turned that vision into a seamless three-day agenda. Their work shaped the leadership playbook above.