Why This Matters Now

Software delivery is changing faster than at any point in the last two decades. AI coding assistants — IBM Bob, Claude Code, GitHub Copilot, Cursor, OpenAI codex and others — have compressed what used to take a sprint into an afternoon. A developer can describe an idea in natural language and watch a working prototype materialize within minutes. Legacy modernization, test generation, documentation, refactoring — tasks that once consumed weeks now resolve in hours.

This speed is intoxicating. It is also dangerous.

When the cost of building drops dramatically, the cost of building the wrong thing rises in equal measure. You can now ship a beautifully engineered solution to a problem nobody asked you to solve, faster than ever before. The constraint in software delivery has shifted: it is no longer about how quickly we can write code. It is about how clearly we understand what users actually need. This is precisely the gap that Enterprise Design Thinking is built to close. Far from being made obsolete by AI, the framework becomes more essential — a discipline that ensures the velocity AI provides is pointed at outcomes that matter.

The Framework, Briefly

Enterprise Design Thinking, developed by IBM to scale design practices across large organizations, rests on three principles, one continuous practice, and three alignment mechanisms.

The three principles are deceptively simple. Focus on user outcomes demands that teams obsess over what users can accomplish rather than what features are shipped. Restless reinvention treats every solution as provisional, always one user insight away from improvement. Diverse empowered teams recognizes that the best solutions emerge when developers, designers, product managers, operations, and end users work together with real authority to decide.

The practice is the Loop — Observe, Reflect, Make — repeated continuously throughout delivery. It is not a phase that ends when development begins. It is the rhythm by which teams stay connected to reality.

The three keys make the framework workable at enterprise scale. Hills are outcome-based mission statements that align teams on what success looks like. Sponsor Users are real people from each user group whose feedback shapes every decision. Playbacks are structured storytelling rituals that keep stakeholders aligned as work evolves.

These elements existed before AI coding assistants arrived. What changes now is how each of them is practiced, accelerated, and — in some cases — endangered.

The Loop in an AI-Augmented World

Observe: The First Step Cannot Be Automated

When teams adopt AI coding assistants, the temptation to skip observation grows stronger. Why interview developers about their pain points when AI can generate plausible-sounding user needs in seconds? Why shadow an operations engineer when a language model can summarize what an operations engineer probably struggles with?

The answer is that AI can describe the typical. It cannot tell you what your specific users, in your specific context, actually experience. A developer wrestling with a legacy mainframe integration in a regulated financial services environment has constraints that no general model will surface accurately. The wrong assumption here doesn’t just produce a suboptimal feature — it produces an entire roadmap aimed at the wrong target.

Observation in an AI-augmented workplace looks much like it always has: contextual interviews, shadowing, journey mapping, and empathy work. What AI changes is the speed at which the output of observation can be synthesized. Transcripts can be summarized, themes clustered, journey maps drafted. The human work of being present with users remains irreplaceable; the analytical work that follows is meaningfully faster.

Reflect: Framing Hills That Matter

Once teams have observed, they must frame the right problem. This is where Hills come in — outcome statements that answer three questions: Who is the user? What can they do now that they couldn’t before? What is the differentiated wow factor?

A well-crafted Hill in an AI-assisted IT context might read: A new engineer ships their first production-quality pull request on day one, with AI as their pair programmer, so they feel confident and the team ships faster.

Notice what this Hill does. It centers a specific user (a new engineer). It defines a concrete capability (shipping production-quality code on day one). And it identifies a wow factor (confidence and team velocity) that goes beyond merely automating an existing task.

The risk AI introduces here is subtle but corrosive: false consensus. An AI assistant, asked to draft Hills, will produce statements that sound polished and reasonable. Teams may adopt them without the harder work of grounding them in real user evidence. The discipline is to use AI to draft, refine, and explore variations — and then to test every Hill against Sponsor Users before committing engineering resources.

Restless reinvention applies here too. The Hill written on Monday should be challenged on Friday if new user evidence demands it. Teams that hold Hills too tightly miss the signal that their framing was wrong; teams that change Hills too casually lose alignment. The Loop creates the cadence for both holding and revising.

Make: Where AI Genuinely Transforms Practice

It is in the Make phase that AI coding assistants deliver their most visible value. Prototyping cycles that once took weeks now take hours. Teams can build three competing prototypes in the time it once took to build one. Working software — not wireframes, not slides, but actual functioning code — can be in front of Sponsor Users within a single working day.

This compression has profound implications. The traditional design thinking caution about prototyping cheaply and learning before investing becomes almost trivially achievable. The constraint shifts from how do we build a prototype quickly enough to test to how do we evaluate what we’ve built before falling in love with it.

And here is where the risks of AI in the Make phase concentrate. Speed without quality is recklessness. AI-generated code can hallucinate APIs that do not exist, skip edge cases that a senior engineer would have anticipated, and produce solutions that work in the demo and fail in production. The human-in-the-loop principle is not a bureaucratic constraint — it is a quality gate that protects the trust users place in your software.

The mature practice, then, is to use AI assistants aggressively in the Make phase while treating their output as a strong first draft requiring human review, testing, and validation. Restless reinvention applies to the prototype itself: throw it away when feedback demands it, iterate when feedback refines it, and ship only what has survived the gauntlet of Sponsor User scrutiny and engineering judgment.

The Keys at Enterprise Scale

Enterprise IT does not run in small co-located teams. It runs across continents, time zones, business units, and decades of accumulated system complexity. The three Keys i.e. Hills, Sponsor Users and Playbacks, exist precisely because alignment at this scale is hard, and AI assistants neither solve nor escape the challenge.

Hills Become the Shared North Star

In a single team, alignment can happen through conversation. At enterprise scale, alignment requires artifacts — and Hills are the artifact that travels. A well-written Hill can be understood by an executive sponsor in a Tokyo boardroom and by a developer in a São Paulo office and produce the same mental picture of success.

AI assistants help here by accelerating the drafting and refinement of Hills, generating variations, stress-testing language, and translating across audiences. They do not, however, replace the cross-functional conversation that earns a Hill its legitimacy. A Hill imposed by leadership without team buy-in is just a slogan. A Hill co-created by the team, grounded in user evidence, becomes a decision-making instrument.

Sponsor Users Anchor the Work in Reality

The Sponsor User practice — designating real people from each user group as ongoing feedback partners — becomes more important, not less, when AI is in the loop. The risk of building polished solutions to imagined problems grows when polished solutions become cheap to build.

In an IT context, Sponsor Users span the full delivery chain. Backend developers care about code quality and system design. Architects worry about scalability and technical debt. DevOps and Site Reliability Engineers focus on reliability and observability. Product managers track business outcomes and adoption. End users — the people whose work the software ultimately supports — bring the perspective that all of these technical concerns exist to serve.

A workable Sponsor User practice does not require a focus group every week. It requires a small, committed group of real users who agree to engage regularly, see prototypes early, and offer honest feedback. AI assistants can help summarize their input, surface patterns across sessions, and prepare the materials shown in each engagement. The relationship itself remains human.

Playbacks Create the Cadence of Alignment

Playbacks are the third Key, and arguably the most underestimated. A Playback is a structured storytelling session in which a team presents its current understanding of the user, the Hill, the prototype, and the feedback received — and invites stakeholders, sponsors, and Sponsor Users to respond.

In enterprise IT, Playbacks serve a purpose that no document or dashboard can replicate. They force alignment in real time. They surface misunderstanding while it is still cheap to correct. They build shared ownership by making the team’s reasoning visible. And critically, they convert feedback into commitments that feed the next turn of the Loop.

When AI assistants are part of the delivery process, Playbacks become the venue where teams demonstrate not just what was built, but how AI was used, what risks were identified, what human judgment was applied, and what remains uncertain. This transparency is essential to building organizational trust in AI-assisted delivery — trust that, once established, allows teams to move faster within sensible guardrails.

Diverse Empowered Teams: The Hidden Competitive Advantage

Of the three principles, diverse empowered teams is the easiest to nod at and the hardest to practice. AI coding assistants put pressure on this principle in both directions.

On one hand, AI levels certain playing fields. A junior developer can produce work that approaches the quality of a senior engineer’s first draft. A product manager who cannot code can prototype an idea and bring it to a technical conversation. A designer can sketch an interface in code, not just pixels. The capability gap between roles narrows, which makes cross-functional collaboration more productive than ever.

On the other hand, AI risks concentrating decision-making in whoever holds the prompt. If only the engineering lead is “talking to the AI,” the perspectives of designers, operations, and users may be summarized away before they ever reach the work. The practice of diverse empowered teams requires deliberately distributing the use of AI tools across roles and ensuring that the conversations happening with AI are paralleled by conversations happening between humans.

Empowerment also matters in a new way. Teams using AI assistants must be empowered to reject AI output, to slow down when the AI is leading them somewhere unwise, and to apply judgment that the AI cannot. A team that feels pressured to ship whatever the AI produces is not empowered; it is hostage to a tool.

A Working Example

Consider an enterprise IT team modernizing a legacy claims processing system at an insurance company. The team has six engineers, two product managers, a designer, and an operations lead. They have been given a mandate, a budget, and access to AI coding assistants.

The naive approach is tempting: feed the legacy codebase to the AI, ask for a modern rewrite, ship in six months. This approach will fail. It conflates code translation with system transformation and ignores the users — claims adjusters, supervisors, fraud analysts — whose work the system exists to support.

The Enterprise Design Thinking approach looks different. The team begins by observing — spending time with claims adjusters, watching them work, understanding which parts of the current system frustrate them and which parts they have learned to trust. AI helps summarize the dozens of interviews into themes; it does not replace the interviews themselves.

The team then reflects. They write a Hill: A claims adjuster resolves a routine claim in under three minutes, with the system surfacing the right context automatically, so they can spend their time on the complex cases that need human judgment. This Hill is sharper than “modernize the claims system” because it identifies who benefits, what changes for them, and what makes the change meaningful.

In the make phase, the team uses AI assistants aggressively. Three prototypes are built in two weeks, each exploring a different way to surface context to the adjuster. Sponsor Users — three claims adjusters, a supervisor, and a fraud analyst — review each prototype and provide feedback. One prototype is killed. Two are merged. The combined approach is refined over the next sprint.

Throughout, the team runs Playbacks every two weeks. Executives see progress. Sponsor Users see their feedback reflected. The engineering team explains where AI accelerated the work and where human judgment was decisive. Trust accumulates. Speed increases. The risk of building the wrong system diminishes with each turn of the Loop.

Six months later, the team has not just modernized a codebase. They have transformed how claims are processed. The Hill has been achieved, and the metric — average time to resolve a routine claim — has dropped from eleven minutes to two minutes and forty seconds. The complex cases, which used to suffer from adjuster fatigue, now receive the attention they need.

This outcome is not magic. It is the predictable result of combining a disciplined framework with powerful tools, applied by an empowered team focused relentlessly on a user outcome.

The Discipline That Speed Requires

The lesson of AI coding assistants for enterprise IT is not that design thinking is obsolete. It is the opposite: design thinking has become the discipline that allows the speed of AI to translate into outcomes that matter. Without that discipline, AI accelerates the production of impressive demos that solve the wrong problems. With it, AI accelerates the production of solutions that genuinely improve how work gets done.

The three principles, the Loop, and the three Keys are not bureaucratic overhead. They are the operating system of teams that can move fast without losing their way. In an era when the cost of building drops by an order of magnitude, the teams that win will be the ones who invest the time saved in understanding their users more deeply, framing their problems more sharply, and validating their solutions more rigorously.

AI handles more of the typing. Humans handle more of the thinking. The Loop turns faster, the Hills come into clearer focus, the Sponsor Users get heard more often, and the Playbacks become richer conversations about real progress on real outcomes.

That is the future Enterprise Design Thinking enables — and the future AI coding assistants make possible.

AI made the easy part of building easier. The hard part — knowing what to build, and for whom, and why — got harder. Enterprise Design Thinking is how you do the hard part on purpose. The bottleneck was never the code. It was always the clarity. AI just made that obvious.