Main idea

When a product, support or business team starts building screens and tools with an assistant, the reflex is to design a regime of its own for them: their charter, their rules, their validation process, their level of requirement. That reflex manufactures a second system, parallel to the first, which will have to be maintained separately and which will drift.

Yet the tooling already exists, and it was built for exactly this problem: continuous integration, security scanners, repository conventions, quality rules, scoped environments, and increasingly the instruction files, prompts and skills developers write for their own use. None of that needs reinventing for non-developer profiles; their output simply has to pass through it.

The work of governance is therefore a work of connection — which repositories, which environments, which automatic checks apply to this output — and not a work of writing new norms.

Why it matters

It changes the nature of the question put to the engineering team. "What should we require of a Product Manager who codes?" invites a long and contestable answer; "what do we plug them into?" invites an operational answer that is already largely available.

It also avoids an absurd asymmetry, where output from a product profile would be subject to rules written for the occasion, stricter or vaguer than the ones applied to the team's own code.

Nuances and limits

Connecting assumes the tooling exists and is in good shape. In an organization where automatic checks are weak, there is nothing to plug into, and the subject reverts to building that tooling — for everyone, not only for the newcomers.

Some points cannot be connected and do have to be decided: which repositories are reachable, what write access to data is granted, who owns the objects produced.

Open questions

• What share of the tooling developers write for themselves stays unusable by a non-developer, for lack of a shared vocabulary rather than for lack of permissions?