As software engineers, we start our careers driven by our curiosity for computer science and exciting technological innovation happening in our industry. The most beautiful part of developing software is the creative freedom enabled by the absence of physical constraints. In practice, however, the boundaries of software development are of economical nature. Most of the code that we write serves a business and businesses face time and financial constraints, and competing priorities. These conditions limit the amount of time that we can dedicate to implement an idea and create risks about the cost of maintaining them in the long term.

For this reason, we should weigh costs, risks, and benefits of our technical decisions. For example, what are the non obvious maintenance costs of an architectural choice? We should also focus on understanding our users and guiding our limited resources towards features that actually solve their problems. The following sections expand on a few tools that can help us with that.

Understanding of the problem space

A good problem definition describes what we aim to achieve and the hurdles that stand on the way. It helps us simplify solutions but most importantly avoid an incorrect one. Not understanding the problem is costly in any type of creative endeavor. Particularly in the beginning, we have to make decisions that are not easily reversible. For example, we could choose the wrong tech stack, design a bad architecture, or implement a feature that nobody needs.

I find two mental models to be very useful tools to improve our understanding of the problem space : First principles thinking and second order thinking. The former helps us to break down problems into essential and irreducible aspects. The latter helps us to uncover the obscure aspects of a user flow by thinking beyond the immediate consequences of their actions. The following questions turn these principles into practical tools to dissect a problem that we are solving with our software product:

• Why does this problem exist in the first place?

• Are we building this because it’s genuinely needed, or because “that’s how it’s done” in this domain?

• What are the absolute minimum inputs and outputs this system must have?

• If we were to rebuild this entire domain from scratch with today’s technology, what would we keep and what would we discard?

• If we had 10× the budget, would we solve the same problem? If we had 1/10th?

• What are we implicitly saying “no” to by saying “yes” to this?

• What’s the second-order cost of taking the “easy” path now?

Finally, experimentation and quick iteration are good companions to deep thinking but they can’t replace it. We can always iterate quickly towards the wrong solution. That’s why it is important to treat problem understanding and solution exploration as two different phases.

User empathy and dogfooding

We spend most of our careers working on products that we don’t need. In some cases, we are lucky enough to work in products that solve a problem for us. Regardless of our current situation, it’s critical that we either use our own product or dedicate time to understand what our users do, want, think, and feel about it. There are many techniques that helps us refine our understanding of the users’ needs like creating user personas, writing use case documents, and software stories.

Using our own product is also a practical way of identifying quality issues and opportunities to improve existing workflows. In the tech industry, we call this practice “dogfooding”. Dogfooding helps us to sharpen our focus and narrow down our efforts to problems that actually affect users. It helps us to learn the language that our users use to talk about their workflows which leads to better communication with product managers and designers.

These are some of the good and bad practices that I’ve learned over the years when putting dogfooding in practice:

• Identify gaps in the user documentation by identifying missing steps when performing a task with your product.

• Encourage teammates to dogfood a feature that you are developing by recording a demo of the feature and broadcasting your interest in public channels.

• Provide a tool to collect feedback in a single knowledge base. Ideally, this tool allows categorizing the feedback by releases and calculate different metrics.

• Don’t fall into the trap of believing that our own experience is fully representative of other users which can create a false sense of confidence.

Shifting our mindset from fully technical folks to product-minded engineers helps us amplify our contributions from just building the product to also defining it. As AI-powered tools automate more steps of the software development lifecycle, the industry starts to have expectations from engineers to be able to think about a product end-to-end and wear many hats during the process. Cultivating a product mindset can help us evolve our career in this direction.

I started using agentic tools for the first time this year. My introductory tool was Cline, an open source coding agent that integrates with VS Code as an extension. Cline works by connecting to your preferred model provider service for which you have to provide an API key. After setting up the API key, you prompt the model using chat-style UI, and unlike classic chat tools, Cline can execute CLI tools, edit files, and run tests, based on your commands.

In the second half of the year, I started using Claude code, which replaces the integrated chat UI with a CLI tool that loosely integrates with your editor of choice. The main advantage of a CLI tool compared to the chat UI is the ability to create more automated and parallel flows. You can have multiple, specialized agents running in parallel as separate terminal processes. I’m also lucky enough to contribute to the development of agentic tools while working at GitLab. I’m dog-fooding these tools every day and many of the use cases that I’ll mention in the sections below happen in the context of these tools.

Generative and Agentic AI tools changed the way that I develop software. I can report bugs and draft ideas quicker. I can communicate complex ideas more clearly generating Mermaid diagrams and iteratively refining them. I feel more confident and willing to contributing to projects that I don’t have deep expertise in. And it’s so fun to explore what’s possible with technologies that I don’t know deeply. The following sections expand on each of these use cases.

Generating diagrams

In a remote workplace, it’s challenging to replicate the in-person whiteboard sessions where two or more people can sketch diagrams to communicate high level ideas and build a mutual understanding. Even though there are amazing real-time collaboration tools, I usually strive to communicate ideas as clearly as possible in a written format before jumping to a call. When communicating asynchronously via written notes, dedicating time to conveying an idea using a diagram consumes a lot of time. This aspiration raises the bar for what a diagram should be: Choosing the correct type of diagram and making it clear and useful without excess detail becomes more important.

I’m a fan of Mermaid, a JavaScript-based tool that allows creating all sorts of diagrams using a powerful Domain Specific Language:

 graph TD;
    A-->B;
    A-->C;
    B-->D;
    C-->D; 

Generative AI reduces the time to produce useful diagrams from hours to minutes. Models are quite good at identifying associations, grouping related nodes, and generating color palettes. Exploring what an idea looks like in different types of diagrams is faster than ever. I begin by writing a prompt that describes my idea as a rough diagram, then I refine the model’s first result. For example, I suggested a team to use Storybook interaction testing framework to write integration tests that rely on user-centered commands and assertions.

I wanted to convey in a single diagram multiple ideas: How the testing framework interacts with the UI components, that Storybook provides a mock backend that the state management layer connects to, and how these tests fall in the integration test category. The model generated this diagram that I found overly complex:

I send successive prompts to remove what I considered unnecessary elements of the initial proposal and simplify the information flow and associations. The result was a simpler and more focused diagram that conveyed my suggestion precisely.

• “Remove the unit tests and e2e tests boxes. Focus the diagram on explaining the integration tests”.

• “The diagram should only have three groups: Storybook interaction tests, Vue components, State management (Pinia) -> mocked message bus”.

• “The Pinia store connects to the mocked message bus, not the opposite.”

• “Storybook mocks the message bus and the vue components use the Pinia store”

Brainstorming and flattening the learning curve with agentic tools

My job demands me to learn quickly, adapt, and stretch beyond my current skillet. Agentic AI tools represent a game changer to my productivity because they speed up my process of on-boarding or starting new projects. They also help me realize what’s possible by generating prototypes from ideas that rely on tools that I would have to learn in detail before I can write a line of code.

I think that AI Agentic tools are specially powerful in the hands of experienced developers. I can translate heuristics and best practices that I’ve learned in one tech stack to another. Modern programming languages share similar design paradigms like functional programming, OOP, etc. And software design best practices such as loose-coupling/high cohesion, DRY, and are applicable to most projects. AI agentic tools help me to onboard quickly into the specific implementation details of a tech stack while my experience and understanding of functional/technical requirements guide my requests to agents. Code review of teammates that are subject matter experts serve guardrails to ensure that my contributions conform with idioms and project-specific conventions.

For example, this year, we had to set up an e2e testing framework to test a Language Server in the web browser. Language servers run in a web worker for several reasons such as creating a sandboxed execution context (when loading the worker on a separate origin) and to prevent expensive operations from blocking the web browser’s main UI thread. We wanted to test web workers in a headless browser rather than using an environment that emulates web browser APIs such as JSDOM.

Agentic tools allowed me to develop three prototypes using several combinations of test runners and libraries in a single working day. Making a decision is much easier when we can uncover as many unknowns as possible. In the past, we have to time-box these exploration phase due to the usual time and resource constraints that affect software development projects.

Agentic tools have the potential of flattening the learning curve for contributing to a project without lowering the quality bar. To strike this balance, we should rely on a well known software development practices such as a strong code review process, continuous refactoring, and automating quality checks using test coverage tools, code linters, security scanners, etc.

2026

Next year, I want to scale my usage AI agents by executing them in parallel, learning how to create agents tailored for specific use cases, and automating complete flows. My usage of agents so far has involved significant supervision on my part by breaking down requirements into smaller tasks, providing feedback for every proposal, etc. I want to move away from this workflow and give agents more complex requirements that require longer periods of focus.

One area that I find very exciting is the evolution of agentic AI for accessibility and e2e testing. For example, Playwright 1.56 includes agent definitions for test planning, generation, and most importantly healing. The other area that I want to explore is automating the resolution of breaking changes when updating dependencies to major versions. This kind of maintenance work is crucial for the health of a project, however, it has historically represented a big cost for teams because of the amount of busywork involved.

When it comes to AI, every year feels different. The big players in the AI industry make seismic moves that transform the way we use these tools. I’m looking forward to all the new developments 2026 and how they will reshape my day-to-day work.

Building trust becomes more challenging in personal relationships. Unlike formal systems, our personal relationships lack clear rules, and the consequences of our actions often remain unclear. Yet trust is even more vital in these relationships since they profoundly shape our daily lives. In this essay, I'll explore the behaviors that either build or erode trust in these personal connections. I think that most of these behaviors arise in the conflict between trust and agency.

Trust vs agency

In all human relationships formed with the purpose of achieving a goal, there are two forces at play in every interaction: Trust and agency. Trust provides individuals the assurance that members of their group shared some values, respect a common set of rules, and work towards one or more common goals. Agency is the capacity of an individual to make decisions on their own and pursue interests unique to them with confidence and security.

Trust promotes collaboration while agency serves individual interests. When individuals in the same group are pursuing conflicting interests, their agency can erode trust. Lack of trust, in turn, leads to dysfunctional behaviors such as withholding information, hindering the ability of others to achieve their interests, or just falling into avoidance. This negative feedback loop ends up hindering collaboration in the group.

For example, let’s say that a couple is planning to purchase their first home. A real estate investment is one of the most important and challenging decisions that two people can make together. We trust that the person that we decided to spent our lives with will have our backs financially. We also expect that our preferences will align with our partner’s in a way that makes the buying process smooth and happy.

In reality, your better half might be more of a city animal while you lean more towards the suburbia life style with backyard and an automobile included. Also, you both could have different levels of risk tolerance which leads them to desire properties with a wild price range difference. These conflicting perspectives often lead to the dysfunctional behaviors that I described before because we will defend our agency to choose the home of our dreams. We can try to avoid these traps by guiding our actions with values that protect or even develop trust in relationships.

Building trust

These are personal values that have helped me to develop or repair trust in my relationships.

Respect the agency of others. We should make other people feel that we respect their opinions and decisions even if we disagree with them or they end up making a mistake. Sharing a long term journey with anybody means that they will make many mistakes along the way. If mistakes are unavoidable, what is the point of creating a environment where people feel guilty about them? A better path is helping others to identify the cause of their mistakes and finding possible remediation.

Be honest. Specially, when your truth will lead to conflict and disagreement. Staying truthful to your beliefs is a strong source of self respect and confidence. It’s also a sign of respect for others because we give them the opportunity to decide whether to stick with us or not based on our true selves. Fear of conflict leads people to lie. We are afraid that conflict will deteriorate or even break our relationships. However, the fatal blow is usually the discovery of a long held lie or our incapacity to drag it for longer and exploding as a result.

Assume positive intention. Give other people the benefit of the doubt that you give to yourself when you’ve made a mistake. This is very challenging because we usually don’t have the full picture of what led someone else to behave in one way or the other. Even so, this lack of context should become the reason to see others in a better light rather than judging them. We can approach other people’s mistakes with curiosity and explore the path that led them to their outcomes.

Conclusion

As I’m writing this essay, I can’t escape the reminder of the countless times I’ve failed to act based on the principles that I described. This essay serves me as a place to come back and remember the person that I aspire to be, not the person that I always am. Humanity has prospered due to its extraordinary capacity of working together. Nevertheless, we never lost the tribal and competition instincts that pull us apart. Building trust requires fighting deeply rooted behaviors that we’ve inherited to survive in harsh environments. It is a worthy struggle because our lives feel lighter when we can trust the people that form an integral part of it.