I recently talked with a CTO who had left his company.
\nHe did not leave because he had another big offer waiting.\nHe did not leave because he was tired of engineering.\nAnd he was not trying to disappear for a few months and call it a sabbatical.
\nHe left because he wanted a better chance of surviving the next version of this industry.
\nThat sounds dramatic when I write it down.\nBut the way he said it was calm.\nAlmost practical.
\nHe looked at the company, looked at how quickly AI was changing the expectations around engineering, and realized he was not getting enough room to learn in the way he needed to learn.
\nThe company wanted to become AI-native.\nThe founder wanted to lead that change personally.\nAnd somewhere in the middle of all that excitement, the founder submitted a pull request with more than six million lines of code.
\nWith a smiley face.
\nI keep thinking about that image.
\nTo be clear, I do not think the founder was trying to make a mess.
\nI think he was excited.\nAI gave him a new kind of leverage, and suddenly it felt possible to move faster than the company had ever moved before. That feeling is real. I have felt a smaller version of it myself.
\nYou ask for something. The agent works. Files change. A feature appears. The blank page is gone.
\nIt feels like progress because some of it is progress.
\nBut six million lines of code is not a normal pull request. It is not even a normal engineering conversation anymore.
\nAt that size, the questions change:
\nThe CTO was not afraid of AI writing code.\nHe was worried about a company confusing output with direction.
\nThat difference matters a lot.
\nI hear \"AI-native\" everywhere now.
\nSometimes it means a company is genuinely changing how it works: learning faster, removing repetitive work, giving engineers better tools, and making room for more experiments.
\nSometimes it means everyone is expected to produce more, with fewer people, while nobody has decided what quality should look like anymore.
\nThose are very different companies.
\nThe hard part is that both can look similar from the outside. Both have AI tools. Both have agents. Both can ship a demo quickly.
\nThe difference shows up later.
\nIt shows up in whether people can question a risky idea without being treated like they are slowing things down.\nIt shows up in whether the team still has time to understand what it ships.\nIt shows up in whether reliability, design, and customer feedback still count when the code is arriving faster than ever.
\nThe CTO I spoke with did not feel like he had the space to help make that distinction.
\nSo he left.
\nNot to run away from AI.\nTo get closer to it.
\nTo be fair, I do not think every company is turning AI adoption into a giant pull request and a panic attack.
\nI cannot tell you what it is really like to work at Ramp, Stripe, or Notion from the outside. Public writing is still public writing. But the engineering details they share point to a healthier direction than \"ship more code and hope.\"
\nRamp built its own background coding agent, Inspect, around a fairly practical idea: the agent should not only write code. It should have the context and tools to verify what it did. Their setup gives the agent a sandboxed development environment, tests, telemetry, feature flags, screenshots, and live previews.
\nThat detail matters to me. The interesting part is not that Ramp has an agent. Lots of companies have agents now. The interesting part is treating verification as part of the work instead of something a human cleans up later.
\nStripe has taken a similarly careful public approach. Rather than assuming the newest model can run a software project on its own, its engineering team spent months building evaluation environments to test whether agents could create real Stripe integrations. That is a much more useful question than \"how much code can it generate?\"
\nNotion describes its own AI culture around people experimenting with useful agents for repeatable work, sharing what works, and freeing more time for critical thinking. Again, I am not saying any company is perfect. I just like the direction: make the boring work lighter, keep the meaningful decisions visible, and let people learn from one another.
\nThat is the kind of AI-native company I hope more of us get to build.
\nI have been thinking about my own career differently lately.
\nFor a long time, staying relevant meant getting better at the things I already knew: architecture, systems, product work, communication, delivery, helping a team make good decisions.
\nThose things still matter. Maybe they matter even more now.
\nBut I also do not want to be the person talking confidently about AI from a safe distance while other people are learning what it can actually do every day.
\nI want to stay hands-on.
\nNot because I think I need to win a contest for who can generate the most code.\nHonestly, that sounds exhausting.
\nI want to stay close enough to the tools that I understand their strengths, their blind spots, and the new kinds of mistakes they make. I want to know which work they make easier and which work still needs a human to slow down and think.
\nThat feels like the real survival skill to me.
\nI do not have a perfect plan. I am still figuring it out.
\nBut I have a few rules for myself right now:
\nThat is why I have been writing about agents, testing, persistent workspaces, and product direction. I am not trying to predict the whole industry from my desk.
\nI am trying to build enough firsthand experience that I can make better decisions inside it.
\nThere is a big difference between saying, \"AI will change engineering,\" and knowing what it feels like when an agent has changed thirty files, the tests are green, and you still have a bad feeling about the result.
\nThat bad feeling is not always fear of change.
\nSometimes it is judgment asking for a minute.
\nI do not think everyone needs to quit their job to stay relevant.
\nBut I do think it is worth asking an honest question:
\nIs my current environment helping me learn the kind of work I will need to do next?
\nIf the answer is yes, great. Go deeper.
\nIf the answer is no, that does not automatically mean you need a dramatic exit. Maybe it means finding a hands-on project, moving closer to the product, trying a new workflow, or making more space to learn outside the usual job description.
\nFor me, the goal is not to become an AI person because that is the label everybody wants right now.
\nThe goal is to remain useful.
\nUseful when the tools are amazing.\nUseful when the code gets weird.\nUseful when a founder sends a very large pull request with a smiley face and somebody needs to ask the quiet question:
\nWhat are we actually building here?
\nI think that question will survive every technology shift.
","timeToRead":6,"frontmatter":{"title":"The CTO Who Left to Stay Ready","description":"A conversation about AI-native change, a six-million-line pull request, and how I am trying to stay useful","date":"2026-08-26T00:00:00.000Z","updated":null,"slug":"/blog/the-cto-who-left-to-stay-ready","tags":["AI","Engineering","Career","Culture"]}}},"pageContext":{}}, "staticQueryHashes": ["1672341955","2009693873","2077189868","3505212370","3825832676"]}