Building teams for successful AI-Driven Development Lifecycle adoption

How AI is changing the skills your team needs

Adopting AI-driven development changes the balance of skills required within technical teams. In our experiences so far, leading AI tools like Kiro and Claude Code handle the bulk of the heavy lifting for writing code, analyzing issues, and performing unit and integration testing. This shifts your teams’ focus partially away from coding tasks.

However, despite the marketing hype, no AI can handle every aspect of a project without effective human oversight. Poorly directed AI can produce convincing but ultimately flawed outputs, typically referred to as “slop”, which fail to meet business needs.

From our work, we identified three competencies that are critical to making AI-DLC successful:

1. Business analysis & requirements engineering

In AI-DLC, the first and most important steering you provide to the AI during each blot is the requirements document. This must define the business requirements you’re seeking to fulfil along with detailed, testable acceptance criteria for each of them.

That is often harder than it sounds! One example from my previous projects was a requirement written by a senior leader simply stating “The system shall fulfil all future requirements”. It remains a memorable illustration of how vague requirements can be. Translating business needs into specific, achievable requirements is a specialist skill. I’ve observed in my work that the old adage of “garbage in, garbage out” remains very much in effect for AI models. Thus, the quality of the requirements and acceptance criteria you provide at the start strongly influence the quality of the results you’ll receive.

AI can help draft and refine requirements, but only after humans have understood and defined the desired outcome in detail. In my experience using Kiro, as an example of an AI-DLC tool, the largest single portion of project effort is spent refining requirements rather than writing code.

Consequently, your success at adopting AI-DLC depends on your teams having a strong foundation in business analysis and requirements engineering. Enabling them to effectively discover and describe business needs and turn those needs into achievable user stories with specific, testable acceptance criteria.

2. Solution & enterprise architecture

Even perfect requirements are not enough. My Fujitsu colleagues and I have noticed that even with the most capable coding models and largest context windows, feeding the entire specification for a large, complex system into an AI all at once invariably results in incomplete and low quality output.

The solution is effective architecture. Large systems must be broken into components that fit within the AI's practical "attention span" and organized across blots to build the solution incrementally.

Enterprise architecture also has a key role to play in shaping the AI models’ actions to maximize quality. A core characteristic of all Gen AI models, including those used for coding and development work, is that they are non-deterministic. In a nutshell, this means that given the same input 10 times in a row, the model may produce a different result each time and almost certainly will produce multiple distinct outputs.

Across multiple projects, I've seen the impact of AI's non-determinism in both solution design and feature development. Where the same technical challenge appeared in multiple parts of a system, an experienced architect would apply a consistent design pattern. Yet even Claude Opus 4.6—the most capable coding model at the time—often produced different, inconsistent solutions for each instance. To address this, an AI-DLC team must bring an enterprise architecture mindset in their reviews of the AI models’ proposed designs and implementation plans. Your team play a critical role in applying big picture thinking and driving architectural consistency and policy compliance both to each project individually and across projects.

3. Outcome-oriented testing

Throughout this article we’ve discussed “outcomes” repeatedly, which brings us to the third key competency for successful AI-DLC projects: testing.

AI-driven development automates much of the traditional testing effort. With Spec-Driven Development, a key enabler of AI-DLC, AI agents generate and execute unit and integration tests as part of spec-driven development.

And even more is needed for AI-DLC teams to be successful. A core aspect of AI-DLC is providing outcome-oriented direction to AI development agents. Your teams need to systematically test whether the resulting solutions deliver those intended outcomes. AI can help scale testing, but it cannot judge the gap between the intended outcomes and real-world results. This makes outcome-oriented testing a uniquely human capability. It requires evaluating how people, processes, and technology interact, then identifying the remaining gap between the current state and the desired business outcome.

Such expertise is, in my experience, rarely well developed or widely present in today’s corporate IT departments. Thus this is an area to focus your training investments in; equipping your teams to evaluate outcomes across the dimensions of people, processes, and systems. Describing the delta between the current state and the desired outcome at the end of each bolt is the critical driving force behind process for AI-DLC teams and projects.

Those insights become the input for the next blot, creating a continuous feedback loop that overlaps with the business analysis and requirements engineering we started with. Defining, measuring, and refining outcomes is what enables AI-DLC teams to iterate towards success.

The new balance of human expertise and AI capabilities

Throughout this blog, we’ve discussed key skills for success in a world where AI performs a lot of the undifferentiated heavy lifting of corporate IT projects. So how does this square with the industry rhetoric of AI replacing people wholesale?

In our work at Fujitsu, we've consistently found that AI models remain highly dependent on the quality of human direction. One example is sycophancy bias —the well-documented tendency of LLMs to flatter users and reinforce their opinions, even when their ideas are flawed. Left unchecked, AI can confidently generate polished but inappropriate or inconsistent solutions. This resulted in AI-driven development tools gleefully expending significant resources designing and implementing entirely inappropriate, or even technically impossible, ideas from the user, all the while telling that person what a great idea they’d had!

This even showed up in the style of the responses AIs gave to inputs, with the models leaning into token-heavy styles layered with jokes and emojis when the person gave signs they’d find such an approach funny.

In light of this, we can say that realizing the potential productivity benefits of these AI tools is reliant on the skills of the people wielding the tool.

AI-driven development doesn't eliminate the need for skilled teams—it changes where their expertise is applied. As coding becomes increasingly automated, capabilities such as business analysis, architecture, outcome-oriented testing, and effective AI steering become even more critical. The organizations that invest in these skills will be best placed to realize the full potential of AI-DLC.

Interested in learning more about how Fujitsu applies AI to software development? Visit this page for additional information, use cases, and the latest insights.