VP of Technology breaks down how his team uses Claude Code — and how it was adopted without resistance

Pedro Gustavo Torres is VP of PXM Technology and Architecture at Centric Software, where he's using AI to build a complex product.

We talked to Pedro about successful AI adoption and how Claude Code is changing the game. Here's what he said.

A low-ego leader

I'm VP of PXM Technology and Architecture at Centric Software. Our product engineering team is around 60 people. We have a very complex product that works like a Swiss Army knife: extremely flexible and customizable for our customers and partners.

We have frequent deployments with monthly "releases" (i.e., marketing alignment), and our current architecture is a monolith with loosely coupled services that extend its capabilities. We can also deploy our system in any AWS region, enabling us to offer a truly global solution.

As for me, I’m a low-ego leader, biased toward action, and passionate about building and scaling high-performing engineering teams across startups, scaleups, and enterprise organizations.

I use AI daily to maximize my output and outcomes. It is a game-changer!

Pedro Shares

I use AI daily to maximize my output and outcomes. It is a game-changer!

How Claude Code is revolutionizing software engineering

The entire team uses Claude Code for our development tasks now. We also use it for code reviews. But honestly, Codex and CodeRabbit are just as good.

Before Claude Code, we required a lot of hand-holding and support. With Claude, that need decreased, and everyone became more autonomous, developing tasks from soup to nuts.

The SRE team experienced its biggest breakthrough when Claude Code proved itself a remarkable troubleshooter! Troubleshooting that once took hours now takes a few minutes. Show it the systems, log locations, etc., and Claude can make an amazing diagnosis of any hairy situation. It deeply impresses me.

I can't imagine a future in the Software Engineering industry without it.

How AI and humans can work together

Humans with AI become superhumans. I don't see any work that is exclusive to humans or to AI. I see them always working together. Humans work alongside AI, supervising and steering it whenever needed.

We use AI for planning, implementation, and review; a human then conducts a final review of AI's work.

Beyond that, AI can chime in on any topic. Want to brainstorm an architecture decision? Claude can create an ADR. Want to perform a code review? Claude will learn your repo and give you meaningful feedback. Want to troubleshoot an incident? Claude will get to the root cause much faster than a human can.

The possibilities are endless. Claude even helped us decide among several message broker options, simplifying the choice by clearly stating the pros and cons.

And most recently, while exploring an agentic experience within our product, we were able to prototype and get feedback and validation within days. Without AI, it would have taken several months.

Why the only metric that matters with AI is time from idea to customer-ready solution

As far as results, I think it is too soon to give numbers. I would rather challenge the usual school of thought here.

To me, metrics like deployment frequency, defect rate, cycle time, uptime, and cost efficiency miss the point. They are, of course, important. But what we really need to be measuring is the time it takes to get from an idea to delivering a working solution to customers.

Sure, one could argue that the frequency of deployments gets one closer to delivering solutions to customers, but to me, that still measures the "wrong" thing.

I invite everyone to focus on what matters: the time from idea to delivery. Everything else could be considered a vanity metric — or could even be gamed.

Why AI failures are usually low risk

Like everything else, AI comes with its challenges.

One challenge is that it has become harder to resist becoming "lazy" and over-relying on AI tools. But then again, is that a bad thing? Only time will tell.

Another challenge is poor output. But this usually happens when we do not provide the full context, or we omit important details that AI needs to execute the task. As I like to say: "AI is great, but it doesn't read minds... yet!"

I've found it effective to feed AI the artifacts — e.g., the documents — such as the following:

• Problem statement
• Considered approaches
• Chosen solution
• Implementation plan (e.g., JIRA epics and tickets)

This provides a powerful, consolidated view of any initiative.

Luckily, when AI doesn't behave as expected, the impact is usually only token consumption — assuming the right guardrails are in place. Yes, it can be costly, but we can address even that with minimal effort.

Why psychological safety is key in AI adoption

My teams embraced Claude Code well. They showed little to no resistance, and I saw their excitement about using the new tool as a force multiplier.

A main cause of this was the psychological safety we provided: AI did not take anyone's job; it enhanced their capabilities.

Aside from psychological safety, teams need three things for successful AI adoption:

• Clarity
• Competence
• Autonomy

I recommend that leaders take care of those basics before implementing AI. Otherwise, AI won't solve anything. On the contrary, it can make things worse.

And one other thing. There can be initial confusion and disorientation since AI changes many aspects of people's day-to-day lives. Like with any new tool, people will need time to adapt.

Pedro Shares

There can be initial confusion and disorientation since AI changes many aspects of people’s day-to-day lives. Like with any new tool, people will need time to adapt.

How CTOs should use the usual change management playbook with AI

Once you're ready to begin, I would follow the "regular" playbook: Find interested people, get them together, define principles, create a plan, build enablement material, put guardrails in place, and roll it out. After that, monitor how things evolve and act accordingly.

This is a pure change management exercise.

Why software engineering jobs are safe

I don't think software engineers will lose their jobs. I understand the concern, but it will be fine. Humans will always be needed, maybe just in different functions.

There's a lot of talk about juniors losing their jobs, but I think there will always be a need for them. We just have to wait for the dust to settle — and it is already starting to settle.

How AI is changing software engineering

We shouldn't stress too much about perfect code. Humans and AI both make mistakes, so bugs have always existed and always will exist.

What's needed now is a mindset change toward being more pragmatic and less perfectionistic.

Nothing good comes from perfectionism. It slows teams down significantly. In contrast, pragmatism helps us act more decisively, move the ball forward, avoid over-engineering, and focus on what matters: customer value.

That's where I see software engineering going with AI. Less craft, more pragmatism.

Why CTOs must embrace AI and learn the basics

Here's my advice to CTOs: Embrace AI, and embrace it fast. AI is here to stay. It is not a fad.

I see companies taking forever to deploy AI tools in their day-to-day work, but that is a mistake. The competition won't wait. Don't fall into the trap of being over-cautious. Deploy AI fast and furiously.

And read up on the basics. I found it incredibly helpful to understand how everything works, from data science and machine learning to LLMs, RAG, vector embeddings, and vector databases. Learn it.

Follow along

You can follow Pedro Gustavo Torres' work on LinkedIn, X, and SlideShare.

More expert interviews to come on The CTO Club!