Revisiting Pega in 2026: GenAI, Constellation, and Blueprint

A journal for 2026

I’ve been building Pega applications since 2010. It has been a long journey.

Over the past few weeks, I spent some time catching up through Pega's CSA, CSSA and CLSA courses. The experience was not tedious, and it was not deeply technical either. It was more of a reset: a way to understand what has changed, what has stayed the same, and where Pega seems to be heading now.

What made me seriously take a second look was Pega Launchpad.

Launchpad feels like an intentional move by Pega to create room for building applications for clients that are not quite in the Fortune 500 tier Pega has traditionally been known for. For years, Pega’s reputation has been tied to large enterprises, complex operations, and equally large price tags. Launchpad looks like an attempt to open another lane: one where partners and builders can deliver workflow-driven applications to mid-sized organizations with a more productized entry point.

At least, that is how it looks from the outside.

What still feels unclear is the pricing. Pega talks about charging by “outcomes,” and that raises more questions than it answers. What exactly counts as an outcome? A completed case? A business event? A customer transaction? It is the kind of term that sounds modern and attractive in a sales deck, but vague in practice. I filled out their contact sales form hoping for clarity. So far, nothing. Just silence.

Even so, the idea itself is interesting. It reminds me of how Pega has repeatedly tried to accelerate the early stages of application building.

Back in the 5.5 days, the Application Wizard helped lay down the application’s foundation: class structure, operators, rulesets, and the basic scaffolding. Over time, that idea evolved. From Pega Express to Blueprint, Pega kept pushing farther upstream, trying to define more of the application earlier and with more automation.

Today, Blueprint does much more than create a shell. It tries to infer flows, data structures, personas, case types, and user experiences from prompts and business requirements. That is a meaningful expansion compared to the old days. It is encouraging to see, even if it is not perfect.

Like most AI-assisted generation tools, Blueprint appears to generate what it thinks best fits the requirements. How reliable that is remains something of a black box. It can also update flows through chat, but from what I have seen, that capability still feels limited. Helpful, yes. Fully trustworthy without review, no.

It also feels like Pega wants to keep more of its accumulated implementation “wisdom” inside its own ecosystem. Blueprint is not just a helper feature. It increasingly looks like a strategic front door to the platform.

On the UI side, Constellation is clearly the present and future. “Legacy” UI is now exactly that, and Cosmos sits in the middle as a kind of transitional generation. A friend joked that we are dinosaurs now if we still think in the older Pega UI paradigms. There is probably some truth to that.

My opinion here may be polarizing, but I think it is fair.

Pega’s UI has never really been its strongest point. It has always been more about process, orchestration, and enterprise behavior than interface elegance. Cosmos felt like a familiar upgrade. It expanded UI features, events, and controls in a way that still felt natural to experienced Pega developers.

Constellation is different. It comes from a more prescriptive, data-model-first philosophy. In that sense, it is a more mature and opinionated framework. I can see why Pega went in that direction. But coming from Cosmos, it can also feel constrained. Sometimes it feels less like a step forward in flexibility and more like a trade-off: consistency and speed in exchange for freedom and control.

Security also seems more developed now. The two additions that stood out to me were CBAC and BAC.

• CBAC (Client-Based Access Control) appears to be aimed at privacy-oriented handling of personal data, helping address regulations and compliance requirements that used to require a lot of custom implementation.
• BAC (Basic Access Control) is focused on protecting against unauthorized requests coming from the UI layer, including sections, controls, and harnesses. In plain terms, it is there to help prevent broken access control issues where users try to bypass the intended experience through crafted requests or URLs.

That part stood out to me because it addresses real pain that teams used to solve the hard way.