Why More Software Requires More Engineering
The latest advances in LLMs and agentic work have shown one thing: roles within traditional software engineering teams must change. In many businesses a typical engineer would preferably spend 80% of their time on writing code, 5% on software architecture and the remainder on communication, including gathering requirements. The latter two are what I typically think of when discussing engineering. Agentic software development turns this on its head. Honestly, it's about time. Software engineering was the only remaining field in which the engineer actually implemented what they designed.
Software is now created by the entire organization. Not just the engineering team. This means the overall responsibility of the engineering team must change. The team moves from building the actual software, to enabling and facilitating the entire organization to build software.
The largest misconception in this transition is the idea that the engineering team must become responsible for the software that was created by others. Putting it like this might ring a bell: the software industry found itself in the same exact situation around the turn of the millennium. One group building the software, while another group is made operationally responsible, is a disaster waiting to happen. It took the industry years to course correct and we called it "DevOps".
When the role of the team changes, so must its team members. We’re cutting out the part that now can easily be done by other members of the organization: the capture of basic, functional requirements and the creation of code.
Engineering teams that see what is coming will double down on the following roles:
Forward Deployed Engineers, who are comfortable working alongside the business and multiple other disciplines, building more critical and customer-facing applications. This requires both an interest in the business and a good read on the organization’s long term objectives so that they are able to continuously weigh the interests of stakeholders. They care both about software and its users.
Platform Engineers, who create and maintain the building blocks that are used by everyone throughout the organization who creates software. They engage with platform users and make new services, workloads and datasets available at the platform level to make the increased maintenance load manageable for the entire organization. A good Developer Experience (DX) is what allows one company to be agile while the other is not.
This agility is what made the business excited about "vibe coding" in the first place: they are now able to create software that typically required months or years of work, all with a snap of the finger. A handoff between teams or roles is exactly what kills this newfound agility. Instead engineering teams should leave the business at the helm, while adequately supporting the new creators of software. Critical pieces of functionality are moved out of this software by a Platform Engineer when beneficial, allowing for a smooth transition of ownership, while simultaneously contributing to the velocity of future projects.
Nirvana is getting close.