Blueprint has shipped a lot in the past year, and I’m curious how much of it has made the jump from “cool demo” to “part of how my team actually works.”
A few features in particular:
Integration Designer imports. Since May you can import API specs and database schemas straight into the Data & Integrations step and let Blueprint auto-generate the integration systems, then map data objects by drag and drop. On paper this kills a whole category of discovery-phase spreadsheet work. Has anyone run this against a messy real-world schema (hundreds of tables, inconsistent naming) rather than a clean sample? How did the AI-suggested mappings hold up?
MCP Preview. There’s already a great thread here on prototyping with customer AI teams through the MCP gateway. I’d love to hear from anyone who’s taken it a step further. Has an MCP-driven prototype session actually changed the design that went into the Blueprint, or shortened your discovery timeline in a measurable way?
Decision Preview / simulation. Does live simulation build confidence with stakeholders, or does it invite endless “what if we tweak this” rabbit holes?
Vibe coding assistant. Now that you can converse with the design by text or speech and flip back to drag-and-drop at any point, is anyone actually using voice? And where do you draw the line between letting the assistant restructure things vs. modeling it yourself?
So, question for the circle:
When you’re creating a Blueprint, what’s delivering the most value for you? Is it the AI assistance itself, the ability to upload assets (briefs, API specs, schemas, supporting docs) that help generate the workflows and data model, getting a handle on MCP connections and integrations early, or something else entirely?
I’ve started treating Blueprint less as an “AI that builds an application” and more as a shared design workspace for business, architecture, and delivery teams.
In my experience, the biggest value is not the AI conversation itself. The real benefit is having process knowledge, data models, integrations, personas, decisions, and a working preview represented in one artefact that everyone can inspect and challenge before implementation starts. That changed the conversation from “Can Blueprint generate this application?” to “Have we understood the process, data, integrations, decisions, and exceptions well enough to build the right application?”
The assistant, MCP, voice, simulation, and integration-import capabilities are useful accelerators. But the durable value is the Blueprint itself: a structured artefact that connects business intent, workflows, data, integrations, personas, decisions, and previewable behaviour in one place.
The biggest value has been the rapid application acceleration. One of our clients used Blueprint and was impressed enough to demonstrate the output to their leadership team shortly afterward. The ability to quickly generate a solid application foundation and get an initial solution uplift in hours rather than weeks was the key benefit.
The most valuable capability for me is not the AI conversation itself, but the ability to bring business requirements, API specifications, database schemas, supporting assets, personas, workflows, and integration designs together in a single living artifact. Features such as Integration Designer significantly reduce manual discovery effort by automatically generating integration systems and suggesting data mappings, allowing architects to focus on validation rather than documentation. MCP Preview is particularly exciting because it enables early AI-driven simulation of workflows, helping business stakeholders interact with proposed solutions before any implementation begins. This often exposes design gaps, missing decision paths, or integration assumptions much earlier in the lifecycle. Decision simulation adds another layer of confidence by allowing teams to validate business outcomes and operational scenarios upfront, reducing costly rework later. The new vibe coding experience is also a strong productivity enhancer, especially for refining personas, workflows, and data models through natural language or voice interaction. However, in enterprise environments, architectural governance remains critical. AI should accelerate architecture, not replace it. Complex decisions around security, integration ownership, data governance, reuse strategies, and enterprise architecture still require experienced architects to guide the design. In my experience, the winning approach is a partnership between AI and human expertise: let AI handle repetitive discovery activities and generate the initial design foundation, while architects focus on business outcomes, enterprise alignment, governance, and solution quality. Ultimately, Blueprint’s greatest value is its ability to transform discovery from a document-centric activity into a collaborative, AI-assisted design experience that is much closer to implementation readiness than traditional requirements gathering approaches.
I agree with all of the above, Key point for me is the instant level setting between business and IT. Having the room speak Pega language of steps, stages and workflows in a matter of minutes is a game changer when designing new applications.
Great question and discussion! I use Blueprint really to create a common understanding with the business on what the solution should look like.
What works for me is especially:
Uploading supporting assets: Uploading requirement descriptions, forms and process diagrams gives me a great starting point, as I get a guided experience from there: I can discuss the workflow candidates, refine, go into workflow details then. The data extraction from the documents has gotten so much better with each release that I prefer this over uploading individual files later.
AI Assistant for “bulk” actions: I use the AI assistant especially when I want to perform multiple actions at once, e.g. creating multiple workflows / steps / fields (or editing / deleting them). This saves a lot of clicks and creates consistency, e.g. if I need to rename things in multiple places. It is also great for restructuring workflows, especially after the initial AI generation. What’s also great about it is that it generates descriptions / notes immediately, e.g. adding a Persona adds the persona description and asks me to which case types the persona should have access to. So using the AI Assistant makes the Blueprint more complete and higher quality from the beginning compared to configuring this manually (where I tend to leave things for later as it costs me more time).
Preview: The preview is usually where the business really understands what application we are creating (i.e. in contrast to seeing the Pega case design just as a different way of modeling processes with BPMN diagrams). I use this primarily for verification that what we modeled is what the business is actually looking for and to get a glimpse of what it could look like. At the same time, this is where I see the most potential for improvement for Blueprint going forward. If we can basically model the full user-experience upfront, the “build” part of the application could really be focused on just finishing the technical details, but the business has already approved the experience they will get in Blueprint.