How an Architect Drives Innovation Through Experimentation

It started with a simple question:

How can we, as architects, make our teams faster—not by pushing harder, but by learning in a smarter way?

At Prosigliere, we like to think of architecture not as a gatekeeper, but as an enabler. My role as architect has never been about having all the answers—it’s about helping others find them faster. Over the past few months, I’ve been leading our Architecture Cohort, a cross-team group created to share knowledge, align technical direction, and explore how emerging tools—especially AI—can help us deliver more value with less friction.

We come from different products, stacks, and business contexts, but share one common goal: to make engineering more effective across the organization. Every two weeks, we meet to discuss architectural topics that impact everyone—from delivery speed to data integrity, scalability, and developer experience.

The Architecture Cohort: Building Shared Understanding

The Architecture Cohort grew out of a simple realization: every team has deep knowledge, but that knowledge often stays local. We needed a place to bring those insights together and look at architecture as a living system, not a fixed diagram.

Our sessions happen every two weeks, and each one focuses on a core architectural theme. We’ve already discussed topics like how to decompose a monolith into microservices, strategies for maintaining data integrity across distributed systems, caching layers and invalidation patterns, and how to balance scalability with simplicity; ****and even the cultural aspects of technical decision-making—how teams can align on architecture without losing autonomy. We will also cover topics like resource provisioning, deployment automation, video delivery scaling and many others.

Sometimes these sessions take the form of short presentations, sometimes open debates, or guided frameworks that help teams analyze trade-offs together. The format changes, but the principle stays the same: to create a shared mental model of what “good architecture” means inside Prosigliere.

It’s still early days. We’re experimenting with how to document the learnings and how to make them accessible to every engineer. What matters most is participation—turning architecture from a solitary discipline into a collaborative one.

My job as this effort leader isn’t to decide what’s right—it’s to facilitate, document patterns as they emerge, and connect people who can learn from one another. The goal is clear: build governance through shared understanding, not through rigid control.

Experimentation as a Method

When I took on the cohort, I wanted it to be more than a discussion group. It had to be a lab—a place where we test assumptions, share failures, and surface patterns worth adopting.

So I began experimenting with AI tools—not just to play with them, but to understand where they fit in our actual workflows. The market is flooded with promise: GitHub Copilot, Cursor, JetBrains AI, Claude, DiffBlue, Devin, and others all claim to make developers more productive. But we needed evidence, not marketing.

I approached it systematically. For each tool, I looked at context awareness, integration quality, and how it handles complex, real-world repos. With ChatGPT, I developed requirements and crafted prompts for concrete tasks; then I passed those prompts into tools like Devin or Cursor to see how well they could execute.

I extracted patterns, coding styles, and reusable snippets from past projects and fed them into Devin’s knowledge base—essentially training it with our way of building things.

The process looked like this:

1. Define the requirement with ChatGPT’s help.

2. Feed that context and code structure into Devin.

3. Let Devin create a new branch and implement the feature autonomously.

4. Review the code manually, fixing or improving it with Windsurf or Cursor.

Devin: The AI Tool That Deserves Its Own Page

Among all the tools I’ve tested, Devin deserves special mention. It’s not just another AI pair programmer; it’s a new paradigm. Devin works at the branch level, not the line level—it can spin up a repo, make commits, and even manage its own tasks.

But that power also requires discipline. Devin is most effective when guided by precise, well-structured prompts. That’s where ChatGPT became essential: together, they form a workflow where I can define what needs to be done (ChatGPT) and have it executed (Devin).

It’s not perfect—Devin still struggles with large multi-repo setups and complex dependency graphs—but its potential is enormous. Used correctly, it can reduce boilerplate, accelerate prototyping, and help teams focus on higher-order problems rather than repetitive code.

Experimenting with Devin taught me something important: AI tools don’t replace engineering judgment—they amplify it. The better the context, architecture, and processes behind them, the more useful they become.

Expanding the Perspective: Cloud, Certification, and Continuous Learning

Parallel to these experiments, I’ve been working on my Azure Cloud Solutions Architect certification. It’s been more than a personal goal—it’s also a way to bring structured, enterprise-grade cloud knowledge back into the cohort.

Learning Azure’s governance, identity, and scaling models helps me frame our architecture discussions around real cloud design constraints—like multi-tenant isolation, cost optimization, and global availability.

The certification has also reinforced a principle that runs through all our work: architecture isn’t static. It’s an evolving body of knowledge that grows stronger when shared, challenged, and tested.

Quality Through Governance, Speed Through Shared Knowledge

If there’s one takeaway from this period, it’s that quality scales through governance, and velocity scales through collaboration.

By documenting best practices, evaluating tools systematically, and keeping architectural discussions open, we’ve built a culture where everyone can contribute to better engineering decisions.

And in that sense, my role as architect isn’t to be the expert in the room—it’s to make sure expertise flows through the room.

When a developer from another team asks a tough question, my goal isn’t to answer it myself, but to find the right person in our network who can. That’s how we stay lean, fast, and connected.

The real power is not in any single architect or AI—it’s in the ecosystem we’re building together. The stronger our connections, the faster our ideas move from concept to production.

Strength in Numbers

At Prosigliere, experimentation isn’t a side project—it’s how we grow. Whether it’s testing AI assistants, refining our delivery pipelines, or improving cloud governance, every experiment adds a new piece to the puzzle.

As I look ahead, the challenge is to keep that momentum—to continue experimenting, documenting, and sharing so that innovation remains a collective habit, not an individual effort.

The strength, as always, is in the numbers.