DEV Community: Moises Griott

Human First ' AI Accelerated

Moises Griott — Mon, 15 Jun 2026 23:11:07 +0000

During the last year, I have been developing PoCs using AI tools such as Kiro, Codex... and other ADEs.

Like many devs, I started by focusing on the questions.

How to write better prompts, how to get better code, how to make AI generate more code?...

But after months of working this way, I realized something... the biggest challenge was not generating code, the biggest challenge was preserving intent.

As projects grow, architectures evolve, requirements change, and teams change, decisions made months ago begin to fade away!!!

The original vision becomes harder to perceive. Because AI does not know why a specific architecture was chosen, nor does it know why a particular cloud strategy was selected. AI only knows the context available during the current interaction.

Then we see this:

"AI does not follow the architecture, but the available context"

This creates a new challenge for software engineering today. The more capable AI becomes, the more important human intent or human solution vision becomes. Well... this is not less important, it is very important.

Because AI can generate solutions and accelerate delivery. But AI does not own the outcome, we do... architecture remains a human responsibility.

The software architect of the future will not compete with AI. The software architect of the future will govern it.

That is why I increasingly believe that we need to rethink AI-assisted development; prioritize human intent through governed context. etc. The real work is no longer just about writing code.

NOTE!!
The real work is about preserving the knowledge, decisions, architecture, and intent that guide the creation of that code

I am currently exploring these ideas through a methodology that I am calling Context-Driven AI Development (CDAD), focused on treating context as a governed architectural asset, rather than a collection of isolated prompts.

I am interested in knowing how others approach this challenge and whether they see it as a challenge as well...

Thanks for reading!

Griott

The Next Challenge in AI-Assisted Development Isn't Code Generation

Moises Griott — Sun, 14 Jun 2026 03:07:50 +0000

Over the past year, I've been developing intensively with AI, ADEs, and software agents, and I've become increasingly convinced that the main challenge is no longer generating code.

The real challenge is maintaining control over the architecture, design decisions, requirements, and context that guide AI throughout the entire development lifecycle.

Lately, I've been exploring how context governance, traceability, and continuous alignment between design and implementation can help build AI-assisted solutions in a more predictable and sustainable way.

What interests me most is how software engineering will evolve in this new era, where productivity is no longer the primary challenge, but rather the ability to maintain coherence, control, and quality as systems grow.

AI #AgenticAI #SoftwareArchitecture #SoftwareEngineering #GenAI #Architecture

When Context Doesn't Govern AI, AI Governs the Solution

Moises Griott — Thu, 11 Jun 2026 20:35:18 +0000

Over the last few months, I've spent a significant amount of time working with AI coding assistants, agentic IDEs, MCP-based architectures, and AI-assisted development workflows.

Like many engineers and architects, I was amazed by the speed.

Features that previously took days could be built in hours. Boilerplate disappeared. Documentation became easier. Prototypes emerged almost instantly.

At first, everything looked great.

We started with a clear architecture, defined principles, and a solid technical vision. The AI accelerated implementation and helped us move faster than ever before.

Then something interesting happened.

After dozens—or sometimes hundreds—of interactions, we began noticing subtle changes across the solution.

Individual changes looked reasonable.

The problem appeared only when we stepped back and looked at the system as a whole.

We found ourselves asking questions such as:

When did the architecture change?
Who decided this new approach?
Why is this module following a different pattern?
When did we stop following the original design?
How did the code become something I no longer fully control?

The reality was surprisingly simple.

The AI wasn't following a governed architecture.

It was responding to the partial context available at each interaction.

Every individual suggestion made sense.

Every individual optimization looked correct.

But over time, those local optimizations started creating architectural drift.

A component changed.

A pattern evolved.

A new abstraction appeared.

A different architectural style emerged.

No single decision seemed problematic.

Yet the overall solution gradually moved away from its original design.

The issue wasn't code generation.

The issue wasn't AI quality.

The issue was the absence of a strategy to govern the context that guides the AI.

Most discussions around AI-assisted development focus on prompts, models, agents, or coding tools.

Very few focus on what I now believe is the most important asset in an AI-driven project:

Context.

Architecture decisions.

Business rules.

Constraints.

Domain knowledge.

Design principles.

Technical standards.

All of these elements form the context that should guide the AI.

Without a governed context, the AI naturally optimizes based on whatever information is available in the current interaction.

And that is where the problem begins.

As I reflected on this challenge, I started thinking about a different approach.

What if we treated context as a first-class engineering asset?

What if architecture, principles, constraints, and domain knowledge became the primary source of truth?

What if AI systems were required to operate within a governed context instead of continuously redefining it?

These ideas eventually evolved into a framework I am currently exploring:

CDAD — Context-Driven AI Development

The core idea is simple:

The AI may suggest.
The AI may analyze.
The AI may accelerate.
But the AI should not redefine the architecture without explicit approval.

CDAD is built around several principles:

Context Engineering
Governance of Context
Context Protection Pattern (CPP)
Markdown-Driven Development
Agentic Development Environments (ADE)
AI-Assisted Delivery

The goal is not to limit AI.

The goal is to ensure that AI accelerates implementation without taking ownership of architectural decisions.

In this model:

Architecture lives in the context.
The context becomes the source of truth.
The AI operates on that context.
Humans remain responsible for the evolution of the solution.

This is still an evolving idea, but it has already changed how I approach AI-assisted development.

The biggest lesson so far is surprisingly simple:

When context doesn't govern AI, AI governs the solution.

And perhaps an even stronger statement:

Context is the new Source Code.

I'm curious to hear from other architects, engineers, and AI practitioners.

Have you experienced architectural drift while working with AI coding assistants or agentic development environments?

If so, how are you governing the context that guides your AI systems?

Building Agentic Architectures with AutoGen and Groq: Notes from My PoCs

Moises Griott — Tue, 09 Jun 2026 21:05:37 +0000

By Moisés Griott – Digital Architect | Cloud & Agentic AI

As a Digital Architect, most of my career has been focused on cloud platforms, distributed systems, microservices, and enterprise integration.

the last year, I have been exploring Agentic AI, Multi-Agent Systems, and MCP-related architectures. Instead of only reading about them, I decided to build several PoCs using AutoGen and Groq to understand their strengths and limitations in practice.

One of the questions that motivated these experiments was:

``Kubernetes solved container orchestration. Who will orchestrate AI agents?

Why AutoGen and Groq?

For my experiments, I wanted a solution that was simple to set up and allowed me to focus on architecture rather than infrastructure.

AutoGen provided an easy way to create specialized agents and coordinate conversations between them.

Groq offered low latency and a straightforward developer experience, making it ideal for rapid prototyping.

What I Built

My PoCs focused on a simple pattern:

Instead of having one agent responsible for everything, each agent had a specific responsibility:

Reasoning and analysis
Knowledge retrieval (RAG)
External actions such as notifications

This approach felt very familiar to someone coming from a microservices background.

Looking Ahead

The more I experiment with Agentic AI, the more I see similarities with the early days of microservices and cloud-native architectures.

The tools are evolving rapidly, but many architectural principles remain the same:

Separation of concerns
Scalability
Observability
Loose coupling
Clear responsibilities

I believe we are only beginning to discover the patterns that will define enterprise Agentic AI architectures in the coming years.

For now, the best way to learn is simple:

Build PoCs, experiment, and understand where these architectures create real value.

About the Author

Moisés Griott
Digital Architect | Cloud | Distributed Systems | Agentic AI

Currently exploring Multi-Agent Systems, MCP architectures, AutoGen, Groq, and the future of enterprise AI platforms.