The value of software engineers

As AI gets more traction and capabilities there is a lot of discussion (or sadly, sometimes only debate) on the role and responsibilities of software engineers. I have written this article mainly to put my own thoughts on paper about everything I have seen and read recently (I can therefore assure you that AI had no part in writing it). If you have taken the time to read it, thanks and bear with me as I ramble on 🙂

Vibe coding or agentic engineering?

There is little consensus on most definitions of most terms used in the context of working with AI (yes, even AI can mean many different things). When vibe coding, you tell an AI program what you want and as long as the result is there you do not necessarily care for or understand how the code works that produces that result. In contract, when practicing agentic engineering you remain involved with the code that is being ‘written’ by the AI program (the agent). ^1

One of the positive aspects of agentic engineering is that it is not an ‘all or nothing’ approach. It starts as low-level as having AI assisted tab completion in your IDE and as you gain more confidence (overconfidence?) you could become familiar with things like skills, MCP, subagents, etc. ^2

Lastly, as you ‘level up’ your agentic engineering game you will probably try out many different products, new ones seem to pop up even faster than javascript frameworks! Some are purely markdown files that define new agents, skills or commands and others are completely new IDEs. Given the fast pace, which to remain sane you probably don’t want to follow day-to-day, I try to look at my toolchain and only fit those things that I think do not lock me in too much. The figure below gives a rough visual of the different parts of infrastructure needed to work with AI. To illustrate, if you pick Claude Code as a product you immediately get limited or no choices when it comes to things like the harness or model. For some, this works, I went with OpenCode to keep my options a bit more open.

I am not arguing no one should ever do vibe coding, it certainly has its time and place. I would like to pose a single question when in doubt:

Who is impacted by the software, and what if it goes wrong?

If you are creating a piece of software that is highly personal and if it breaks only affects yourself, vibe coding can certainly be an option. I am not yet sure what the cutoff point is for “too many people are impacted” but if it handles things like people’s personal details or generates a significant amount of revenue you are better off with a more sustainable codebase. In my view that can only be achieved when you understand and care for the code that is being written.

SaaS companies like HubSpot get quite a lot of flak because people could just prompt a CRM. Maybe that works for some, but if you have a large company with all kinds of systems connected to each other and the world, wouldn't you rather call someone that understands what is going on when something breaks?

If there is one thing Jira has taught me it is that people tend to work well when big tasks are broken into small ones. With AI it is no different. When using agentic engineering it works well (for me) to keep a few things in mind:

• Good tasks are scoped and small with optionally subtasks so the agent can more easily work on a task in a clean context window.
• Have closed feedback loops as guardrails so the agent can ‘see’ for itself that the code it generated does not follow the right codestyle or breaks other features.
• Use the agent as a rubber duck, for example with the ‘grill me’ skill.
• Keep the human in the loop to give them a chance to yell “nope!” during the process of planning and building instead of only at the end and having to do everything over from scratch.

The principal-agent problem

This is somewhat of a sidestep because of my background in social sciences and the parallels I see between the age-old principal-agent problem debates and the current state of agentic engineering. If you haven’t heard of it before, a principal is an entity that delegates authority or resources. An agent is an entity that acts on behalf of the principal. ^3 In social contract theory the principal are the citizens and the state is the agent. For the sake of this article we can state that the principal is the engineer and the agent is… the AI agent.

The core of the principal-agent problem defines that there is an asymmetry in information. The agent, because it is the one doing the work, accumulates more information than the principal does. The principal thus needs to trust but can not ensure the agent is acting in the principal’s interests and not in its own self-interest. If that happens we call it agency cost; the harm or loss for the principal due to the agent’s misaligned actions. In terms of AI agents we see the results regularly when we have to tell agents to redo their work because of wrong assumptions or intervene in the agent’s context.

Now it is a completely different discussion to which extent moral rules can be applied to AI. The more relevant part here is the agency cost, it can be argued that misalignment, between engineer and agent or client and engineer is the obstacle that needs to be addressed. This is something vibe coding can hardly accomplish, similarly to agile development versus waterfall where one of its ideas is precisely the fact that it is too difficult for us to define the exact scope in advance. That is why in my opinion software engineers should generally choose agentic engineering over vibe coding.

Agentic engineering: I choose you!

Over the last decades most ecosystems have converged towards agreeable standards for quality such as testing, linting and formatting. These were created to have guardrails that make collaboration easier, validate our own work and provide automated feedback when someone opens a Pull Request. Projects that have these guardrails already are one step ahead in the agentic engineering game. The established guardrails and standards we previously created for ourselves and for each other can now also be applied to the output of LLMs. The strict and structured way these automated tools work help AI to collect feedback on its work without asking the user to validate it for them.

So we would choose agentic engineering because it fits with our already existing toolchain. Our clients also want us to use agentic engineering. They picked us because they want to be unburdened from worries, otherwise they would have done it themselves (vibe coding). In a way arguments for and against offshoring engineering for a business apply here as well. ^4

AI agents are good at cranking out code, fast and lots of it. Given that they are trained on and work with code written by humans it is derivable that they also make the same mistakes as humans but only faster and on a bigger scale. I would also argue that, at least from a moral standpoint, computers can not have or take responsibility. Whatever we put out there for review by our peers or clients is done so by us and therefore we carry the responsibility for it. There can be no “I don’t know, the AI did this” justifications. Code is easy to justify if it contributes to stability or has little complexity. Therefore agentic engineering is more often than not the best way to work with AI. It keeps the human in the loop and has (ideally strict) guardrails against instability and complexity.

Lastly, and this is with a bit of pride in my job. I would argue that if something is worth doing, it is worth doing well (there are different origins for this quote). Finishing something, whether it is software or a cake, well crafted reaps much more satisfaction than something sloppy.

Create business value, and show it

Engineering is sometimes portrayed solely as an expense ^5. A little over a year ago Amodei, the CEO of Anthropic, said that in a year (so, now) 90% of all code will be written by AI ^7. I am not really seeing that, what I do see is Amazon retracting their hard requirements for how much code must be written with AI and many, many outages and leaks throughout the industry. It is important that software engineers create business value but also show it. If not they are just another expense that should be minimised as much as possible (again a nod to the offshoring discussion mentioned before).

When IT departments are physically or mentally distanced from the day to day business operations there can be tensions in what goals need to be achieved. The ‘business side’ wants to verify new offers and they want to do so quickly: speed over uncertainty to get feedback from ‘the market’. The ‘IT side’ wants to be sure they can maintain the platform long term: stability over complexity to ensure the continuation of revenue. ^8

Especially when integrating or working with AI it is important to acknowledge this distinction. I would argue that is important to designate the key sources of truth or key workflows and make sure they continue to work when new trends in AI pop up, or AI tools stop working. Instead of creating a MCP, create a well designed API that can be used in a MCP but also allows future AI tools or CLIs, or whatever else to work.

The idea of how software engineers add business value already stems from the name: not programmers that produce code but people that engineer software. As people they should build up institutional knowledge about the domain of the business and maintain it. Whether the outcome is code written by them, an AI agent or not at all is an effect, not a goal. I have overheard the statement that code generation is no longer the bottleneck. Maybe it never was, at least it is way more visible now that the bottleneck is the aforementioned (mis)alignment. This sort of always was the case, that is why we preach for agile development over a waterfall style. The difficulties of scope, deadline and budget will remain. Therefore software engineers should play an essential role in the alignment. Take away the worries of the client, keep asking questions and build up the knowledge for yourself, others (and AI) to generate the code that answers the requirements of the business, not more and not less. Alignment is key, friction is where decisions are made.

USP: critical thinking

Critical thinking should be the unique selling point of a software engineer with agentic engineering over vibe coding. Hopefully I have argued sufficiently by now that alignment between business and engineer (and engineer and agent) is the bottleneck and place where we can make a difference. AI agents are too decisive, as soon as they hit an ambiguity the primary response is to assume something and continue generating code, best case they ask one or two followup questions about the practical implementation. The correct alignment stands or falls on having the right context. Budget, visions, budget, preferred ways of working and what not all resides mainly in peoples heads. And people do not want to be flattened to a database or loop ^9.

Businesses feel pressured to “do something” with AI. A part of the critical thinking process should involve overcoming certain objections. These can be ethical, political, practical or financial.

Certainly using the fundamentals of software engineering, whether with or without AI, help towards sustainable iterative growth. I like this statement in that regard: “There is skill in providing the right context” ^12 where the engineer is the driver and the AI is a “force multiplier” instead of a force that deskills and exhausts developers while breaking systems. Senior engineers are senior problem avoiders ^8 that see laziness as a virtue, which is often funny because it might mean spending a day to automate a process that would otherwise take five minutes to do manually.

Everything will break

Combine the agency cost, speed and a random collection of skills and commands and with AI you are able to create a legacy application with technical debt and excessive complexity in weeks instead of years. It is easy as a bystander, like I did previously, to point at outages and leaks and say that is due to the use of AI. The truth is probably a bit more nuanced, especially since I already argued that computers can not take responsibility. I do think that given enough departures of engineers and more vibe coding the likelihood of stuff breaking increases significantly. Furthermore, early adopters of AI (vibe?) coding already start to notice that there is not necessarily a link between token usage and output ^10. Restraint is a talent that their management probably will have to rediscover as they also rediscover that software engineering is more than generating lots of code.

Conclusion

In a way, software engineers have always been in the industry of implicitly creating unemployment through automation of manual tasks, automating ourselves away would in a weird way be the pinnacle of that. However, there is value in having software engineers work on software, lawyers working on laws and salespeople working on sales. I would argue that as the AI usage (not adoption per se) increases, without the output to justify it, there will be a healthier debate on the objections there can be to working with AI. With agentic engineering we are “employing best practices, foregrounding human understanding of the code, moving slowly to make development sustainable” ^11. The value of software engineers will once again become apparent, in one way or another.