The gains aren’t about speed alone; they’re about where human energy goes.

To me, the real productivity gain using AI tools comes from the ability to optimize our work, not from doing more for the sake of doing more. We need to improve our work, and the positive collateral effect will be more productive

Models become better over time, and several concepts we learned months ago become less important today. And, this came as the result of weeks of personal experimentation, study, and knowledge sharing with people.

After a while of following these principles, I believe that I was able to extract much more potential from AI tools than before.

The Three Principles

Don’t try to control the AI.
The instinct when using AI is to spend 15–20 minutes crafting an instruction that tells it exactly what to do — as if correcting someone who is learning. The first shift is dropping that instinct.

Give it problems, not tasks.
Using AI “as an intern” — “make this class do X” — undersells it and overloads you. The mental model that unlocked productivity is to describe the business problem and let it decompose. Give the agent access to the stuff that matters, and the agent decides what to read, what to change, and what to test.

Extended brain, not outsourced brain.
AI can’t read your mind. Context is the activation energy. You have to tell it what the problem is, where to find things, and what constraints matter. Once that’s in, you’re genuinely co-thinking, not just delegating.

Setup Pays Off Compounding Returns

Spend some time on your setup (MCP, skills, connectors, context files), or even more, ask the agent how to configure it. The setup pays for itself in the first session.

The common pattern I’ve seen is to use AI within a single repository, in a single context, one file at a time. Don’t build this setup from scratch; it is hard, craftsman work.

Plan Mode Is Not Optional

Plan mode forces a reviewable artifact before any token is spent on possible wrong code. Spend as long as it takes to produce and refine the plan. This will save the same amount of time in mid-execution corrections. The prompt-to-execution handoff works better when you’ve spent time getting the plan right, not when you’ve rushed to give the AI a broad goal and hoped it would figure out the rest.

Code is cheaper

The cost of producing correct, tested code has dropped. What hasn’t dropped is the cost of knowing what to build and who to align with. All required human judgment.

With that team’s energy, optimally, going into decision-making, context-building, and review, not line-by-line implementation.

Good architecture it's a set of decisions over time

No matter how good it is (today), it will change over time, based on several variables we can’t fully control, like leadership change, the experience gathered, technology evolution, problems to be solved, growth, performance, cost, etc…

Over the past years, I realized that good architecture needs to be flexible and adaptable. To achieve this it should be simple enough to be boring. Concepts are important, but don’t tighten too much to then, mainly because they will make the architecture unflexible, pay attention to the core of concepts and the problem to be solved, not to the system design or technologies.

Here are some aspects that can change how good an architecture is over time…

The Conway's Law

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure” — Melvin Conway

Conway's Law implies that as an organization evolves through leadership changes, team restructuring, or shifts in communication strategies, the same happens with the architecture of its systems, which will reflect the changing communication patterns and decision-making processes within the organization.

Consequently, what is considered a 'good' architecture today might not align with tomorrow's “new” organizational structure since this is influenced by how we communicate with each other.

As teams grow, new skills, perspectives, and capacities come together with the new hire individuals and change how some problems are approached and solved, raising new opportunities or efficiencies that weren't clear before. So, an architecture that was working before may need to be re-evaluated to accommodate the new capabilities of a larger team.

Standards & Patterns

An effective architectural strategy must balance these specific goals overarching goals of the project or organization. Standards and patterns aim to reduce the risk of introducing unnecessary complexity, as these standards often encapsulate the collective wisdom and experiences of the broader community.

The reality is that, nowadays, there are at least 46 different patterns — don't forget Anti-patterns — that aim to offer a way to build reusable solutions to common problems.

It's almost impossible to remember all these patterns, so we tend to talk more about the most recent and popular, and it’s common to try to fit a pattern into a problem not the other way around.

Microservice1 is a good example, over the years it has become the default answer to almost all architecture scalability issues, but microservices try to solve an organizational problem2, reducing teams’ dependency and improving velocity by the cost of introducing a significant amount of complexity to manage multiple services, their deployment, testing, monitoring, and managing dependencies between services.

Accidental Complety

The Accidental Complexity anti-pattern happens when we introduce non-essential complexity into a problem. - Mark Richards3

This often happens due to a lack of understanding of the problem, poor communication, or misalignment between the system design and business needs, an architecture should minimize non-essential complexity by focusing on the problem that needs to be solved and aligning the system design with the business objectives.

Relying on a one-size-fits-all architecture can lead to inefficiencies and inadequacies in addressing specific challenges. An architecture tailored to a specific problem needs to be flexible, allowing components to be added, removed, or modified as the understanding of the problem evolves or as new requirements surge.

Conclusion

Legacy is just a decision made in the past with or without your participation

Problems evolve, influenced by changes in technology, market demands, organizational structure, and other external factors. This means designing systems that are modular, flexible, and capable of integrating new technologies or methodologies as they emerge is hard.

Everybody has some good or bad experience with some (even the same) architecture or technology, every time you build a new shiny design, a new legacy is also built. So every time you face this scenario try to answer the following questions:

• What's problem(s) will be solved?

• What's the ROI of the proposal?

• Who owns the actual (legacy) architecture?

• How can the actual architecture be changed? How easy is it to do?

• What can be done with the time and people if the new architecture isn’t implemented?

With the above questions answered start building.

References

• The Cult of Best Practice

• THE FRUGAL ARCHITECT

• Domain Driven Design

• Conway's Law

No Degree Engineer is a dedicated space where I'll share my personal experiences, where I aim to share the insights and lessons I've gathered over the years about creating and managing large-scale, resilient, and efficient tech infrastructures and, what I learned building, organizing, and leading tech teams.

On Substack, I aim to write more frequently (I'll try monthly), using a newsletter format to bring these experiences.

Why No Degree Engineer?

My career path has been unconventional. Rising to a senior leadership position in the tech industry, I've navigated the complexities and challenges without a bachelor's degree and this inspired the name of this page.

I spent two and half years on my Bachelor's degree in Information Systems, which I didn't graduate, mainly because of personal life circumstances. A few years later, my job application was declined because I didn't have a Bachelor's degree, even after going through the entire interview process.

As a result, I decided to become a student again. This time, I enrolled in a Bachelor of Technology in Analysis and Systems Development mainly because this course was shorter, lasting only two years, and allowed me to skip several classes. During this period, I was already an experienced professional, which made the classes feel very boring. Coupled with some life circumstances, I once again didn't graduate.

Disclaimer: I'm not advocating against formal education, unlike that, this is my personal history.

Despite not graduate I gathered a lot of knowledge about the foundation of computer science that helped me to leverage my career which proves the importance of formal education.

Learn to learn

There are several other notable autodidacts over history, but Leonardo da Vinci characterizes these characteristics he was an Italian polymath: painter, sculptor, architect, musician, scientist, mathematician, engineer, inventor, anatomist, geologist, botanist, and writer.

The tech industry is dynamic, where things are changing every day, and experience and how you’ve done something before aren’t as important as the ability to think and learn new things.

My daddy tells me that when I was a kid I asked a lot of “why”, and named me “why-boy”. My curiosity drove me to the path to becoming an autodidact capable of learning almost everything I needed during my career to deliver projects.

The journey shaped my perspective, proving that it's possible to succeed in a professional career not going through the traditional academic paths but also with determination, skill, and continuous learning.

Your presence here is not just about reading content; it's about sharing a journey where every step challenges expectations and redefines possibilities. Whether you're carving your unique path or seeking diverse perspectives, I hope my stories resonate and encourage you in your endeavors.