# CTO in the AI Era — Challenges and Approaches The CTO role is being fundamentally redefined. This file covers what's different now and how to navigate it. **Last updated:** 2026-03-15. This file has the shortest shelf life in the knowledge base — review quarterly. --- ## The 5 Key Shifts ### Shift 1: AI Coding Assistants Change What Engineers Do **What's changing:** Engineers spend less time writing code from scratch and more time reviewing, validating, and directing AI output. Claude Code dominates among early adopters. Staff+ engineers are the biggest users — they have the judgment to guide agents effectively. `[practitioner: Orosz]` **What the CTO should do:** - Invest in test infrastructure BEFORE investing in AI tooling. AI-generated code that looks right but has subtle bugs needs robust automated validation `[practitioner: Willison]` - Invest in observability. AI-generated code hitting production without observability is reliability debt `[practitioner: Majors]` - Raise the engineering bar. AI amplifies judgment — senior engineers become dramatically more productive, while junior engineers without judgment create confident-looking bugs - Redefine "productivity." Lines of code is dead. Outcomes delivered per engineer is what matters. **Common mistakes:** - Mandating AI adoption without investing in test coverage — accumulates invisible debt - Measuring AI adoption by tool usage instead of outcome improvement - Treating AI-generated code as trustworthy by default — it needs the same review rigor as human code - Cutting engineering headcount because "AI can do it" before understanding what AI can and can't reliably do --- ### Shift 2: Smaller Teams Build Bigger Products **What's changing:** 3-5 people can now build what required 20-30 two years ago. The justification for large engineering headcount is under pressure. Cloudflare rewrote Next.js using AI agents in one week. `[emerging]` **What the CTO should do:** - Embrace it. Smaller teams with higher judgment and better AI tooling ship faster and more coherently - Hire for judgment, not headcount. Each person has higher leverage, so wrong hires are more costly - Invest in AI infrastructure that amplifies each person: coding assistants, automated testing, CI/CD, monitoring - Redesign processes for small teams — many processes were designed for 20-person teams and don't scale down **Common mistakes:** - Using "we're a small team" as an excuse for no process. Small teams need LESS process, not NO process - Keeping large-team processes (Scrum for 3 people, daily standups for everyone) when the team has shrunk - Equating "small team" with "no specialization." Even 5 people need clear ownership - Not hiring when you genuinely need to because "AI should handle it." AI augments, it doesn't replace judgment --- ### Shift 3: Build vs. Buy vs. Generate **What's changing:** AI can generate code to spec, creating a third option for every technical decision. The traditional build-vs-buy framework now has three dimensions: | Option | When to choose | Risk | |---|---|---| | **Build** | Core differentiator, needs deep customization, long-term ownership | Time, maintenance burden | | **Buy** | Commodity feature, established SaaS exists, not a differentiator | Vendor lock-in, cost scaling | | **Generate** | Prototype, internal tool, well-specified problem, reversible | Quality uncertainty, maintenance unclear | **What the CTO should do:** - Default to "generate" for prototypes and internal tools. Speed of validation matters more than code quality for throwaway work - Default to "buy" for commodity infrastructure. Don't generate your own auth, payments, or monitoring - Default to "build" for your core differentiator — the thing that makes your product unique - For everything in between: how reversible is the decision? If you can regenerate it in 2 days, "generate" is almost always right **Decision framework:** ``` Is this your core differentiator? ├─ Yes → Build. Own it. Invest in quality. ├─ No → Is there a reliable SaaS for this? │ ├─ Yes → Buy. Don't reinvent wheels. │ └─ No → Can AI generate a good-enough version? │ ├─ Yes → Generate. Test thoroughly. Iterate. │ └─ No → Build. But keep it simple. ``` **Common mistakes:** - Generating your core product. AI can build fast, but the judgment about WHAT to build is still human - Building everything because "we might need to customize it later." YAGNI applies more than ever - Treating generated code as disposable — if it goes to production, it needs tests, monitoring, and ownership --- ### Shift 4: The "Everyone Can Code" Dynamic **What's changing:** Non-engineers (CEOs, product managers, designers) now use AI tools to generate functional code. Tobi Lütke (Shopify CEO) ships code via agents. The CTO's monopoly on "knowing how software works" is weakening. `[practitioner: Willison]` **What the CTO should do:** - Don't resist it. Welcome it. Non-technical leaders who understand code make better decisions - Reframe your value: the CTO's unique contribution is no longer "can write code" — it's "knows what to build, what not to build, and how to make it reliable at scale" - Create guardrails, not gates. Let non-engineers experiment. Protect production with review processes, not access controls - Translate "I built this with AI in an afternoon" into "here's what it takes to make this production-ready: testing, security, deployment, monitoring, scale. The AI handled 30% of that." **The conversation guide — when a non-technical leader says "just use AI":** 1. Agree first: "Yes, AI can generate that code." 2. Add the missing context: "Here's what else goes into making it reliable: [testing, security, deployment, monitoring, user management, permissions]." 3. Quantify: "The AI handles about 30-40% of the total work. The other 60-70% is making it production-grade." 4. Offer options: "We can ship a prototype in X days. Production-ready takes Y weeks. Which do you want?" **Common mistakes:** - Gatekeeping. "Only engineers can write code" is no longer true and defending it makes you the obstacle - Not gatekeeping. Generated code in production without review is a reliability risk. Both extremes are wrong - Feeling threatened. The CTO who sees AI-empowered non-engineers as a threat has misunderstood their own role --- ### Shift 5: Technical Strategy Half-Life Collapses **What's changing:** A CTO who chose a data architecture in Q1 may find it obsolete by Q4 because a new model capability eliminates the need. The strategic half-life of technical decisions has collapsed. `[emerging]` **What the CTO should do:** - Design for reversibility. Architecture as optionality management, not commitment - Shorten commitment cycles. 12-week strategy windows with 6-week execution sprints. Review, don't re-litigate - Invest in abstractions that let you swap implementations. Use interfaces/contracts at system boundaries - Accept uncertainty as permanent. The "right architecture" is the one that's easiest to change when you learn more **Common mistakes:** - Trying to future-proof. You can't predict what AI will be able to do in 12 months. Design for change, not for a specific future - Pivoting too often. The half-life is shorter, but it's not zero. Committing for 12 weeks is still necessary to learn anything - Analysis paralysis. "Let's wait until the landscape settles." It won't. Make the best decision with what you know and build the ability to change it --- ## AI Infrastructure Decision Framework ``` Considering AI infrastructure? ├─ Using AI models (LLMs, embeddings, etc.)? │ ├─ API-based (OpenAI, Anthropic, etc.) │ │ ├─ Pros: No infrastructure, latest models, lower upfront cost │ │ ├─ Cons: Token costs at scale, data privacy questions, vendor dependency │ │ └─ Choose when: Prototyping, < 1M requests/month, non-sensitive data │ ├─ Self-hosted (Ollama, vLLM, etc.) │ │ ├─ Pros: Data privacy, predictable cost at scale, customization │ │ ├─ Cons: Infrastructure complexity, GPU costs, model updates manual │ │ └─ Choose when: Sensitive data, > 1M requests/month, regulatory requirements │ └─ Hybrid │ └─ Choose when: Different use cases have different requirements ├─ Building AI features into your product? │ ├─ Start with API-based. Always. │ ├─ Measure token costs monthly as a budget line item │ ├─ Move to self-hosted only when costs or privacy force it │ └─ Build abstraction layers from day one — swap providers without rebuilding └─ Using AI for internal tooling (coding assistants, automation)? ├─ Invest early and measure outcomes ├─ Don't force adoption — let it spread from champions └─ Measure: outcomes per engineer, not tool usage ``` ## Token Costs as a Budget Line Item Token costs are the new cloud compute bill. They're growing faster than most CTOs expect. **How to manage:** - Track token spend per feature/service. Attribute costs to business functions - Set budgets per team/feature. Treat tokens like compute — someone owns the cost - Optimize prompts for cost, not just quality. Smaller models for simple tasks, larger for complex - Cache aggressively. Same query = same response = don't pay twice - Model tiering: use haiku/small models for routing, sonnet/medium for analysis, opus/large for complex reasoning **What "good" looks like:** - Monthly token cost review with engineering leads - Cost-per-transaction metric alongside DORA metrics - Budget alerts before overspend, not after --- ## AI-Generated Technical Debt **What it is:** AI coding assistants generate code that works but may be architecturally incoherent. The code compiles, passes tests, and functions — but doesn't follow the codebase's conventions, duplicates existing patterns, or introduces subtle inconsistencies. `[practitioner: Fowler]` **How it differs from traditional tech debt:** - Traditional: deliberate shortcut taken knowingly - AI-generated: unknown shortcut taken unknowingly — the engineer may not realize the AI chose a suboptimal pattern - Traditional: concentrated (one developer's decisions) - AI-generated: distributed (AI makes different choices each time) **How to manage:** - Code review is MORE important, not less. Review AI-generated code for architectural coherence, not just correctness - Maintain strong test suites — they catch behavioral regression even when the implementation changes - Use linters and style guides aggressively — catch convention violations automatically - Periodic "coherence reviews" — does the codebase still make sense as a whole? - Track AI-generated code separately if possible — measure its maintenance cost over time --- ## AI Readiness Assessment Framework Use this to evaluate how well an engineering team uses AI and where to invest. | Dimension | Level 1 (Basic) | Level 2 (Integrated) | Level 3 (Native) | |---|---|---|---| | **Tool adoption** | Some engineers use AI autocomplete | Team has standard AI tooling | AI agents integrated into workflows | | **Test infrastructure** | Manual testing, some unit tests | Automated test suite, CI | Comprehensive tests that validate AI output | | **Code review** | AI code reviewed same as human | AI code review guidelines exist | Architectural coherence review for AI output | | **Cost management** | No tracking | Monthly token cost review | Per-feature cost attribution and budgets | | **Knowledge** | Individual learning | Shared best practices | Team-wide AI workflow documentation | | **Security** | No AI-specific considerations | AI output reviewed for security | Automated security scanning for AI patterns | **How to use:** Assess current level per dimension. Invest in the lowest-scoring dimension first — the chain is only as strong as the weakest link.