What Leading a Hybrid Human-AI Team Actually Looks Like

A few weeks ago, our CTO, Patrick Gardella, sat down with Amir Khan, Co-Founder and COO at PureLogics, for a conversation about what it actually takes to run engineering teams where AI is doing a meaningful share of the work. Patrick has spent 25 years leading technology teams, most recently in healthcare and life sciences before joining Monstarlab. The full conversation is available as a written article, a video, and a podcast episode. We wanted to pull out the parts that matched what we are seeing across our own engagements, alongside some outside research that adds useful context.

Patrick's central point is that AI is a bigger shift than cloud or mobile, not because the infrastructure changed but because it changes what a person can do in a day. That framing matters for how a technology leader thinks about people, training, and delivery models. It is also a framing that takes real, ongoing effort to act on, since it means treating AI adoption as a change in what the job is rather than a one-time tooling rollout.

The fragmentation problem is real, and it is quiet

One of the points Patrick raises is about tool fragmentation. When one engineer is deep in Copilot, another is working almost entirely in Claude, and a third has built a personal workflow around ChatGPT, the team can look productive individually while losing consistency collectively as prompts do not transfer between people. Context gets rebuilt from scratch every time a task hands off. It is the kind of gap that is easy to miss until a project ends up with several different partial approaches to the same problem.

Patrick's approach is not to mandate a single tool, since engineers tend to have good reasons for their preferences. Instead, the fix is standardizing the prompt libraries and shared context documents that sit underneath whichever tool someone chooses. It is a smaller intervention than it sounds, and one that tends to get built only after a team has already felt the friction of not having it.

This lines up with findings from Stack Overflow's most recent Developer Survey. Even with 80 percent of developers now using AI tools in their workflows, trust in the accuracy of AI-generated answers dropped from 40 percent to 29 percent year over year, and 45 percent of developers named "almost right, but not quite" outputs as their top frustration industry-wide. Standardized context will not fix that accuracy gap on its own, but it does mean a team is working through the same failure modes together instead of each person discovering them independently.

Code generation is not one number

Patrick puts AI's share of code generation somewhere between 30 and 90 percent depending on the engagement, shaped mostly by client trust and how sensitive the domain is. That range is wider than most public commentary allows for, and we think that is because a lot of commentary is reaching for one industry-wide statistic when the honest answer depends on the client relationship and the regulatory weight of what is being built.

Outside research supports a range rather than a single number. The same Stack Overflow survey found that 72 percent of developers do not use full "vibe coding," meaning end-to-end application generation from prompts, in their professional work, even as AI-assisted coding overall keeps growing. The difference between "AI helps write this function" and "AI generates a compliance-critical module unsupervised" is where that 30 to 90 percent range lives, and it is a distinction a single adoption percentage would flatten.

Verification as a standing practice

Patrick is direct about the discipline this requires. His approach combines closed-ended prompts where possible, a knowledge base thorough enough to narrow the room for error, and human verification before anything reaches a client. None of that is exotic, and it reflects an approach we recognize in our own delivery work: verification is built in as a standing part of how AI-assisted work gets delivered, not a phase to eventually phase out.

McKinsey's recent research on enterprise AI trust points to why that discipline matters industry-wide. Among the organizations it surveyed, only about 30 percent had reached a mature level of governance over agentic AI, and security and risk considerations were the most commonly cited factor in how organizations pace their scaling plans. The firms McKinsey found performing best on the metrics that matter to leadership were the ones that built verification and governance in as a permanent part of the operating model, not an afterthought.

Cost as an explicit target

Agentic AI carries real, variable costs, and Patrick's view is that "maximize AI use while minimizing spend" has to be an explicit target that someone owns, rather than an outcome teams hope shows up on its own. McKinsey's data adds useful texture here: organizations that invested at least 25 million dollars in responsible AI practices reported meaningfully higher maturity scores and a much better likelihood of EBIT impact above 5 percent. That investment functions less like overhead next to the AI program and more like a condition for the program producing a return at all.

Compliance from the architecture stage

For regulated clients, Patrick is clear that HIPAA and GDPR requirements need to shape the initial architecture decisions rather than get added after a proof of concept is working. This is a familiar principle in enterprise software, and it carries added weight with AI in the loop, since retrofit costs run higher. A data pipeline built without compliance in mind is expensive to adjust later. Getting the architecture right early is the more efficient path either way.

What this means for junior talent

Patrick's view on junior developers is one of the parts of the conversation we spend the most time on internally. As AI absorbs more of the mechanical work of writing code, the differentiator for someone early in their career shifts toward domain expertise and systems thinking: understanding why a system needs to work a certain way, not only how to make it compile. That is a different thing to teach and a different thing to hire for, and it means training pipelines are evolving alongside the technology itself.

Building it on purpose

A theme running through the conversation is that adoption, cost discipline, and data quality take deliberate ownership. They do not arrive automatically once a tool is deployed. Standardized context, verification workflows, cost ownership, and compliance-first design each need someone to build and maintain them intentionally. The organizations having the most success, our own included, treat their AI operating model the way they would treat any other piece of critical infrastructure: with a clear owner, a budget, and a plan for how it evolves.

We do not think this is a finished playbook, and Patrick would likely say the same. The research is moving quickly enough that some of what holds true this quarter will need revisiting next year. What we can say is that the practices described here match what we are seeing across our own engagements, and the outside data suggests plenty of other organizations are working through the same questions.

Read the full conversation with Patrick as a written article, watch the video, or listen to the podcast episode.


Sources referenced