DEV Community: Marcos Cruz

What would a world look like where developers have been replaced by AI?

Marcos Cruz — Thu, 24 Sep 2026 05:05:43 +0000

Lately, we keep hearing in mainstream media about AI models so powerful that they will replace developers. Those of us who are well-informed know this is largely a marketing tactic to fuel the hype around AI and attract investment into the technology. But have you ever stopped to think about what this would actually mean?

What would a world really look like where 100% of developers’ work is replaced by AI agents?

As Plato would say, “Let us examine (Episkepsómetha).”

Let’s start by examining why companies have developers in the first place. There are many reasons (such as security, maintenance, etc.), but let’s focus on the two clearest cases:

Because it is a software company (such as a SaaS business)
Because it is another type of company that wants to automate or improve efficiency in its internal processes

To simplify, let’s focus only on the second case.

What would it mean to live in a world where 100% of your developers’ work is covered by AI? In other words, a world where every non-software company has access to an unlimited army of developers.

Before we continue, let’s be explicit about something: this is a strong and extreme hypothesis. We are deliberately pushing the idea to its limit, not because it is the most likely outcome, but because it helps us clearly visualize the implications of such a world.

If we fully embrace this extreme scenario, unlimited development capacity would imply the ability to automate virtually everything. All processes within a company could be automated and optimized for efficiency: payroll, billing, customer support, internal operations… even highly complex workflows.

Companies would have such brute-force capability that nothing would realistically escape automation. In that sense, a world with unlimited development power—a world without developers—would also imply a world where finance teams, customer support, operations, and even parts of management as we know them today would largely disappear or be radically transformed.

This leads to an interesting conclusion: developers can, to some extent, feel reassured. If such a scenario were ever to happen, their role would likely be among the last to be fully automated.

However, "With great power comes great responsibility". The role of developers is already changing—and will continue to change profoundly. Developers are gradually shifting from being pure coders to becoming orchestrators of AI-driven systems: designing workflows, coordinating agents, validating outputs, and ensuring that systems behave as intended.

With this change of paradigm, if an engineer wants to remain relevant, it will not be enough to simply write code. They will need to: Understand how to validate AI-generated outputs critically, develop expertise that combines technical knowledge with business domain understanding, learn how to design, guide, and supervise AI systems effectively, etc.

Finally, it is important to come back to reality. Everything described above represents an extreme scenario, a thought experiment. We are not necessarily heading toward a world where everything is fully automated. Instead, what we are already starting to see is more interesting: Developers will become significantly more productive and teams will become smaller but more impactful.

In fact, the Spanish job market already reflects this trend. In early 2026, developer job openings have increased, with leading employment platforms reporting a growth of 25% compared to the end of 2025.

So rather than disappearing, developers will evolve. They will not be replaced, they will be amplified. And those who learn how to work with AI, rather than against it, will be the ones who shape what comes next.

Dev Multi-Agents are worth?

Marcos Cruz — Wed, 16 Sep 2026 05:48:15 +0000

Lately, I’ve been experimenting with OpenCode and reading up on multi-agent development architectures. However, both my own tests and the demos I’ve seen leave me wondering about their real value.

The big promise of these architectures (using an orchestrator alongside specialized sub-agents) is minimizing or even completely eliminating human intervention. While the potential is there, the cost seems too high. In my tests, relatively simple requirements consistently resulted in massive Pull Requests costing upwards of €40 to €50 each.

A common pattern in these setups is essentially replicating a full human team virtually: sub-agents acting as Project Manager, Technical Product Owner, UI/UX designer, Architect, Developer, QA, and so on. While this allows for very smart context management, copying human team structures probably isn't optimal for AI, and the financial cost is huge.
Given this, I struggle to see a clear advantage over simpler approaches, such as using a single solid coding agent selected according to the task, or maybe two agents using an adversarial pattern (like builder and reviewer).

What has your experience been? Do you think we’re over-engineering things?

Is AI Making Us Slower?

Marcos Cruz — Tue, 08 Sep 2026 11:09:15 +0000

It feels like the industry’s new mantra isn't building software anymore, but manufacturing "application factories." As engineers, we have to ask ourselves: are we actually optimizing delivery, or are we just playing with a new tool? (Because let's be honest, raise your hand if you’re guilty of this. I’ll be the first.)

Over the past few weeks, I’ve seen numerous posts discussing the paper "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity." The study presents a striking paradox: while developers perceived a 20% boost in their performance, the empirical data revealed they actually took 19% longer to resolve issues when using AI.

It’s worth highlighting (as the title of the study suggests) that this study focused exclusively on senior engineers. The nearly 40-point gap between perception and reality might simply come down to intuition and deep experience. A seasoned expert often knows which variable to tweak in under a minute. Working with AI, by contrast, requires opening the tool, crafting prompts, waiting for the MCP to index files, and letting it process the context. This leads to the surprising finding that senior developers took 19% longer to close issues when AI tools were part of their workflow.

Naturally, these findings aren't conclusive, the sample size was limited to just 16 developers, which is quite small. Still, it sparks a necessary conversation:

Does this productivity gain actually exist for staff-level and principal engineers, or is AI far more effective for mid-level developers?
How do you explain this massive gap between perceived efficiency and actual output?
How much weight do you give to studies like this in your day-to-day workflow?

I’d love to hear your take in the comments.

Beyond the Hype: 4 Agentic Design Patterns Every Dev and PM Needs to Know

Marcos Cruz — Wed, 26 Aug 2026 17:00:53 +0000

The current AI landscape is thick with "smoke." Between infinite buzzwords and thousands of AI posts and infographics, it is becoming increasingly difficult to discern what is actually a new architectural breakthrough versus what is just marketing noise.

With that in mind, here is a breakdown of the 4 core AI design patterns for development:

1. The Pipeline (Prompt Chaining)

The Pipeline is the foundational pattern of AI Engineering. It treats tasks as a linear sequence of specialized nodes, where the output of one instance becomes the structured input for the next. This provides much-needed granularity to the development process.

A classic example of this is Spec-Driven Development. Rather than asking an AI to "build an app," we chain specialized instances together:

Design Node: Establishes the initial concept and architecture.
Specification Node: Translates design into technical requirements.
Task Definition Node: Breaks the spec into actionable tickets.
Development Node: Executes the code based on the tasks.
Review Node: Evaluates the final output against the original design.

In a content pipeline, you might have a technical writer agent generate a draft and a marketing-specialized agent generate a high-engagement title. By separating these into nodes, you can swap out models to match the task—using a high-reasoning model for the spec and a faster, more creative model for the title.

2. The Router (The Decision Maker)

As your system scales, linear flows become too rigid. The Router pattern introduces branched logic, where a "gatekeeper" analyzes the input query and directs it to the most appropriate specialized worker.

In a customer support context, a Router determines whether a query belongs to Billing, Technical Support, or Returns. You can implement this via:

LLM-based Classification: A model categorizes the intent. This is highly flexible but incurs token costs and latency.
Embeddings-based Similarity: The query is converted into a vector and compared against department-specific clusters. This is fast and cost-efficient.

Pro-Tip for Architects: Always implement a Human-in-the-Loop fallback. If the Router’s confidence threshold falls below a set level (e.g., 70%), the system should automatically route the ticket to a human agent. This ensures production reliability even when the model is uncertain.

3. Planner-Executor (The Orchestrator)

The Planner-Executor pattern brings the "Brain and Workers" dynamic to life. This is the preferred pattern for open-ended tasks where the steps to a solution are not known upfront.

The Planner: Acts as the high-level architect (using a powerful model like Claude 3.5 Sonnet). It defines a multi-step plan but does not execute.
The Executors: Specialized workers (often smaller, cheaper models) that carry out the specific steps.

This is best visualized as a Diamond Diagram:

Initial Prompt: The task enters the system.
Fan-out: The system parallelizes multiple tasks at once across different workers to save time.
Fan-in: A final agent performs a synthesis step to merge diverse outputs into a cohesive result.

This tiering of models—expensive for planning, cheap for execution—is the key to building cost-effective, scalable agentic systems.

4. Evaluator-Optimizer (The Adversarial Loop)

To achieve high-quality results, you need an Adversarial Loop. This pattern pits two agents against each other: a Generator and a Critic.

The Critic evaluates the Generator's output against a specific rubric (e.g., "Must be under 30 words," "Avoid vague adjectives"). For example, if the Generator describes a backpack as "good and useful," the Critic rejects it for vagueness and demands specific functional benefits.

The key technical nuance here is the Conservation of Work. In a well-designed loop, the Optimizer is instructed to fix only the specific failures identified by the Critic while preserving everything that already works. This "delta-only" improvement prevents the model from introducing new hallucinations or errors while iterating. This loop-driven refinement consistently outperforms any single-shot prompt, no matter how well-crafted.

Key Takeaways

Agentic Design Patterns represent a fundamental shift in software architecture. We are moving away from monolithic, unmanageable prompts toward semantic separation—the art of organizing modular, maintainable agent logic.

As an Engineer (or AI Engineer, or Agent Architect), your primary value is no longer just writing code; it lies in context engineering and the strategic orchestration of these patterns to simulate reasoning. The more you modularize your logic, the easier it becomes to debug, scale, and optimize.
Is your AI architecture a single-shot "black box," or a structured agentic workflow?

Harness Engineering? Loop Engineering?

Marcos Cruz — Mon, 10 Aug 2026 10:23:12 +0000

In the world of AI, a new concept appears every week. It's nonstop! The reality is that we're constantly bombarded with new technical words, sometimes a repackaged concept and idea with a new, viral name. Many of these concepts even become outdated or are renamed within few weeks.

How do you avoid getting frustrated along the way? The key is not to blindly follow the hype, but to understand what's behind it.

Two terms that have generated the most confusion lately are Harness Engineering and Loop Engineering.

Here's an explanation of their meanings:

Harness Engineering (The tools): This involves preparing the entire ecosystem that an artificial intelligence agent needs to perform its job.
In other words, it's when you implement skills, tools, and connections (like MCPs) for the AI so it can interact with your system.
Loop Engineering (The automation): This refers to the orchestration and design of workflows (loops). Instead of working in the traditional way by typing a prompt in a chat for the AI to do something on a one-off basis (what's called an "open loop"), you design a cycle where the AI acts automatically in response to certain events.
A practical example: Imagine you configure a loop where, if a system detects an error in your code, an AI agent is automatically triggered, analyzes the error, writes a test, fixes it, and sends you the proposed change ready for review.

Hope it helps to clarify! Cheers!