DEV Community: Matheus Pereira

Breaking the Black Box Without Sacrificing Performance

Matheus Pereira — Mon, 09 Feb 2026 18:27:23 +0000

Deep learning has a transparency problem.

Modern neural networks achieve impressive results across vision, language, and decision-making tasks, yet they often fail at answering a basic question: why was this decision made? This opacity limits trust, auditability, and adoption in real-world, high-stakes systems.

Over the years, the community has explored two main directions. On one side, highly accurate black-box models with post-hoc explanations. On the other, fully interpretable models that attempt to force reasoning into human-defined concepts often at the cost of performance.

Both approaches have limitations.

This tension motivated a question that guided my recent work:

Is it possible to constrain deep learning models for interpretability without destroying their expressive power?

The Problem With Forcing Interpretability Everywhere

Concept-based approaches, such as Concept Bottleneck Models, enforce predictions through human-interpretable concepts. When successful, they provide clear and intuitive explanations. However, they also assume that all relevant information can be expressed using predefined concepts.

In practice, this assumption rarely holds.

Many discriminative features textures, subtle shapes, spatial correlations do not map cleanly to human language. Forcing all information through concepts often leads to excessive compression and, consequently, a significant drop in predictive accuracy.

The issue is not interpretability itself, but where and how it is enforced.

A Hybrid Perspective

Instead of trying to eliminate the black box, I explored a different approach:
make it explicit, bounded, and structurally separated from what we can explain.

This idea led to HGC-Net (Hybrid Guided Concept Network).

The core design principle is simple:

Part of the model is trained to represent human-defined, interpretable concepts
Another part remains unconstrained, capturing residual information necessary for performance
The final prediction uses both components
Interpretability is enforced selectively, not globally.

What This Enables

This architectural separation leads to an important behavioral shift:

When a human-defined concept applies, the model exposes it clearly
When no known concept applies, the model does not fabricate explanations
Performance remains close to a standard convolutional baseline

In qualitative analyses, this distinction becomes explicit. Some predictions are fully explainable through concepts. Others are correct but rely on latent representations, with the model being honest about the absence of a semantic explanation.

Rather than pretending to be fully interpretable, the system makes the limits of interpretability visible.

Why This Matters

Interpretability should not mean oversimplification.

Forcing explanations where none exist can be just as misleading as offering no explanation at all. A model that acknowledges the boundary between what is explainable and what remains latent is often more trustworthy than one that claims total transparency.

HGC-Net treats interpretability as a structural property, not a post-hoc add-on. By deciding where semantic constraints belong, we can preserve both accountability and performance.

Read the Full Paper

The complete technical details, experiments, and qualitative analyses are available in the full preprint:

Zenodo (DOI): click here

The paper includes:

the full architectural formulation
quantitative comparisons with baselines
qualitative examples of instance-level explanations
links to executable experiments

Closing Thoughts

Breaking the black box does not require eliminating it.

Sometimes, the most honest solution is to draw clear boundaries, explain what can be explained, and explicitly expose what cannot. Hybrid semantic bottlenecks offer one possible path in that direction, and this work is an ongoing exploration of how far that idea can go.

If you’re interested in interpretability, concept-based learning, or trustworthy AI, I’d be glad to hear your thoughts.

Legacy-First Design (LFD): Designing Software That Still Makes Sense Over Time

Matheus Pereira — Sun, 11 Jan 2026 16:58:51 +0000

Most software architecture discussions focus on how to change faster:
how to refactor safely, adopt new technologies, or evolve systems continuously.

Much less attention is given to a different, and uncomfortable, question:

What happens when change slows down… or stops entirely?

In practice, many long-lived software systems do not fail because of performance or scalability issues. They fail because, over time, they lose conceptual coherence. Business rules leak into infrastructure, architectural decisions become irreversible, and eventually the system is rewritten rather than understood.

This post introduces Legacy-First Design (LFD), a conceptual architectural methodology that treats time as a first-class constraint rather than an implicit assumption.
What is Legacy-First Design?

Legacy-First Design (LFD) is not a framework, language, or architectural pattern.

It operates at the architectural decision level, asking architects and engineers to explicitly distinguish between what must endure and what may change over time.

Instead of optimizing primarily for short-term delivery or technological convenience, LFD prioritizes:

preservation of system identity
resistance to technological obsolescence
long-term conceptual clarity
survivability beyond active maintenance

At its core, LFD reframes the architectural question from:

“How should we structure software to evolve faster?”

to:

“What must remain valid even when evolution stops?”
Survival in Abandoned State

One of the central ideas proposed by LFD is Survival in Abandoned State.

Most architectural approaches implicitly assume continuous maintenance. LFD does not.

It treats prolonged absence of maintenance as a predictable phase of the software lifecycle, not an exceptional failure. Under this perspective, a system that collapses conceptually when abandoned has failed architecturally — even if it once worked correctly.

Designing for survival in abandoned state means building systems that:
remain understandable without their original creators
preserve core business meaning
continue to make sense even after long periods of inactivity How does LFD relate to existing approaches?

Legacy-First Design does not attempt to replace approaches such as Clean Architecture, Domain-Driven Design, or Hexagonal Architecture.

Instead, it introduces a temporal governance layer that these approaches often leave implicit.

LFD is less concerned with how a system is structured and more concerned with what is allowed to change over time — and what must be protected from change.
The paper

The complete, canonical definition of Legacy-First Design (LFD) is presented in a short technical paper:

📄 Legacy-First Design (LFD): A Temporal Approach to Software Sustainability
👉 PAPER Zenodo

The paper explicitly positions LFD as a conceptual and normative methodology, discusses its relationship with existing architectural approaches, and acknowledges its limitations.

It is intentionally concise and meant to provoke discussion rather than prescribe implementation details.
Why this perspective matters

Software systems rarely fail because of a single bad decision.
They fail because of accumulated decisions that did not account for time.

Legacy-First Design does not promise to eliminate complexity or conflict. It proposes something more demanding:

Designing systems that remain coherent when time does its work.

If you are working with long-lived systems, legacy codebases, or architectural sustainability, this perspective may be worth exploring.

Is the Monolith Dead? Introducing MQ-AGI: A Modular, Neuro-Symbolic Architecture for Scalable AI

Matheus Pereira — Thu, 20 Nov 2025 23:56:47 +0000

The "Wall" of Monolithic LLMs
We all love GPT-4 and Claude. They are marvels of engineering. But if you've tried to build complex, long-term applications with them, you've hit the wall:

Amnesia: The context window is a band-aid, not a memory.
Black Box: You can't debug why it hallucinated.
Inefficiency: Asking a 1T parameter model to do simple arithmetic is like using a flamethrower to light a candle.

I believe the next step in AI isn't just "bigger models", but better architecture.
For the past few months, I've been working on a blueprint to solve these bottlenecks. Today, I'm releasing the preprint of MQ-AGI (Modular Quantum-Orchestrated Artificial General Intelligence).

What is MQ-AGI?
MQ-AGI is a conceptual framework that moves away from the single giant neural network. Instead, it proposes an "Orchestrated Brain" topology inspired by cognitive science (Global Workspace Theory).
It breaks down the monolith into specialized components coordinated by a central core. Think of it as Microservices for Intelligence.
Here is the high-level topology:

The 4 Core Components

1. Domain Expert Networks (DENs) - "System 1"
Instead of one model that tries to know Physics, Law, and Cooking all at once (and gets confused), MQ-AGI uses specialized, independent networks.

Dev Benefit: You can update the Python Expert without breaking the History Expert. No catastrophic forgetting.

2. Global Integrator Network (GIN) - "System 2"
This is the orchestrator. It acts like the Prefrontal Cortex. It receives inputs from the experts, resolves conflicts (e.g., Safety vs. Efficiency), and maintains the train of thought.

It solves the Binding Problem: fusing disparate data types into a coherent concept.

3. Quantum-Inspired Core (The Routing Engine)
This is the heavy engineering part. How do you route a prompt to the perfect combination of 5 experts out of 1,000?Using a standard classifier is O(N). Finding the optimal coalition is a combinatorial nightmare.MQ-AGI models this as a Hamiltonian Energy Minimization problem. We use physics-inspired algorithms (Tensor Networks) to find the "Ground State" (lowest energy/conflict) path.

Note: This runs on GPUs today (via simulation) but is ready for future QPU hardware.

4. DREAM Memory Protocol
An AGI needs to remember you. MQ-AGI integrates DREAM (my previous work on episodic memory).

It replaces the raw "context window" with a Self-Pruning Vector Store.
Adaptive TTL: Memories that you access often live longer. Useless noise is deleted.
Dual Output: The system generates a user response AND an internal memory summary in parallel.

Why Open Source this Blueprint?
I believe we need more architectural diversity in AI research. We cannot leave the future of AGI solely in the hands of closed labs building bigger monoliths.

I have released the full technical paper, including:

The mathematical formalization (Hamiltonians, Free Energy Principle).
Critical feasibility analysis (addressing QRAM and latency bottlenecks).
Implementation roadmap.

It is available as an Open Access Preprint on Zenodo.

Links & Resources
Read the Full Paper (PDF):MQ-AGI on Zenodo
Read about the Memory Protocol: DREAM on Zenodo

I’d love to hear your thoughts on the Orchestrator Topology. Do you think modularity is the key to System 2 reasoning? Let's discuss in the comments!