Have you Had Your Claude Code Moment Yet?

If not, cancel your meetings for a half day - your job may depend on it...

If you’re an engineering leader and you haven’t taken a solid half day since the Opus 4.5/Codex 5.2 releases in November to work with Claude code on something meaty, you need to block the time to do so ASAP.

Before, and after

Every CTO I talk to who has personally sat down with Claude Code (or Cursor, or Copilot in agent mode) and built something real has the same reaction: this changes everything. Not “this is a useful tool.” But “when we figure it out, this is going to change everything we do”.

The ones who haven’t had that moment are managing a transition they don’t feel. They’re reading the reports, setting the strategy, approving the licenses. But they’re steering by instruments, not by feel. And their teams can tell.

The moment is not “I tried it and it autocompleted some code.” The moment is when you give it a real task, something that would have taken you a day, and it does it in twenty minutes. And it’s not perfect, but it’s 80% right and you can see exactly how to fix the rest. That’s when the implications hit.

My Claude Code Moment

For me, in a day I managed to import ~350 various spreadsheets with attendees from events I’ve run over the last 20 years, ingest all of the events I have run from a combination of local files and websites, load up 25 years of emails and meetings, ingest 9 months of granola meetings and create a rich CRM cross referencing all of that data. In a spare half hour I got connectors to capture my health tracking data from an Oura ring and an Apple watch.

In another day I had a full time agentic team with back stories, motivations, personalities and well defined job descriptions with the ability to send and receive email, chat via telegram and iteratively improve their performance at the end of each session.

Right now I’m building my own version of Monday.com to manage my agentic org, a custom wiki to share playbooks with partners (human and agentic) and I’m crafting the version of Circle.so I always wanted to build exactly the community that I want for Gather.

A Practical Plan

It doesn’t matter if you haven’t written production code in years. Try to do something - build your own little app to ingest your Jira, slack and GitHub data to capture insights about a projects health. Create a lightweight budget scenario planning app to see the impact of different staffing decisions on your cost structure. Write something to ingest all of your Jira tickets and classify whether they’re R&D or categorize as KTLO vs feature development. Work within the constraints that your org requires and be thoughtful about the security implications of any data you process.

Here are some things that’ll help you get the best out of the session:

• Specification and verification - You need to articulate your exact functional requirements and have a clear definition of done that will help the agents generate test cases to confirm that the software meets your needs.

• Small, thin slices - We’ve always know the value of decomposing work into small, thin slices of user valued functionality. It’s doubly important with agents or you’ll blow the context window and enter “the stupid zone” where the agent starts forgetting what it built ten minutes ago.

• It takes a team - At the very least, have an agent create the code, clear the context window and then have it create and run the tests. Better, create a “coder” and a “QA” agent, so each has a clear intent and job, and let them work on it until the tests pass.

• Each failure is feedback - It’s pretty unlikely that you’ll one shot an app that meets your needs (although it’s happening more and more), but see issues as a signal to add more context and/or roles. If the naming of the classes is imprecise, add an agent whose only responsibility is to propose better names for methods, classes and variables on every PR. If the architecture is inelegant, add an agentic architect. If there is repeated code, add a DRY bot to stop your coding agents repeating themselves.

• You’re building the builder, not the app - The new job is not to take the autocomplete suggestions and to fix them, but to continue to refine the elements of the system you use to build the apps, so you can iterate towards a robust software factory where no human writes the code, no human reads the code, and the output is still better than what your team could have delivered manually 2 years ago.

In a half day, you’re not going to end up with a fully functioning software factory. But hopefully you’ll realize just how transformative this has the potential to be and you’ll be in a much stronger position to help your engineering org to retool in the ways it’ll need to keep up with the upcoming changes in the industry. It’s going to be quite a ride!

When did you have your Claude Code moment? What did you learn from it? How has it changed how you manage your org?