Your engineers are vibe coding which means your licence compliance is probably broken

• 

• Laura Trapnell

• 06 Jul 2026
• •
• 5 min read

• Share

AI-assisted development is transforming how internal tools get built but most companies haven’t thought about what’s hiding in the code.

There’s a quiet revolution happening inside engineering companies. Project staff (mechanical engineers, data analysts and calibration specialists) are using AI coding tools to build software that makes them better at their jobs. They’re not software developers by training. They’re domain experts who’ve discovered that tools like GitHub Copilot, Cursor and ChatGPT can turn a natural-language description into working code in minutes.

The industry has a name for this: ‘vibe coding’. You describe what you want, the AI writes it, you test it, you ship it. No computer science degree required (theoretically, I would argue exactly the opposite remains true in order to properly test architectural resilience).

For productivity, it’s extraordinary. For legal compliance, it’s a ticking time bomb. I was asked to advise on this exact issue earlier in the week and I found it so interesting that I thought I’d share it with you and open a discussion.

The problem nobody’s talking about

When an engineer asks an AI tool to “write me a Python script that optimises fuel injection timing”, the AI doesn’t create code from first principles. It draws on patterns learned from billions of lines of open source code, and one of the most misconceived misconceptions about open source code is that it is ‘free to use’, but open source code always comes with licence terms attached and it is the scope of restrictions within these licences that are creating the latent liability for organisations which are not even aware that they have them embedded within their proprietary models.  

Some of those licences are permissive, MIT and BSD essentially say: “Use this however you like, just keep the copyright notice.” That’s fine.

However, some are ‘copyleft’. The GPL, AGPL and similar licences say something very different: “You can use this code, but if you do, your entire program must be released under the same open terms”. It’s viral by design and the intention with these licences has always been that ‘freedom propagates’.

When AI tools reproduce substantial portions of copyleft code (and studies show they do, sometimes verbatim), that obligation attaches to whatever codebase it lands in. Your proprietary internal tool now has a latent obligation to release its source code.

“But it’s only internal”

This is the most common response and it’s partially right. The GPL’s distribution obligation only triggers when you distribute the software to third parties. If the tool never leaves your organisation, you’re unlikely to face an enforcement action. But “unlikely” isn’t “impossible” and “internal today” doesn’t mean “internal forever”, particularly if a model becomes commercially viable as the development continues. The risk crystallises when you:

• Share a tool with a client or partner, even informally, even “just for this project”.
• Spin out a software product. That internal tool that works brilliantly might have commercial potential.
• Get acquired. Due diligence will audit your code and contaminated IP is a deal issue.
• Open source something deliberately. You can’t release code under a permissive licence if it contains GPL components.
• Use AGPL code. This variant triggers on network access, not distribution. If anyone outside your organisation accesses the tool over a network then you’re caught.

The dependency problem

It’s not just AI-generated code. When an engineer runs pip install or npm install, they’re pulling in libraries and those libraries pull in their dependencies, which pull in their dependencies. A single npm install express command could bring in nearly 60 packages and each has its own licence. Most engineers have never checked. Most don’t even know that they should.

What organisations typically get wrong

The instinct is usually to solve this with an IP ownership document, a licence asserting “all code created here belongs to us”. Organisations draft internal proprietary licences, drop them in the repository root and assume the problem is solved. This is exactly what my client was doing. However, that doesn’t solve the problem because you cannot override a third party’s copyright by putting your own licence file next to their code. The GPL doesn’t care what your employment contracts say because copyright law doesn’t work like that! In any event, the ownership question is the easy one (employment IP provisions handle that). The hard question is: ‘what obligations/restrictions have attached to code you’ve incorporated and are you complying with them?’

What actually works

ORganisations that get this right in my view need three things:

1. A development policy with a licence classification system

Give engineers a traffic-light framework they can apply without legal training:

This needs to apply to both AI-generated code and manually imported dependencies.

2. Practical tooling

Policy without tooling is wishful thinking. At a minimum organisations need:

• A licence scanner that runs on every commit or pull request (FOSSA, Snyk, Trivy, or even command-line tools like license-checker).
• A Software Bill of Materials (SBOM) for each project listing every dependency and its licence.
• A review gate requiring human sign-off before AI-generated code is merged.

These aren’t expensive or complex to implement. Most can be added to an existing GitHub workflow in an afternoon.

3. Education, not just enforcement

Engineers aren’t ignoring licence compliance maliciously, some of them know about it (certainly, those who are ‘my age’!) but some may never have been told it matters. My response to the client I was advising was to draft a short, practical awareness guide that explains why (in terms that resonate with their domain).  In my view, this changes behaviour far more effectively than a 30 page governance policy they’ll never read.

The retrospective problem

If your engineers have been vibe coding for months without any of this in place, you probably have existing repositories with unknown licence exposure. The temptation is to panic or to ignore it.

The right approach is a structured, no-blame audit:

1. Run a licence scanner across existing projects.
2. Flag anything red or amber.
3. For each flagged item, determine whether it can be replaced with a permissive alternative? Can it be isolated? Or does it need to stay (with proper compliance)?
4. Document the outcome.

Most contamination in internal tools can be resolved by swapping one library for another. Things are rarely business critical but you need to know the level of risk that the organisation faces.

Why this matters now

Vibe coding is accelerating. The tools are getting better, the barrier to entry is dropping and more non-developer staff are building more software in more organisations. I have so many clients who say “I have developed a platform/an App/a website and I have no software experience”. The organisations that put guardrails in place now (lightweight, practical and proportionate) will avoid being one of the organisations that discover the problem during a sale, a partnership negotiation or (worst case) enforcement action.

The fix isn’t, in my view, to ban AI coding tools. That’s a backward step and they are too productive for that. The fix is to make sure the humans using them understand what’s in the code they’re shipping  and have the tools to check.

Join the discussion

I’d really like to discuss this topic further and find out from this sector what organidations are doing to tackle this issue.  If you’d like to join a discussion, please email me: [email protected]