What AI-enabled delivery means for your IT talent

The productivity picture is changing

Over the past two years, AI-assisted development tools have moved from novelty to daily practice inside most serious engineering organizations. Code assistants, test generators, and automated review tools are now table stakes — not because they replace engineers, but because engineers who use them well produce meaningfully more in a given sprint.

That shift changes the calculus around IT talent in ways that are still settling. We want to share how we are thinking about it, because it affects how we staff engagements and what we look for when we place people.

What has actually changed

The clearest change is in the task mix. Work that once required several hours of careful human effort — writing boilerplate, generating unit tests, translating requirements into initial implementations — now compresses substantially when an experienced engineer uses AI tools well. That is a net positive, but it creates a bifurcation.

Engineers who have incorporated AI workflows into their practice produce more. Engineers who have not, or who have not yet learned to verify AI output rigorously, introduce new categories of risk: subtle bugs that pass surface-level review, hallucinated API calls, logic that is plausible-looking but wrong.

The skill that matters most right now is not prompt engineering — it is discernment. The ability to know when an AI suggestion is good, when it is plausible-but-wrong, and when the problem requires ignoring the assistant entirely.

What this means for how we find people

When we source for a client engagement, we have always screened for technical depth. We look for engineers and analysts who can work through ambiguous problems, not just execute against a clear spec. That has not changed.

What has changed is that we also evaluate how candidates use AI tools, and more importantly, how they think about their output. We look for people who treat AI assistance the way a senior engineer treats a junior suggestion: as a starting point worth scrutinizing, not a final answer worth shipping.

We also pay attention to the categories of work where AI assistance offers the least leverage: system design decisions, cross-team dependency management, security review, and anything that requires institutional context about a client's environment. Those are still human-hours-in tasks, and we look for depth there.

Deployment models adapt too

AI-enabled productivity also affects how we think about team composition on managed engagements. A smaller squad of senior contributors using AI tooling effectively can, in some cases, produce output comparable to a larger team of mid-level contributors without those tools. That is not a reason to understaff — it is a reason to staff deliberately.

We have shifted some of our ISG Global delivery models toward smaller, more senior blended squads for work that is AI-tooling-friendly (feature development, test coverage, documentation), while keeping larger specialist footprints for work that is not (data migration, integration testing, compliance review).

The Manila office, which handles a significant share of our execution-heavy delivery, has been early to adopt AI tooling in workflows — partly because the technical depth there supports it, and partly because the productivity leverage matters in a delivery center context.

The honest limit

AI tools do not change what good delivery looks like at the outcome level. Clients still need software that works, teams that communicate, and delivery that hits milestones. The tools change how you get there, not what you are aiming for.

We are still in the adjustment period — best practices are forming in real time, and the tools themselves are changing rapidly. What we can offer is that we are thinking about this actively, and the people we place are the kind of practitioners who think about it too.

If you are navigating what this means for your team's capacity or your next engagement, reach out to us. It is a useful conversation to have.