A New Way of Working with AI

Quality Will Make the Difference

An AI agent doesn’t need to be recruited, doesn’t get tired and can be replicated infinitely. Once the accuracy issue is resolved, speed becomes merely a matter of cost.

For this reason, functional coverage and the pace of new feature releases will no longer be differentiating factors in the future. Competitive advantage will be based on: creativity, quality, communication and organizational capabilities. With mere execution automated, we’ll be called upon to work primarily on what we too often call details today, but which will actually make the difference.

Users themselves will raise the bar of expectations. They won’t settle for software that doesn’t always work, is buggy and difficult to use. And this is fantastic, because it will raise the level of our experience as users and the quality of our work as software engineers.

Specialization

Today, a software engineer is called upon to be a multi-expert. One eye on security, one on quality, user experience, costs, etc. Most organizations have experts or entire departments that handle these topics cross-functionally, but software developers must still understand them, combine them and implement them all. This imposes an unsustainable cognitive load, forcing them into compromises and generally poor application of best practices due to lack of expertise or time.

Generative AI is a great opportunity to solve this problem. The partial or complete automation of certain tasks, such as code writing, will allow us to recover a lot of time and we’ll need to carefully decide how to invest it.

Initially, we’ll be tempted to increase our speed while keeping our way of working unchanged. We’ll produce more features, in some cases almost saturating user needs. Soon we’ll realize that this isn’t the differentiating factor and that much of that time must be invested in quality. Hence the need to transform the generalist developer figure into that of a vertical specialist, with deep domain expertise capable of elevating the product level in a specific dimension.

The New Team

The product team will consist only of specialists, coordinated by a Project Manager. Each will be responsible for a specific dimension of the product. Below is an example lineup, but obviously there can be other components or different multiplicities depending on needs:

• Project Manager
• Product Expert
• Architecture and Technology Expert
• Infrastructure and Operations Expert
• Security Expert
• User Experience Expert

Note that I haven’t mentioned AI in any of these roles, because AI will be completely pervasive. Each of these team members will make extensive use of it upstream and downstream of their contribution.

I believe that work organization will also undergo transformation. Agile principles are totally aligned with this change and will guide, even more strongly, the way of working. There will be growing attention to user feedback because to increase product quality, it will be essential to deeply understand their needs, even to the point of creating customized software versions for them.

The team will still remain central and strategic, perhaps with even more synergies between individual components. I imagine that frameworks like SCRUM and Kanban will become limiting and increasingly collaborative methodologies will spread, based on mutual review and very short release cycles. True continuous delivery.

Review and Control

Depending on the project’s criticality, humans will need to maintain different levels of control over it. In some cases, it will be necessary to have total and complete control over the codebase, comparable to today’s standards, while in others it will be sufficient to rely on perimeter testing, treating some generated components as black boxes. We remain responsible for what we release, whether written by us or not.

But how can we maintain control over something we didn’t create directly? The typical answer, which I myself have given many times, is: through a thorough review process. Does it work? Is it sufficient? In the future, as AI usage increases in our software development cycle, I believe not.

Reading code is much more complex than writing it, it requires a high level of attention and discipline. We will need tools capable of facilitating this activity by shifting our attention to points where it’s most strategic and visualizing the produced artifacts in a clear and navigable way. This is still largely unexplored territory, but I think we’ll see great developments.

Review will remain our bulwark against widespread indetermination, but it won’t be sustainable on a large scale. The only way to leverage AI’s multiplier potential while keeping quality standards high will be to prevent most errors, both macro and micro.

Specifications and Intents

Today, those who work on a project for a long time have a precise mental schema, a combination of domain knowledge, application logic, architecture, and infrastructure that forms the basis for problem-solving or designing new features, generally for making correct choices. I can’t imagine creating this schema only through a series of review processes. The possibility of it becoming nebulous and full of gaps is very high, thus losing control.

The only idea that comes to mind to solve this problem is to anticipate it. Every expert must create this schema, written and if possible in the most formal domain language possible, before AI proceeds with implementation. They must maintain total control over this schema, which evolves over time.

In other words, the product team will mainly contribute to writing technical and functional specifications, intents, tests, rules, and guardrails capable of reducing LLM hallucinations and related indetermination. These elements will be the primary source of truth. Some of them, if sufficiently detailed, will allow complete code regeneration of a component with each modification, making review less necessary.

Modularity will be more important than ever before. The smaller, more modular, reusable, and decoupled the system components are, the more we can automate their generation by treating them as black boxes with deterministic behavior. Many of these will have AI itself inside them.

We will essentially need to carefully apply classic software engineering principles but with the goal of defining formal specifications for various system aspects, making implementation a secondary step in the process.

A New Way of Working

So how will we work? In practice, what will be the way to create software products? We’re already seeing this transformation today, with the spread of AI coding assistants and autonomous agents.

Each team expert will focus on writing, evolving and maintaining specifications for their area of specialization, with a documentation-first approach. The product expert will describe the product’s purposes and peculiarities and various functionalities, the security expert will define security requirements, guardrails, and necessary checks, and so on. I believe DSLs will emerge to help experts express concepts using recyclable abstractions and avoid the indeterminations and verbosity of pure natural language.

Under PM coordination, the software development cycle will be 99% dedicated to creating specifications, review, and integration. We will completely delegate the operational part to AI and won’t be nostalgic about it, because this will allow us to focus on what truly adds value and not on mere transcription of concepts into a programming language.

I imagine that, starting from requirements, each expert contributes (always utilizing AI where useful) to a technical specification of the functionality, validation of an execution plan and addition of new guidelines if necessary. A pre-execution step that will expand with collaboration from all team members.

Similarly, review will be thorough and collaborative, with a priority order that AI itself can suggest depending on the task’s nature. When the review and validation process is completed, the functionality can go into production.

A cycle that can last days, but also hours or even minutes.

The Transition

It will be a faster change than we’re ready to manage, even if with very different paces depending on the sector. The main difficulties won’t be technological, but organizational and related to human capital.

Specialization, being able to add value in a specific area beyond what AI can do, will be a precious and sought, after quality. Probably every software developer will need to deepen individual aspects and be less generalist to remain relevant. Continuous study and deepening beyond basic notions will be fundamental.

We’ll need to reinvent growth paths for junior resources, who won’t be able to build know-how through hands-on experience and will need to start very vertically from the beginning. Soft skills will become increasingly strategic to be able to adapt to change.

Conclusion

As a software engineer, I don’t fear change and indeed appreciate its opportunities. I think everyone will find their own path, grow and learn new things, which is perhaps the true peculiarity of our sector, in the future as in the past.

I hope we’ll stop spending our time on tedious repetitive actions, on days of debugging and bugfixing. I hope we’ll find ourselves using our brains more and not less, as some claim. I hope this will make us feel more fulfilled and contribute to creating useful products and services for everyone.