Two years ago, I showed you how to code with AI using Ollama and Continue. Back then, the assistant commented my code and fixed a few syntax errors. Today, it writes entire features, tests and even deployment scripts.
So naturally, the question keeps coming up: do we still need a software architect?
Spoiler: yes. Even more than before. Let's take stock together.
Writing code was never the hardest part
Let's be clear, typing lines of code has never been the trickiest part of our job. The real challenge is knowing what to build, how to break it down and why to make one choice rather than another.
AI has considerably sped up the writing. It hasn't made these questions go away. Quite the opposite: the faster code gets written, the faster bad decisions spread too.
What AI does very well
Let's be honest, I use it every day, and it saves me precious time on:
- repetitive code and tasks with no surprises;
- generating tests and datasets;
- explaining existing code you're discovering;
- documentation, commit messages, everyday scripts;
- first drafts of a prototype.
In short, everything that comes down to execution. And that's already huge!
What cannot be delegated
Breaking down the system
An assistant answers the question you ask it. It doesn't see the whole picture: the modules that are going to grow, the services that will have to scale, the boundaries that must never be crossed. Breaking down a piece of software means deciding what must stay simple, and what is allowed to be complicated.
Technical choices, and above all the reasons for them
Ask an AI to choose between two frameworks: it will give you a plausible answer. But it knows neither your team, nor your existing systems, nor the person who will maintain the software in five years' time. An architecture choice has to be justified, documented and owned.
Security and data
Secrets management, access rights, personal data, vulnerable dependencies... Generated code often works first time, which doesn't mean it's safe. That's exactly where a review by an experienced eye makes all the difference.
Business constraints
At Keranova, I worked on the software for a laser cataract surgery robot, subject to the IEC 62304 standard for medical devices. Traceability, code reviews, MISRA rules: none of these requirements can be negotiated with an assistant, however gifted it may be.
Responsibility
When software goes down in production, nobody turns to the language model. Someone has to understand what was delivered, why, and how to fix it. That someone is the team, and it's often the architect.
A concrete example: prototyping before building
On the redesign of SOGo 6, Alinto's open source groupware, the work didn't start with production code. It started with architecture proposals, technical studies and prototypes, such as a MAPI server, to clear up the risky points before committing.
Only then did development begin: Python services, deployment on Kubernetes, asynchronous processing handed to Celery. AI can speed up each of these steps. It doesn't replace the decision to do them in that order.
My rules for working with an AI assistant
- The framework first: architecture, conventions and interfaces are defined before anything is generated.
- Small tasks: the assistant moves forward in short steps that are easy to review.
- Tests: all generated code is covered, or it doesn't ship.
- A real review: code that nobody has understood is not finished code.
- No secrets in prompts: passwords, keys and client data stay with you (a local model, such as Ollama, helps a lot).
- Written decisions: every structural choice is documented, for the team and for the next person who comes along.
In short
AI is a tremendous accelerator. It writes faster than we do, and that's a good thing! But software that lasts is still the result of human decisions: a well-thought-out structure, reasoned choices, security under control and responsibility that is owned.
Starting a project, or taking over an application written (partly) by an AI? Find out how I work as a Python software architect in Lyon, or take stock with a code audit. And if you'd like to discuss it, let's get in touch!
