AI now writes a growing share of the code in every development team, and Quality Clouds is no exception. In this conversation, Albert Franquesa and Luis Barreiro examine what happens when several developers generate code with different assistants and no shared rules, and why the answer is not to ban AI but to govern it.

Why governing AI-generated code matters

Generative AI has changed the fundamental question in software development. For decades, the bottleneck was writing the code; today, an AI assistant can produce it in minutes. The challenge is no longer speed but control: making sure that code conforms to the organisation's architecture, conventions, and security and compliance requirements. We call this code governance. Without it, every developer and every tool moves in a different direction, and what is gained in speed is later paid back in technical debt, inconsistency and regulatory risk. A team's critical skill is no longer simply writing code, but defining the rules by which AI writes it, and being able to prove those rules are met.

Prefer the Audio Version?

Listen to the full conversation on the go. Your favorite blogs, now in audio format

Open Spotify

About the participants

Albert Franquesa is Chief of Strategy & Board Member at Quality Clouds, where he leads the company's strategy around the governance of AI-generated code.

Luis Barreiros leads one of the Quality Clouds development teams and is responsible for the architecture and quality of the code his team produces.

The Interview

Albert Franquesa: Luis, a few weeks ago we were talking about how AI is changing the way your team writes code, and you mentioned there was a degree of disorder. What exactly did you mean?

Luis Barreiros: That every developer uses the tool they prefer — Claude Code, Cursor, whichever — and, above all, uses it in their own way. There is no common standard. Just last week, I reviewed a pull request in which the generated code did not use the standard Spring Boot mechanisms. It worked, but it was not built the way we would have built it.

Albert: That is the obvious question: if the code works, does it matter how it was built, or with which tool?

Luis: Working is the minimum, not the goal. The problem is that the code does not follow our architectural guidelines, and that makes it unmaintainable in the medium term. If the same problem is solved in five different ways, or if the naming is inconsistent from one module to the next, you lose control. What worries me most is duplication: someone creating a new factory when one that does the same job already exists. The AI does not know that unless someone tells it.

Albert: So the code is technically correct, but architecturally chaotic. If the root cause is that each developer gives the AI their own instructions, should we not standardise those instructions — the Markdown files — and commit them to the Git repositories so the whole team works to the same rules?

Luis: That is the first step, yes. Today almost no project has those instruction files standardised; we have done it in a few specific repositories, but not systematically. Unifying them is how we get the AI to generate code that fits our standards from the outset, rather than correcting it afterwards in review. It is an initiative we have already started to move forward internally.

Albert: Let me suggest going a step further. Standardising the files is good, but the files change. Imagine a central place where those instructions are inventoried, with their version history and traceability of which code was generated under which rules. Anyone could check they are using the correct version for their project, and we could audit the result. Would that be useful to you?

Luis: Very. In the end, those Markdown files are what really guides the tool: governing them is governing the code. And this is not a problem that only matters at large scale. Today only a few of us generate code this way; with ten developers each doing it their own way, the loss of control would be unmanageable.

Albert: There is a second reason to standardise, and it is external. Several of our clients in the financial sector already ask us which code generators we use. It is not curiosity: they need to verify compliance with standards such as ISO/IEC 42001 and ISO/IEC 27001, which also extend to software and the supply chain. If there is disorder internally, you cannot demonstrate that your own processes comply.

Luis: I was not aware that audits reached that level of detail. Seen that way, standardisation stops being an engineering preference and becomes a requirement. A rule as specific as “no new factories in this code” stops being a personal preference of mine and becomes something that can be verified.

Albert: That is the idea: moving from each developer working in their own way to a set of explicit, versioned and auditable rules. It is exactly the problem we have been working on for some time, and the conversation that any team already generating code with AI should be having.

Conclusion

This conversation describes, in practice, the problem that Quality Clouds Hub solves: governing the instructions that guide AI assistants, maintaining traceability between rules and generated code, and verifying that the result meets the organisation's architecture and security standards. Quality Clouds Hub will be available from 1 June 2026.