Editorial
The Gist
- AI can accelerate—but also destabilize—front-end development. Teams adopting composable architectures are leaning on tools like ChatGPT and Copilot, but speed often hides missing context, weak patterns, and brittle code.
- Context engineering is emerging as the backbone of AI-native workflows. By structuring stories, designs, component patterns and developer intent, AI can generate code that aligns with team standards instead of guessing.
- Reusable patterns—not raw accelerators—unlock sustainable agility. Organizations that treat design systems, atomic components, and legacy accelerators as AI-readable patterns are seeing faster delivery and easier onboarding.
Being stuck on an aging digital experience platform is painful. Not just because the page loads are slow, but because change is slow. Updating content, launching new features, iterating on experiences; everything takes longer than it should. Teams on older DXP and CMS platforms are feeling the friction, and many are making the move to headless, composable architectures built on frameworks like React and Next.js.
The appeal is clear. Modern architectures unlock better performance, developer flexibility, cloud-native scalability and faster iteration across channels. Teams gain the freedom to evolve their front ends independently, integrate best-of-breed services and adopt deployment and testing practices that feel modern and efficient.
But getting there isn’t easy. Re-platforming means rewriting large swaths of front-end code, aligning design systems, migrating content models and often rebuilding what was tightly coupled in the legacy stack.
It’s an expensive shift, and teams are understandably looking for leverage.
Table of Contents
- The Allure—and Limits—of AI Acceleration
- What Human Developers Already Know (and AI Needs)
- The Missing Ingredient: Continuous Context
- Context Engineering: The Foundation of AI-Native Development
- Redeeming Accelerators as Pattern Libraries
- Turning Old Accelerators Into Modern Patterns
- From Acceleration to Agility
- Looking Ahead: Building Solutions AI Can Help Sustain
- Shifting From Code Generation to System Stewardship
The Allure—and Limits—of AI Acceleration
That’s where AI has stepped in, offering the promise of instant productivity. Tools like GitHub Copilot, ChatGPT and Cursor make it feel like you can skip the boilerplate, accelerate front-end builds and scaffold features with just a prompt. “Vibe coding” has become shorthand for that feeling—fast, fluid development guided by conversational intent rather than architectural precision.
At first glance, it works. Components appear instantly. Pages scaffold themselves. The feeling is fast.
But fast is not the same as right.
AI Acceleration: Benefits and Fragility
Key contrasts between what AI-generated code appears to offer and the hidden risks teams encounter during replatforming and front-end builds.
| Perceived Benefit | Underlying Risk |
|---|---|
| Instant scaffolding of components and pages | Missing requirements or business rules that weren’t represented in the prompt |
| Faster delivery of front-end features | Implicit architectural decisions made by the AI without team alignment |
| Reduced boilerplate and developer toil | Brittle or opaque code that teams struggle to maintain or debug later |
| Momentum during early development phases | Accessibility, security and QA gaps that surface only when code reaches production |
When Speed Masks Structural Problems
Too often, the code works without anyone really understanding how or why. It may be enough to run a demo or migrate a page, but beneath the surface, key requirements may be missed. Accessibility can be overlooked. Security vulnerabilities may slip in unnoticed. Architectural decisions get made implicitly, without alignment or review. And without a clear understanding of what was generated and why, teams struggle to maintain or extend what’s been created.
Software development has always been about more than code. It’s about capturing and transferring context. Until we bring that context into the AI development process in a structured, repeatable way, the promise of acceleration will remain mostly unrealized.
What Human Developers Already Know (and AI Needs)
When a developer joins a project, they don’t start coding blindly. They begin by building context: reading the story, reviewing the designs, checking acceptance criteria and understanding how similar features were built in the past. They explore existing components, follow naming conventions, check for shared utilities and align with the architectural patterns the team has already committed to.
This context isn’t optional. It’s what ensures the new code fits the system. It’s what lets a developer move confidently, knowing their work won’t collide with others or introduce regressions. It’s also what allows them to move quickly without sacrificing maintainability or quality.
Related Article: Should Marketers Jump Into Vibe Coding?
The Missing Ingredient: Continuous Context
If we want to integrate AI into this process, we can’t treat context as a one-time input. We need to reimagine the development lifecycle itself so that context is continuously available, referenced directly and maintained alongside the solution. This means prompts aren’t just throwaway instructions; they become tracked artifacts, stored in source control and versioned with the code they produce.
It means component documentation isn’t written after the fact. It’s designed to serve the AI first, describing not just what a component does but how it should be built, where it fits and why certain choices were made. Context becomes modular, intentional and actively used by the tools generating the code.
With tools like Model Context Providers (MCP), AI can pull live, structured context from systems like Jira, Figma or Azure DevOps. This allows it to see the same story, the same design, the same constraints a developer would use and do so automatically, on demand. The result isn’t just better code, but a more maintainable, scalable process.
This isn’t about adapting AI to work within the old process. It’s about evolving the process so that AI is embedded within it, so that structured context, versioned intent and aligned output are part of the system from the start. Context engineering is one way to describe it. But what matters most is this: if AI is going to participate in building software, we have to give it a place in the lifecycle, not just a prompt box on the side.
Context Engineering: The Foundation of AI-Native Development
To make AI a meaningful contributor to the development process, we can’t treat it as a black box or a bolt-on. It needs to be embedded in the system, fed with structure, governed by patterns and aligned to the way teams actually work. That’s the premise behind context engineering: turning the inputs that developers already rely on into structured, accessible artifacts that AI can use, too.
The diagram below captures how this model work:
The triangle on the left represents the context an AI system needs to generate code that fits the solution. This is the same context a developer would reference: stories that define what needs to be built, Figma designs that capture intent and structure, reusable atoms and molecules that enforce consistency and existing code or pattern libraries that inform architectural choices.
In most teams, this context already exists, but it's fragmented. It lives in tickets, design tools, wikis and the minds of senior developers. Context engineering is about capturing that material with more discipline. It puts the developer in the loop, asking them to be deliberate about referencing the context they should be using anyway. Developer instructions become more than notes or checklists. They serve as a bridge between human intent and AI interpretation, guiding prompt construction, scoping what matters and reinforcing the patterns that sustain the system.
The Role of Engineered Prompts
What ties everything together is the engineered prompt. This isn’t just a sentence typed into a chat window. It’s a carefully constructed instruction set, assembled from both project-specific context and organization-wide standards. It sets the expectations not just for what should be built, but how. It outlines reasoning steps, coding conventions, documentation structure, testing requirements and accessibility rules. In this way, engineered prompts become the guardrails that ensure consistency across the entire system, whether you're generating a simple UI component or scaffolding a multi-step integration.
On the right side of the model are the outputs: code, test scripts, content models. These are real, production artifacts, but importantly, they’re not treated as static or sacred. Developers will, and should, make manual changes. The goal is not to have AI generate everything perfectly. The goal is to create a workflow where AI-generated output and human-authored adjustments live together, backed by shared context. The current version of the code becomes part of the context itself. When the prompt is run again, the AI doesn’t start over, it adapts to the state of what exists.
This isn’t about overwriting progress. It’s about maintaining alignment. When context changes, be it a story, a design tweak, or a refactor, developers can choose what to regenerate, what to preserve, and what to evolve by hand. The structure stays intact, the standards remain consistent, and the system continues to scale without relying on guesswork or tribal knowledge.
Context engineering doesn’t remove the need for judgment, it gives developers a more stable surface to apply it. It makes quality a first-class concern not just in outputs, but in process. And it sets the foundation for using AI not as a replacement, but as a responsive, reliable part of the development lifecycle.
Webinar
Dec
16
Roundtable: Turning Real-Time CX Signals into Business Results
Four big brands. One live, unscripted discussion on how modern CX teams move from dashboards to real impact.
Register
Webinar
On demand
Empowering Non-Profits: Smarter Crisis Communication and Community Engagement
The cost of miscommunication is measured in more than words. Learn to deliver outreach that's fast, clear and trusted.
Watch Now
Webinar
On demand
Unlock Connected Service: How to Forecast, Staff & Support Every Channel
Stop juggling tools. 73% of CX leaders say silos damage CX. Build a seamless service operation instead.
Watch Now
Webinar
On demand
Beyond Composability: How Modern Marketers Build Connected Experiences
Ready to launch campaigns faster, personalize smarter and prove your marketing ROI? Discover the power of a modern DXP.
Watch Now
Webinar
On demand
Rebrand. Migrate. Optimize. How to Do It All (Without Slowing Down)
Cresta leveled up site speed, design flexibility and marketer sanity (in record time). Find out how.
Watch Now
Webinar
On demand
From Manual to Magical: How AI Transforms CX Teams
Learn how to replace manual support processes with automation that actually delivers.
Watch Now
Redeeming Accelerators as Pattern Libraries
Agencies have long developed accelerators to make replatforming faster and more predictable. When moving from a legacy platform to a modern headless architecture, having a prebuilt library of components promised to reduce time spent rebuilding standard UI patterns: carousels, tabbed lists, modals and other common elements. These accelerators were intended to help teams focus on integration and business logic, not the basics.
But in practice, most don't adopt the components as delivered. Every organization had its own branding, layout conventions, data bindings and behavioral expectations. Even when the core logic is solid, implementations often have to be heavily reworked to fit the needs of the project. What is supposed to accelerate delivery often becomes something that has to be worked around.
Turning Old Accelerators Into Modern Patterns
That doesn’t mean those efforts are wasted. While the components may not be directly reusable, the decisions behind them remain valuable. Each one encodes a pattern: how a tabbed layout should behave, what a pagination model looks like, how hover states and responsiveness should feel.
How Legacy Accelerators Become AI-Readable Patterns
Instead of reusing old components as-is, teams can extract the reusable decisions they encode and structure them as patterns AI can understand.
| Legacy Accelerator Element | Reusable Pattern for AI |
|---|---|
| Prebuilt tabbed layouts | Interaction model: switching logic, breakpoint behavior, keyboard navigation |
| Carousel components | Rules for item rotation, pagination, responsive behavior and visibility constraints |
| Modal and overlay structures | Accessibility expectations, focus trapping and dismissal logic |
| Reusable content blocks | Semantic structure, data-binding rules and styling tokens |
These are the kinds of decisions that can and should be leveraged in AI-native development.
In a context-driven workflow, those accelerators become pattern libraries. They aren’t inserted into projects wholesale. They’re referenced intentionally. Instead of generating a component from scratch, a developer might guide the AI by saying, “Build this like our carousel pattern, but show only three items,” or “Use the same logic as the tabbed interface, but apply it to this dataset.” With the right prompt structure and developer instructions in place, AI can use these patterns to generate code that aligns with past decisions without being boxed in by rigid implementations.
Outside of accelerators, design systems and atomic design principles offer even richer context. Atoms and molecules: buttons, inputs, badges, cards aren’t just visual primitives. They define the building blocks of consistency. Systems like ShadCN offer clear, well-documented component contracts that AI tools already understand. Referencing a ShadCN component, or aligning with a team’s internal design tokens, gives the AI a solid starting point grounded in existing, opinionated UI logic.
By pulling from these sources: accelerators for structure, atomic systems for styling, and design systems for semantics, we give the AI a foundation it can build from. Not just something to generate against, but something to stay aligned with.
The result isn’t blind reuse. It’s guided creation. We’re not saving time by skipping the work, we’re saving time by teaching the system how to do the work the way we already know it needs to be done.
From Acceleration to Agility
By grounding development in reusable patterns, design systems and structured prompts, teams are already seeing gains in the early phases of delivery. In many cases, initial development time is reduced by 30 to 40%. But the real value of this approach isn’t just in building faster, it’s in how the solution holds up over time.
Traditional projects tend to slow down after launch. As the original team rotates off, and the solution grows in complexity, it becomes harder for new developers to trace intent, understand past decisions or make confident changes. Without structured context, code alone doesn’t explain itself.
With a context-engineered system, that barrier drops. The prompt history, component instructions, design references and architectural patterns are all preserved, versioned and scoped alongside the code. That context doesn’t just support regeneration. It supports onboarding.
Lowering the Barrier for New Developers
New developers can use AI as a conversational interface to the system, not to guess, but to ask grounded questions. They don’t need to read through every story or scan Figma boards manually. They can ask why a component was built a certain way, what pattern it follows, or what constraints shaped its structure. Because that context is part of the system, AI can respond with meaningful, project-specific answers.
This dramatically lowers the experience level required to maintain and evolve a complex solution. It doesn’t replace expertise, but it spreads it. Structured workflows allow even less experienced developers to contribute safely, interpret decisions accurately, and stay aligned with architectural intent.
This is what shifts teams from short-term acceleration to long-term agility. A faster build is helpful. A maintainable, learnable system: that’s what actually sustains delivery at scale.
Looking Ahead: Building Solutions AI Can Help Sustain
As more organizations take on platform migrations and replatforming initiatives, the instinct to treat AI as a shortcut will only grow. The idea of skipping boilerplate, auto-generating layouts or letting AI code full features with a single prompt is undeniably appealing. And in isolated cases, it works, at least well enough to demo.
But the real opportunity is larger than speed. It’s about using AI not just to generate outputs, but to help shape and structure the context that will guide those outputs over time. A system that simply produces code may get you to launch faster, but it also risks leaving teams with something brittle, opaque, or difficult to evolve.
From Acceleration to Sustainable Agility
A comparison of short-term speed gains versus long-term system health when adopting AI-supported development workflows.
| Acceleration (Short-Term) | Agility (Long-Term) |
|---|---|
| Rapid scaffolding of components and pages | Consistent, maintainable code shaped by structured context |
| Faster initial delivery phases | Predictable evolution of features backed by pattern alignment |
| High reliance on prompt improvisation | Versioned prompts and instructions that scale with the codebase |
| Works well for demos and prototypes | Supports onboarding, regeneration, refactoring and long-term stewardship |
| Output-first mindset | System-first mindset where context and code evolve together |
Shifting From Code Generation to System Stewardship
In the future, AI will play a role in building not only the components, but the ecosystem around them. Stories, developer instructions, design annotations, test scaffolding ... these can be drafted, reviewed and refined in the same loop. The point isn’t to eliminate the human, but to shift their role: from author to editor, from context collector to context curator.
When that happens, replatforming doesn’t just produce a new codebase. It produces a system that knows itself. A solution where developers, new or experienced, can ask questions, trace decisions, regenerate features, and stay aligned with the patterns that made it work in the first place.
That’s the future worth aiming for. Not automation for its own sake, but a more thoughtful, maintainable way to build, where AI is woven into the process, and the process is designed to last.
Learn how you can join our contributor community.
