DEV Community: Gnzikoune

Repository governance isn't the final layer. It's the first one.

Gnzikoune — Thu, 23 Jul 2026 00:37:14 +0000

In recent weeks, something interesting has happened.

I wrote an article explaining why prompts aren't enough.

Then I addressed the issue of repository governance.

The ensuing discussions expanded on this idea.

I realized that GEF solved a significant problem…

…but only part of it.

When I started developing Guardian Engineering Framework, my goal was simple:

To embed engineering practices directly into the repository, taking them out of the prompts.

Instead of telling the AI:

write tests
follow the GitHub feed
document the architecture

the repository would already contain these requirements.

This still seems like the right direction to me.

But repository governance isn't the whole story.

Imagine an AI agent that could modify:

CI workflows
Branch protection
Code ownership
Repository rules
Deployment policies

At this point, governance becomes self-modifying.

The repository no longer dictates engineering practices.

The agent defines what engineering means.

That's a whole different issue.

This discussion led me to consider technical governance as a multi-layered system of trust.

AI Agent

↓

Repository Governance
CI
Hooks
ADR
Documentation
AI Rules

↓

Platform Governance
Branch Protection
Rule Sets
Required Reviews
Secrets

↓

Identity Governance
Permissions
OIDC
IAM
Administrator Rights
Auditing

Each layer protects the layer below it.

More importantly…

Each layer must be harder to modify than the one it protects.

Otherwise, the boundary of trust disappears.

This has also changed my view of GEF.

Today, GEF focuses on repository governance.

This is a deliberate choice.

It allows each project to benefit from a solid technical foundation from the very first commit.

But I no longer see repository governance as an end in itself.

I see it as the foundation.

The interesting questions that now arise are:

How do we continuously verify technical policies?

How do we measure governance drift? How do we audit policy changes?

How do we ensure that AI cannot, without its knowledge, circumvent its own constraints?

These questions are probably more important than rapid engineering.

They are also far more complex.

I don't believe that the future of AI-assisted software engineering lies solely in smarter agents.

I believe more in multi-level governance.

Because excellence in engineering has never been based on blindly trusting developers.

Perhaps AI should follow the same path.

The future of AI coding isn't better prompts. It's better engineering constraints.

Gnzikoune — Wed, 22 Jul 2026 03:35:55 +0000

Over the past few months, I've noticed that most discussions around AI coding assistants focus on prompts.

People share:

.cursorrules
AGENTS.md
CLAUDE.md
long prompt templates
custom instructions

The assumption is always the same:

"If I explain my engineering practices clearly enough, the AI will follow them."

For simple projects, that works.

For real software projects, it eventually breaks down.

The problem isn't intelligence.

It's governance.

Every AI coding assistant eventually produces something like this:

giant functions
skipped tests
undocumented architectural decisions
ignored security practices
direct commits
inconsistent commit messages
missing pull request descriptions

Not because the model suddenly became "worse".

Because nothing prevents it from taking shortcuts.

Exactly like humans.

We already solved this problem... for humans.

Professional software engineering has never relied on trust.

Instead, we built systems that enforce discipline.

We don't ask developers to:

write tests

We fail CI.

We don't ask them to:

use meaningful commit messages

We reject the commit.

We don't ask them:

not to push directly to production

Protected branches make it impossible.

Engineering isn't based on trust.

It's based on constraints.

Yet with AI...

...we went backwards.

Instead of constraints, we write instructions.

We create increasingly sophisticated prompt files hoping the assistant will remember them.

Always write tests.

Always document architectural decisions.

Use GitHub Flow.

Follow OWASP.

Keep functions below 40 lines.

Never commit directly to main.

Those aren't guarantees.

They're suggestions.

And suggestions are eventually ignored.

Rules are not enforcement.

Recently I came across an article making a simple observation:

Rules without enforcement are just hopes.

That sentence stayed with me.

It perfectly describes the current state of AI-assisted development.

An AI may fully understand your engineering rules.

It may even agree with them.

But unless something checks compliance, nothing prevents shortcuts.

The same principle applies to human developers.

Why should AI be different?

The repository should enforce engineering.

That realization completely changed how I think about AI development.

Instead of teaching every assistant how my projects work...

...what if the project itself became responsible for enforcing engineering practices?

Not through prompts.

Through mechanisms.

Imagine starting a project where, from the very first commit:

Git Hooks reject invalid commits.
CI blocks pull requests with insufficient test coverage.
Security defaults are already configured.
Branch protection is expected.
ADR templates already exist.
Documentation structure is predefined.
AI assistants receive project-specific guidance automatically.

The assistant isn't simply asked to follow best practices.

The repository continuously pushes it toward them.

This is why I built GEF.

Guardian Engineering Framework (GEF) started as a project generator.

But over time I realized that's not what it really is.

It's a governance layer for AI-assisted software development.

Its purpose isn't to generate code.

Its purpose is to generate constraints.

From the first commit, a project already contains:

engineering standards
Git workflow
AI rules
documentation templates
ADR structure
Git Hooks
CI pipelines
security defaults

The repository becomes opinionated before a single feature is written.

Prompts are Level 1.

Repository governance is Level 2.

Most AI tooling today focuses on prompts.

Prompt Engineering
↓
Explain the rules

GEF moves one step further.

Repository Governance
↓
Enforce the rules

I believe the next evolution will go even further.

Agent Governance

↓

Policy Engines

↓

Runtime Verification

↓

Continuous Compliance

Instead of asking AI systems to behave correctly...

...we'll build systems where incorrect behavior simply cannot progress through the engineering workflow.

*The future isn't autonomous AI.
*
It's governed AI.

The goal isn't replacing engineers.

The goal isn't removing code reviews.

The goal isn't trusting AI more.

The goal is building engineering systems that require less trust in everyone involved—humans and AI alike.

Because great engineering has never been about trusting developers.

It's always been about designing systems that make good practices the easiest path—and bad practices the hardest.

AI shouldn't be an exception.

If AI-assisted development becomes the new normal, perhaps the real competitive advantage won't be better prompts.

It will be better engineering governance.

Why your AI code always ends up producing "technical debt" (and how GEF solves the problem)

Gnzikoune — Wed, 22 Jul 2026 00:01:08 +0000

Introduction: The Paradox of the Amnesiac Assistant It's an experience we've all had: you start a new project with a cutting-edge AI like Cursor, Windsurf, or Copilot. The first few hours are magical. The architecture is clean, the commits are conventional, and the tests pass. You feel like a conductor, increasing your productivity tenfold.

Then, things start to go wrong. Caught up in the flow of development, the AI begins to "forget" the basic rules. It suddenly produces 200-line functions, ignores unit tests to go faster, or pushes its changes directly to the main branch without review. You end up spending more time reminding it of Clean Code principles than actually coding. This is the flip side of "Vibe Coding": an initial acceleration that comes at the cost of exponential technical debt. The Guardian Engineering Framework (GEF) was designed to break this cycle of amnesia. This isn't just a style guide; it's a "mechanical" solution that transforms your engineering standards into insurmountable barriers for AI (and for you).

Impact Point #1: The End of "Readable" Rules, Hello Mechanical Enforcement In most teams, standards lie dormant in a dusty wiki. The core philosophy of GEF is radical:

"ENGINEERING_PLAYBOOK.md is the source of absolute truth. It defines the universal rules... engineering rules should not be reread—they should be mechanically enforced."
GEF transforms passive documentation into an active technical barrier. Whether you're developing a FastAPI backend, a Next.js frontend, or a mobile application, the framework is completely agnostic. Its strength lies in its scaffolding system: it doesn't just copy files, it dynamically injects your metrics (like {{MAX_LINES}}) directly into the IDE's configuration files (.cursorrules, .windsurfrules). The Playbook thus becomes the true operating system of your project, ensuring that the AI "breathes" your rules without you ever having to repeat them.

Impact Point #2: "Hard Limits" and the Wisdom of the Boy Scout
AI isn't capable of intuitively self-moderating. Therefore, the GEF imposes strict technical limits injected into your linters (Biome, ESLint, Ruff). Depending on the criticality, the framework adjusts the parameters:
Startup/R&D Level: Speed is prioritized. Functions of 50 lines max, 4 parameters, cyclomatic complexity of 15.
Standard/Enterprise Level: The happy medium. Functions of 30 lines, 3 parameters, complexity of 10.
Mission Critical level: Absolute rigor. Functions limited to 15 lines, 2 parameters max, complexity capped at 5.
Beyond these figures, GEF imposes senior architectural hygiene. We apply the Boy Scout Rule: we clean up surrounding code during a fix without proactively refactoring the entire database. We also follow the Rule of Three: we tolerate duplication twice, but on the third instance, abstraction becomes a mandatory requirement.
Impact point #3: AI becomes your Tech Lead, not just your "code-pusher." GEF reverses the power dynamic by transforming AI into an autonomous Tech Lead governed by the principles of Clean Architecture and SOLID. The framework mandates a workflow where AI no longer simply "churns out" code; it drives the process:
Kanban Governance: The AI must identify or create a ticket via the CLI (gh issue create) before taking any action.
Architecture First: For any structural change, it is required to write an Architecture Decision Report (ADR) in docs/explanation/adr/ following the Diátaxis standard.
Separation of Concerns: It is instructed to isolate the "business" from the "infrastructure," ensuring that the domain never depends on technical implementations.
Business Intent: Each Pull Request must be prepared with a clear intent and submitted for human validation before any merge.
Impact Point #4: The "Crash Clause" or Forced Honesty
The greatest danger of an AI is its propensity for "toxic" hallucinations when it's stuck. To counter this, the GEF integrates a "Crash Clause" into its prompt system:

"When faced with a wall (unsolvable error, ambiguous instruction)... the AI must fail loudly (Fail Fast) and stop to ask for help... rather than improvising a toxic solution."
This Fail Fast approach protects the integrity of the project. By stopping as soon as the ambiguity exceeds a certain threshold, the AI avoids polluting the codebase with flawed solutions that will take you days to debug.

Impact Point #5: "Secure-by-Design" Security and Git Guardians
To achieve DORA Elite status, the GEF deploys automated security barriers inspired by OWASP:
Mechanical Security: The framework locks critical parameters. For example, the lifetime of an Access Token (JWT) is limited to 15 minutes, and Rate Limiting is enforced by default (100 requests/min). AI can no longer take dangerous shortcuts in authentication.
Git Hooks (pre-commit & pre-push): These physically block any direct commit to main. They enforce Conventional Commits including the issue ID (#XYZ) and detect secrets in plain text before they leave your machine.
CI of Intent: The continuous integration pipeline systematically rejects PRs with less than 80% test coverage or lacking a clear business logic.
Conclusion: Towards "Governed" Engineering
The Guardian Engineering Framework is not simply a productivity tool; it is a manifesto for rigorous engineering in the age of artificial intelligence. By transforming design and safety principles into automated mechanisms, it protects us from the silent pitfalls of complacency.
In the age of "Vibe Coding," are we ready to let mechanical tools protect our rigor from our own laziness—and that of our assistants? The answer lies in the first commit of your next GEF project.

I got tired of repeating engineering rules to AI on every project. So I built GEF.

Gnzikoune — Tue, 21 Jul 2026 02:23:41 +0000

For several months, I noticed the same problem with Cursor, Windsurf, and other AI assistants.

They're excellent…

but they quickly forget project rules.

At first:

clean architecture
conventional commits
documentation
tests

Then, after a few hours of development:

200-line functions
direct push to main
no ADR
forgotten documentation
ignored OWASP rules

End up, you end up repeating the same instructions:

"Use GitHub Flow"

"Don't forget the tests"

"Respect the complexity limits"

"Document this decision"

Again.

And again.

So I decided to reverse the problem.

Instead of reminding the AI of the rules…

...why not integrate them directly into the project?

This is exactly what Guardian Engineering Framework (GEF) does.

The idea

GEF is a project generator.

But unlike a simple scaffold, it also installs:

Engineering Playbook
AI prompts
Git Hooks
CI/CD
Cursor/Windsurf rules
ADR
Diátaxis documentation

right from project creation.

npx create-gef

A few minutes later, the project already has technical governance.

What is generated

GEF automatically configures:

GitHub Flow
Conventional Commits
Pull Request template
CI GitHub Actions
Docker
documentation
ADR
lint
security
AI prompts

The goal is for the project to enforce best practices, even when multiple developers or multiple AIs are involved.

An AI that acts as a Tech Lead

This is the point I find most interesting.

The framework pushes the AI to:

create ADRs
open Pull Requests
respect issues
run tests
follow a reproducible workflow

The AI is no longer just a code generator.

It follows a process.

Why it's open source

I wanted something usable with:

Cursor
Windsurf
GitHub Copilot
Claude Code

without depending on a specific IDE.

All the rules reside within the project.

Repository

GitHub:

https://github.com/Gnzikoune/GEF

NPM:

https://www.npmjs.com/package/create-gef

Feedback is welcome.

Need help!

Gnzikoune — Wed, 25 Oct 2023 14:07:36 +0000

Hello there, I have a problem with cypress. Currently I am testing an application that we are developing, it is called Business Plan. I'm carrying out tests on the financial part of our application and I'm having difficulty. My test must be carried out on the forecast financing budget at start-up. I have several fields in terms of needs such as: Total Business Creation Formalities, Total Computer Equipment, Total Furniture to name just a few. These fields must then be filled in with the amount that each requirement costs. In addition I would like to retrieve the values that the users will enter and check that the sum of these is equal to the total amount of requirements. How do I go about it since I've been running out for two days already?