DEV Community: Filipe Ximenes

Context Is King: Reframing Our Mental Model of Coding Assistants

Filipe Ximenes — Tue, 08 Apr 2025 13:31:07 +0000

We've been using the wrong mental model to describe software development AI agents and this might be limiting the value engineers can extract from these tools. I frequently see people referring to AI coding tools as inexperienced developers who can do things for you. I believe this is wrong, these tools are actually senior developers, but they are senior developers without context. These tools know how to write algorithms, they can build complex applications and fix bugs that only experienced engineers can spot. But they don't have the business or the technical context of the thing you are building and that's the main reason why they won't replace human developers any time soon.

Code that produces the right output but that doesn't comply with restrictions imposed by the context at hand is essentially wrong. The most efficient algorithm can increase the complexity of your application which could in the long term lead to bugs and make it hard to make changes to the code. This could be reasonably prevented by using a much simpler algorithm if you know that it's not expected to deal with a high volume of data. Building a highly scalable infrastructure setup is the wrong solution if the constraints are to reduce costs. And it's equally wrong to waste time and resources optimizing the infrastructure if growth is your main goal and money is not a constraint.

Acquiring context is actually one of the main parts of the job of any software engineer and we are quite familiar with the risks of failing to do it. Just as an example of this, as an industry we've recognized that over engineering is a harmful practice and have been learning how to mitigate it for a long time now. Over engineering is essentially a context issue, and is very similar to the problems AI has when it's writing code.

But why is understanding this so important? Changing how you think about AI allows you to improve how you interact with it in order to get better results. For instance, instead of trying to tell it how to do things we can focus on giving it the necessary context that allows it to make better decisions. You can craft your prompts to focus more on the 'what' not on the 'how'. While programming we are constantly making microdecisions that aren't necessarily written, so if we want the AI to also be able to make these decisions it will need more information about the context.

This kind of discussion naturally flows towards the so-called "prompt engineering", but I believe we should aim beyond this. Prompt engineering implies that we are investing a lot into getting the one input that leads the AI to the right decision. But this is far from how we work both individually or within teams. The best solutions come from brainstorming, exploring possibilities and experimenting. That's what we should also be doing with AI. There's no way we will get everything right in one shot, so I think the right path here is that we should instead guide the AI to have a conversation and try itself to acquire more context from us before it actually starts writing the code.

But there's one problem with this approach. The current AI training methods bias models toward producing code immediately so it currently demands some effort in order to keep it iterating with you before committing to an approach. But this behavior is just a result of how LLMs are currently trained, there's nothing preventing future models from being trained differently. I believe this will be the next big change in AI: models that ask more questions before they try to come up with answers. At some point it will feel like a natural conversation we'd have with a colleague and once we've settled all questions and explored solutions we will have a senior engineer with all the context it needs to write all the code in a few seconds.

Boost your career by supporting your teammates

Filipe Ximenes — Fri, 28 Feb 2025 14:55:31 +0000

In my book, Strategic Software Engineering, there are two chapters that explore what success is from different perspectives. They are: "The Success of the Team Is the Success of the Product" and "Your Success Is the Success of Your Team". The titles of these two chapters intentionally use the same structure to convey that these two perspectives are deeply linked.

The main point I wanted to make is that the success of your personal career is directly linked to the success of the product you are building. Moreover, your career is also directly linked to the success of your teammates, because building a successful product requires a great team.

Every time you collaborate, share knowledge, or help a teammate, you are directly investing in your own career. And as a software engineer, there are countless ways to do this. Here are some just to name a few: pair programming with less experienced developers, being attentive during code reviews, giving honest and frequent feedback, participating during meetings, and sharing knowledge.

When you help the people around you become more effective, prevent them from making mistakes, and help them achieve their project goals, you are increasing the chances of the team being successful and therefore investing in your own career. This concept applies beyond just your fellow engineers, from designers to sales reps, everyone is working to achieve the same goal, and you can contribute to their success.

A seemingly contradictory concept related to this is the importance of being dispensable, here is an excerpt from the book that talks about it:

"Another way to empower the team to be successful is by making yourself dispensable. Yes, dispensable, not indispensable. In fact, ideally, your absence should not provoke a noticeable change in the short-term performance of your team. In a mature and functional team, every person should be able to go on vacation, take time off to recover from illness, and assist their relatives with the peace of mind that it won't have a major impact on the overall performance of the team or lead to an incident. This is only achievable when everyone becomes dispensable. Being dispensable means that you do your work publicly and that you communicate progress, it means you write good code that is understandable and easy to maintain, it means that you plan and write documentation and that you capacitate other people to execute routines that you are in charge of."

So the next time you're wasting your time to help a teammate, think twice, because by doing that you are also investing in your own career.

Fix the issue first, improve the process later

Filipe Ximenes — Mon, 17 Feb 2025 14:22:27 +0000

Fixing your process won't get you out of a crisis. During a crisis, your goal should be to get out of it, not to fix your operation. Crises are special situations that, for whatever reason, couldn't be prevented - meaning your process either failed or doesn't have answers to the situation. But in both cases what gets you out of the crisis is not fixing the process.

While fixing the process can prevent the same issue from happening again, it's often not the best way to address the problem at hand. What gets you out of a crisis is analyzing the specific context, evaluating risks, and finding the optimal solution for that unique case. Sometimes that even means bending the rules and stepping outside of established processes.

During a crisis, you and your team are under pressure, stakeholders are waiting for a solution, and there's likely financial risk involved. Speed is the name of the game, so the best solution is whatever reduces impact and gets you out of the situation fastest.

It's also important to note that during a crisis, your ability to think clearly, analyze the situation, identify systemic problems, and propose solutions is severely impaired. This isn't the right environment for making long-term plans. The sooner you leave crisis mode, the sooner you'll have the space to properly think about necessary process changes.

The good news is that fixing the immediate issue is often much simpler and faster than changing processes. It doesn't require as much planning and alignment, and needs a much narrower solution. Keeping your full focus on solving that particular situation gives you flexibility to come up with one-off solutions that don't need to scale or meet long-term requirements of the product.

There's a story in the Risk Management chapter of my book that I think illustrates this concept really well:

"We had a situation in one of Vinta’s projects where an application used a secondary database to store metadata about user’s actions. These were relevant information but non-critical to the operation of the system. An issue caused by our infrastructure provider during a planned maintenance window took down this secondary database but it didn’t affect the main one. Unfortunately, the application code was designed in a way that made the error in the secondary database to affect and break some of the main flows of the product. We evaluated the situation and decided that it was more important to restore the application to users even if that meant losing some of the metadata. So our first step was to comment out all calls to the secondary database and deploy a new version of the application so people could get back to using it. We then deployed a new secondary database, restored the data from a backup and uncommented calls. At this point the application was back to fully operational and the team out of crisis mode so we could take our time to design and build a long-term solution that would prevent the issue from happening again."

50 years of the Mythical Man Month: insights that still shape the software industry

Filipe Ximenes — Wed, 12 Feb 2025 10:48:10 +0000

The Mythical Man Month by Fred Brooks has been on my reading list longer than I'm willing to admit, but I'm happy that this has finally changed. At the same time I'm confident that I was able to enjoy it far more with the professional experience I have now. I also think it was a privilege to read it for the first time in such a pivotal moment for the software industry.

This is a classic of software literature with the first edition being released 50 years ago, so when I picked the book I was mostly expecting to get a historical perspective of the industry and learn about practices we'd long since abandoned.

How wrong I was. Apart from the references to technology that has long been buried in the past, The Mythical Man Month is still a modern book on software engineering.

It was shocking to see that many of the discussions we have in this day and age were already issues back then. Throughout the book Brooks proposes solutions that were new and innovative for the time. And don't get me wrong, there are many ideas that seemed reasonable to him that we've now experimented with and moved away from a long time ago. But for every single chapter I was able to find a concept that was either a seed to a modern software engineering practice if not a if not an exact reflection of what we do today. Here are some key insights that particularly resonated with me.

In the chapter "The Surgical Team" Brooks shares a setup for software teams that is akin to a medical team performing a surgery.

"[...] each segment of a large job be tackled by a team, but that the team be organized like a surgical team rather than a hog-butchering team. That is, instead of each member cutting away on the problem, one does the cutting and the others give him every support that will enhance his effectiveness and productivity. [...] Who are the anesthesiologists and nurses on a programming team, and how is the work divided?"

While the proposed structure does not exactly match our current practices it's very easy to draw some parallels to how we've been organizing teams into small specialized squads. Also in this chapter Brooks describes the work of "The toolsmith":

"File-editing, text-editing, and interactive debugging services are now readily available [...]. But these services must be available with unquestionably satisfactory response and reliability; and the surgeon must be sole judge of the adequacy of the service available to him. He needs a toolsmith, responsible for ensuring this adequacy of the basic service and for constructing, maintaining, and upgrading special tools—mostly interactive computer services—needed by his team. [...] The tool-builder will often construct specialized utilities, catalogued procedures, macro libraries."

If this is not one of the best descriptions of the work of a modern SRE engineer I don't know what else it is. Moreover, in the the "The Second-System Effect" chapter Brooks writes:

"This second is the most dangerous system a man ever designs. When he does his third and later ones, his prior experiences will confirm each other as to the general characteristics of such systems, and their differences will identify those parts of his experience that are particular and not generalizable.
The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one."

This can be directly mapped to our modern practices to avoid overengineering and to the "rule of three" of refactoring. Later, in the chapter "Passing the Word", we have:

"Anyone can propose problems or changes, but proposals are usually distributed in writing before the meeting. [...] These have been circulated and carefully considered by implementers and users, and the pros and cons are well delineated. If a consensus emerges, well and good. If not, the chief architect decides. Minutes are kept and decisions are formally, promptly, and widely disseminated."

And with that Brooks describes something quite similar to what we now know as Architecture Decision Records (ADRs).

There are some other examples in my list that are related to Agile practices but that I'll leave to another post. For now, I hope that I've interested you in Brooks' work, despite the age, The Mythical Man Month is a classic of our field and it's well worth the read.

What classic software engineering books have surprised you with their modern relevance? Have you read The Mythical Man Month? Share your recommendations and thoughts in the comments!

The mythical silver bullet

Filipe Ximenes — Thu, 06 Feb 2025 14:01:02 +0000

40 years ago, Fred Brooks made a prediction about software development that still holds true today.

In his classic book, The Mythical Man-Month - 20th anniversary edition" features an essay titled "No Silver Bullet - Essence and Accident in Software Engineering" originally published in 1986 which states:

Published in 1995, this edition of the book is perfectly timed to assess the outcome of this statement. The author then carefully reviews the state of software at the time to conclude the statement was indeed correct. How could he be so certain in his ten-year prediction? The explanation is actually not too complex. It's based on the essential nature of the problems of software. According to Brooks:

Brooks then lists four essential properties that are inherent to software making:

▪️ Complexity - software systems are frequently more complex than most other things humans build, that comes from size and the non-linear nature of its growth.
▪️ Conformity - systems are complex because we humans impose complex rules to them, not because they're necessarily naturally complex.
▪️ Changeability - the more successful software becomes the more people want to change it to meet demands beyond the original domain.
▪️ Invisibility - it's impossible to perfectly model the structure of any minimally complex system in our limited 3 dimensional understanding of the universe because it naturally requires many more dimensions so all attempts of mapping it through diagrams are inherently incomplete.

Reading Brooks' essay almost 40 years after it was originally published is quite shocking for how modern it still sounds. For all the progress we've made over these years it's clear that we are still mostly attacking the accidental problems of software development. Here are some examples:

📌 Automated tests, code linting and CI tools that run every time code is changed can significantly prevent bugs and enable larger teams to work safely in the same codebase.
📌 Modern databases and cloud computing significantly reduce the toil of scaling systems to a virtually unlimited number of users.
📌 Observability tools have made the work of identifying issues and debugging much faster and effective.
📌 AI assisted development is the new kid on the block and it's helping developers to write code and fix problems much faster than before.
📌 Advancements in "workstations" - as Brooks himself mentions in the book - is still a source of improvements through ever more powerful chips in computers and mobile phones.

But we too made progress in fixing the essence, although most of the progress is mostly incremental to things Brooks already recognized:

📌 Open source has certainly made a dent into developer productivity by defining standards and abstracting away complexity related to things like: protocols, basic system management features and even machine learning. This is mentioned in the book as "buy vs. build" and recognized to address essential difficulties. The use of APIs also had a significant impact on this.
📌 AI assisted development also deserves some recognition here as it enables faster understanding and navigating essential complexity in software.
📌 LLMs also have the potential to provide a path to solving issues that were previously overly complex or beyond our technology capabilities.

There's a lot of talk on what will be the impact of AI in the field, but studies so far haven't identified an improvement of 10x in productivity. Many industry players are promising a revolution but whether it's actually going to happen is still to be seen. For the most part it seems like Brooks' prediction is still valid today as it was 30 years ago.

What do you think? Will AI improve to become the mythical silver bullet? Share your thoughts in the comments 👇

You're not paid to write code

Filipe Ximenes — Wed, 29 Jan 2025 15:29:28 +0000

It's inevitable, with every new generation of AI your ability to write code becomes less and less relevant.

The good news is that writing code was never the goal, it's just the medium that is - or used to be - the most efficient way of delivering value.

As AI evolves you need to shift your focus to two things:

Making sure you absolutely dominate the new tools to write code and are very productive with them.
Master the parts of the job which AI will have a much harder time beating humans.

Number 1 is straightforward, we are in a period of intense change, make sure you test the new models (looking at you DeepSeek), explore code editors and improve your prompting skills. Both Cursor and Windsurf have an agent mode that can autonomously navigate your codebase creating and editing files. I'm seeing many people that haven't played with it yet, if that's your case I recommend starting from that right now.

Number 2 involves a set of skills that the current AI technology can't do. Understanding demand, adapting to change, communicating effectively with stakeholders and peers and managing risk were always key differentiators of great engineers and they will continue to be for a long time. Engineers who think and act strategically will keep being relevant. They will continue to be the decision makers while they delegate the repetitive part of the job to AIs.

OpenAI Operator and how we will consume services

Filipe Ximenes — Fri, 24 Jan 2025 13:09:22 +0000

With the release of OpenAI's Operator I'm seeing people saying "oh we are going to need to rebuild websites for Operator" ...really?

if you need to rebuild, it completely misses the point of having an agent that knows how to navigate the web.
whatever you do it won't ever be better for an agent than a simple API spec.
you are going to end up with a UI that is bad for users and worse to agents than any API would ever be.

Operator seems very interesting and I do think agents using browsers is a piece of the puzzle but I'm skeptic this is how agents will work in the future when they are taking simple voice commands and executing complex tasks in the background by integrating a bunch of services.

Provide a openapi.yaml file of your API and you have an agent that is much more efficient in accomplishing any task than clicking through a browser will ever be, with the benefit that it can present results in any format it's best for you to consume.

While browser navigation will always be necessary for certain things, most of the services we consume in the day to day already happens through an app - which does things through an API.

In practice, if services want user to provide the best possible experience to users it's in their interest that agents can navigate their content and execute tasks in the most efficient way. So what I believe is that we will end up with a kind of app store which instead of UIs to interact with APIs, agents will just have the description of the APIs. They will execute the tasks through these APIs and generate an UI to display the result to users - or just speak to us directly.

What I think will be the impact of AI on developer jobs

Filipe Ximenes — Tue, 21 Jan 2025 12:28:58 +0000

- or will AI replace software developers?

First, let's address the elephant in the room. Neither I nor anyone else knows yet if AGI is possible. If it is and someone actually manages to build it, it's pointless to even spend any time thinking about the question. It would have such a big impact in all areas of society that it becomes pointless to evaluate the matter from just the perspective of the IT market.

But yes, ours would probably be one the very first professions to vanish since the majority of our work happens in an environment that is purely digital and because software can be easily tested for validity (sometimes it can even mathematically proven to be right). I've seen many people a lot smarter than I am saying that perhaps AGI is possible just probably not with the LLM technology we are using today, so perhaps we still have a few years to go - I think Sabine Hossenfelder has some interesting takes on this, go check her videos on YouTube.

With that cleared we can focus on more practical and actionable scenarios.

If there's no AGI, then we first need to consider how far the LLM technology can go. Starting with hallucinations, although LLMs get better at this with every new iteration there will certainly be a limit to it. That's because hallucinations are intrinsic to this technology. The same thing that causes hallucinations is what made LLMs possible. The first consequence of this is that for any minimally relevant application we will need a person in the loop reviewing the work of the LLM. That is to reduce the chances it breaks applications leading to money loss or more severe consequences depending on the context.

The other part of it is that this kind of AI works best when prompted to do the things which it was extensively trained on. "Build an iOS app for an airline company", "write a merge sort algorithm in Python". For these well known use cases it can yield excellent results even if you provide very little context. But if you want anything more specific or less usual you are going to need to write a prompt that is much more detailed than that. And will probably need a few rounds of iteration before you have a reasonable result. This again means we need someone working with the LLM.

So while I do think we will always need developers reviewing the output of LLMs I also agree we will naturally need less and less of this as the technology evolves. In that sense we could say that there will be less jobs for developers and the ones available will be for senior positions.

That was the "programming" side of the debate. We know writing code is just a part of the job. There's another significant chunk of it that is related to things like aligning expectations with stakeholders, understanding context and debating technical and product solutions. I don't see a LLM emailing the CEO of a company requesting clarification on a decision, or participating in a meeting with unprompted comments and opinions - someone will certainly build this, but I think we will quickly figure it's best to turn it off.

The skills beyond writing code are a significant part of the job and they are not going away. We'll still need engineers balancing tradeoffs, negotiating priorities, managing risk and collaborating with users, and with people from other areas of the company. It's much less likely that LLMs will take on these things compared to their potential to write code. But it's also important to realize that writing code was never where the value was. The value is delivering great products to users and it requires much more than programming.

For the last part of my argument, we need to look back in history. How many times has the introduction of tools that significantly increased developer productivity resulted in less jobs? What we've seen is actually the opposite, every advance has actually ended up empowering more people to enter the area and opened opportunities for companies to build better and more. Which leads to my last point, companies hire to outperform their competitors, not to execute a fixed backlog. Every developer now has access to LLMs, the field is leveled so justifying hiring freezes with the productivity gains of AI is just a temporary phenomenon before companies realize they are going to lose clients to other companies that are building faster.

To conclude, no, I don't think the impact of LLMs on software developers jobs will be as big as it's being predicted. But I'm certain that writing code will become an ever smaller differential for engineers that want to succeed in the profession and for the people trying to join the industry. For these people I've written a book with insights on how you can improve your skills beyond writing code and become a more strategic engineer. Go check it out.

I had an amazing chat with Mat Henshall about this topic which inspired me to write about it. Some of the ideas in this post were drafted from this conversation. Gergely Orosz and Addy Osmani wrote about this topic in much more depth than I have and I highly recommend reading their post How AI-assisted coding will change software engineering: hard truths

There's more to risk management than what engineers typically see

Filipe Ximenes — Wed, 15 Jan 2025 11:32:12 +0000

There's a lot more to managing risk in software beyond evaluating what can break and engineers frequently fail due to a lack of a better understanding of what risk management comprehends.

When we talk about software risk, engineers typically focus on functionality breaking or systems failing catastrophically. Although these situations deserve attention, this limited view of risk can severely impact our ability to evaluate options and lead to decisions that hurt both business and careers.

One critical risk I constantly consider relates to prioritization and cost-effectiveness. While it might seem unusual to frame this as risk, the connection is direct. Commercial software resources are limited - both in money and engineering time - and companies constantly compete to win market share. Delivering the right product at the right time is a competitive advantage that can win customers or prevent losing business to competitors. Sometimes, releasing a partially broken feature is actually less risky than delaying the release to get it right.

This ties directly to the risk of complexity and over-engineering. Our industry has excellent processes and tools for building and maintaining software - I'm constantly amazed by how much these have improved our work. However, this often leads to people reaching for tools far beyond their actual needs. Everyday I see one post about teams migrating to microservices, and two others about teams going back to monoliths. The best tool is the one that adequately solves your current objectives within your constraints. More software means more potential points of failure. Reducing code and dependencies is a risk mitigation strategy.

Recency bias presents another sneaky risk. We naturally give disproportionate attention to current events over past ones. Sure, it feels great to optimize that new feature to run under 10ms, but is it really more important than fixing that year-old query that is now taking 500ms? Effective risk management requires comparing and prioritizing - but before you can compare, you need visibility. Invest in tracking known issues, technical debt, and observability so you have the right information to guide how you invest your time.

To help engineers develop a more comprehensive approach to risk management, I've dedicated one of the four chapters of my book "Strategic Software Engineering: software engineering beyond the code" to this topic. Dive deeper into risk assessment, self management - which I consider to be a kind of "non-technical" risk management - and many other essential topics that make great engineers at https://a.co/d/8kLbqtJ

How else can we improve our technical risk management skills? Share your experiences below.