A lot of people ask me what is the difference between approaching a Greenfield project versus a Brownfield project when working with AI agents, Cursor, Cloud Code, or any of these modern AI-driven development workflows.
And honestly, the more I work with these systems, the more I realize that both are fundamentally the same problem.
At the end of the day, both require exactly the same thing: instructions, guidelines, and context.
That realization completely changed the way I approach AI-assisted development. Because once you remove all the hype, all the fancy terminology, all the discussions about models, IDEs, MCPs, RAG systems, and frameworks, what remains is actually a very simple communication problem. How do we communicate clearly enough so the AI can operate within the boundaries we actually want?
The best mental model I’ve found so far is pretending AI is simply another human working with you. A very smart human. Extremely fast. Capable of processing absurd amounts of information. But still another collaborator.
Imagine you come to me and say, “Josue, I need a new web application.” Immediately I would start asking questions. What does your company do? What are you selling? What stack are we using? What are the security requirements? What branding do you have? What are we trying to communicate? What constraints do we have?
Because even if I am very good at architecture or system design, I still need context. Otherwise I am just guessing.
The difference is that humans usually challenge ambiguity, while AI usually resolves ambiguity. That distinction changes everything.
To address this I've seen a lot of people today obsessed with prompt engineering. Personally, I don’t think prompt engineering is the real solution. If you think about it, one of the biggest problems humanity has had for decades is communication itself.
Countries fail because of communication. Relationships fail because of communication. Teams fail because of communication. Families fail because of communication. So how do we suddenly expect that by following some “prompt engineering tricks,” we magically become amazing communicators with AI?
That’s unrealistic.
This is not really about prompt engineering.
This is about structured communication. That is the real skill.
And understanding how models actually work changes your entire perspective on this. Models do not understand truth the way humans do.
Models understand probabilities. Internally, these systems are trying to predict what token most likely follows the previous sequence of tokens. That’s fundamentally what is happening under the hood.
So if a model was trained on incomplete, biased, outdated, or incorrect data, its outputs will reflect that. The model itself is not validating truth. It is predicting likelihood.
That is also why hallucinations happen.
Personally, I believe that modern hallucinations are mostly a user problem. One year ago, hallucinations were more related to model limitations. But modern frontier models are extremely capable. Most hallucinations today happen because context is incomplete, requirements are ambiguous, architecture decisions are missing, or constraints were never defined properly.
The model is simply filling the gaps because that is exactly what it was designed to do.
Another huge misunderstanding I constantly see is people believing that bigger context automatically means better outputs.
That is not true at all. Better context is more important than bigger context.
Let’s go back to the human analogy again. If you hand me a 500-page book and immediately ask me what was written on page 221, line 23, I probably will not know. Not because I’m bad, but because humans have cognitive limits.
Models have limits too.
If your context is contradictory, duplicated, noisy, disorganized, or low quality, the output quality degrades even if the context itself is huge.
And this is where things become very interesting when we bring Greenfield and Brownfield projects back into the conversation.
Because from my perspective, there is no massive distinction between both approaches anymore when working with AI agents.
Thre real game changer
In Greenfield projects, you usually do not have standards yet. You do not have ADRs. You do not have architecture definitions. You do not have coding standards. So the first thing you need to do is define the rules of the game. Define the stack. Define the architecture principles. Define the patterns. Define the expectations. Define the governance.
But in Brownfield projects, even though the system already exists, the problem is usually the same. Most legacy systems do not have enough documentation, enough architectural clarity, enough standards, or enough explicit knowledge for AI agents to operate safely and consistently.
Extract the architecture decisions. Generate documentation. Define standards. Define workflows. Organize the knowledge in a way that agents can consume effectively.
That is why I no longer see Greenfield and Brownfield as fundamentally different AI problems. Both are context engineering problems.
And this is also why I personally do not obsess too much over whether somebody uses Cursor, Cloud Code, Claude Code, skills, MCPs, or custom workflows. Because all of these are simply different mechanisms for delivering context to the model.
Cursor internally uses retrieval systems, indexing, grep strategies, embeddings, and context loading mechanisms. It is already doing RAG behind the scenes for you. The important question is not “which tool is better?” The important question is “how effectively does this workflow provide structured context to the model?”
That changes the conversation completely.
Personally, my architect mindset also makes me very careful with vendor lock-in. I do not like workflows that fully depend on a single provider or a single tool. Because if one provider goes down tomorrow, I still need to deliver value to my clients. Clients do not care if Anthropic had an outage or if some AI platform became unavailable for a day. They care about results.
That is why I’ve been spending a lot of time experimenting with custom CLIs, reusable workflows, provider-agnostic standards, and portable governance models.
Because ultimately, the tooling itself is secondary.
What really matters is how effectively we structure communication between humans and AI systems.
And honestly, I believe that is where the industry is heading.
Not toward better prompts.
Toward better systems of communication. That is the real game changer.
Of course, first between humans and humans, but then between humans and AI systems.