When using a Coding Agent, any project needs its own layer on top of it: the project harness.

This article presents a simple taxonomy for its components, openly inspired from Harness engineering for coding agent users article: Guide, Sensors, Quality Gates and Maintenance Tasks.

The economics changed

In 2024, AI-assisted coding cost a few dollars per month per engineer.
Flat subscription were the norm, GitHub had Premium Request.

In 2026, serious agentic coding session can consume
$100 to $200 in tokens. That is per engineer, per day.
Flat plans are disappearing or highly limited,
without access to some models.

The relevant metric is no longer “lines of code AI generates”
but outcome per token:
how much verifiable engineering value
each dollar of model inference produces.

Optimising tokens consumption,
ensuring heavy agentic development workflow delivers
real value means Project has to keep the coding agent
under tight control.

SDD frameworks try to make this part is easy,
but I do not agree this should be outsourced.
Projects have to own their Harness and
then SDD frameworks, even Plan mode, will use it.

Guides and sensors

The Project Harness has two types of components:

• Guides: shape agent behavor before execution.
  They are feedforward:
  rules and context the agent reads before writing any code.
• Sensors: detect deviation after execution.
  They are feedback: signals the agent processes
  to decide whether its output meets the project’s standards.

Each type can be computational or inferential:

Computational sensors are deterministic, fast, and cheap.

Inferential sensors use LLM calls: probabilistic, slower, and more expensive, but they catch semantic problems that scripts cannot.

For instance, AGENTS.md file is now widely supported and used, and should be a map of the important technologies, entrypoints, mandatory quality gates, pointers to conventions, guidelines, ADRs.

Keep it strictly tight, less than 200 lines for complex projects, 50 lines for simpler ones.

# AGENTS.md for My Project

## Commands

- Available commands: `just help`
- Install: `just dev`
- Run checks: `just check`
- Preflight validation: `just preflight`

## Constitution

See `CONSTITUTION.md` for inviolable rules.

## Guidelines

- REST API: `.agents/guidelines/rest-api.guideline.md`
- Commit messages: `.agents/guidelines/commits.guideline.md`

AGENTS.md will be always in context, and resist compaction.

It is the minimal onboarding document that your agentic consultant
gets at each session.
It gives the important informations to always know and pointers.

Other types of in project guides:

• CONSTITUTION.md: inviolable modification rules of the project
• Guidelines: reusable rules accross project, pointed by AGENTS.md.
• ADR: Architecture Decision Record
• Skills: project specific capabilities.

Quality gates

Guides tell the agent what to before coding.
Sensors tell the agent what went wrong after.

Quality gates are when these sensors fire.

A quality gate blocks the agent from proceeding
until all attached sensors pass.

The simplest gate pattern can be called the “preflight check”: a single target (e.g. just preflight) that run all computational sensors: linting, type checking, unit tests, documentation generation, build, ...

The agent is instructed (in AGENTS.md or hook) to run it after every task.
Failures feed directly into the agent's context as structured error output.
The agent reads the errors and fixes them before moving on.

When project grows, the “preflight” campaign can become too slow, taking more and more time and slowing down the complete agentic coding loop. For these complex workflows, several gates can be defined with different sensors, each with different scope, execution cost.

Here is an example of a complex autonomous coding workflow:

Each level runs less frequently but catches broader problems:

• Task gate fire after every change. They run only computational sensors: lint, type checks, tests. They need to be fast (<5 min) and deterministic.
• Phase gate fire after a group of related tasks. For instance, they can run the full e2e campaign, or the complete unit test suite
  if selection logic was used at the task gate to accelerate execution.
• At the end of development gate, the most complete performance tests run.
• CI gate fire after a push, and can allow agent to automatically fix minor issues when the Pull/Merge request is run in CI environment.
• Agentic Code Review gatecan be triggered when MR/PR is created, a gate can allow the local coding workflow to directly react to agentic review (CodeRabbit, …)

Final Human review happens at the end, and verifies the complete outcome of the session (code, implementation reports, quality metrics,…)

For instance, you can have a ‘CI feedback loop’ skill to allow fixing CI failures:

Gates are organised in a cost hierarchy. Computational sensors should be prefered over Inferential sensors but the later allow catching issues no amount of scripts can detect.

Engineering expertise is important to design these quality gates to balance between efficiency and accuracy.

Computational sensors should be prefered over Inferential sensors, but the later allow catching issues no amount of scripts can detect.

But letting the agent select its own checks is a recipe for failure: LLM will cheat.

This has to be carefully designed by the project. Engineering expertise is important to manage these quality gates, find the right balance between efficiency and accuracy.

Structural checks

For important structural rules, agents might still silently violate guidelines even with careful planning.

Use the coding agent to write its own structural checks and add it into a Quality Gate.

For example, let’s say you have a Guideline that declares:

Module interaction rules:
- `cli` can import `api`, `res`, `lib`, and `utils`
- `api` can import `lib`, `res`, and `utils`
- `lib` can import `res` and `utils`
...

This rule can be easily verified by a dedicate, project-specific script.

Wire it into the preflight target. On error, display a clear message
to explain to the agent what needs to be fixed.

More complex structural rules might require to trigger a specific agent (“Inspector”).

Entropy fights back

Even with a strong harness, drift will accumulate silently, and entropy will slowly build up in the project.

Regular, off-cycle maintenance tasks can help control this drift:

• Harness gardening — review AGENTS.md, guidelines, quality gates structure for drift and performance, remove rules that no longer apply, and tighten rules that agents routinely violate.
• Documentation gardening — prune dead links, stale ADRs,
  and obsolete glossary entries. An agent can scan recent code changes
  and detect gaps in documentation.
• Dependency/Vulnerability updates — bump libraries
  and verify that quality gates still pass.
  This is a maintenance task that agents handle well, even when minor changes are required.

Another good practice to set up is to consolidate feedback from coding agent itself on what when wrong during a session, in markdown, that can be compiled later into a specific “Harness Improvement Session”

Conclusion

Harness engineering exists because LLMs have hard limitations.

The context window is finite, sessions are stateless, output is probabilistic.
And especially inference now become extremely expensive.

The harness is how you work within these constraints instead of pretending they do not exist.

This article presented a very high level overview of how to organize guides to keep the context lean, how to use sensors in quality gates in your project to catch the mistakes that agent will make, and why setting up regular Maintenance Agentic Tasks allows to keep small harness drift under control.

TL;DR: This article presents Gitlab-Project-Configurator (GPC) proudly released under MIT License by Groupe Renault. GPC is a “configuration as code” tool used internally to align settings of hundreds of Gitlab projects and groups.

Gitlab is a great tool to store your code and run Continuous Integration Pipelines on it. It works fine for personal projects and is also a great tool for corporations as their main repository for source code.

It is even greater at experimenting new ways of doing things, project creation is easy (and it should be easy).

But as project number grows, managing them becomes harder and harder. Doing everything in the UI is great, but things get a bit harder when you want to apply the same settings to every projects in a single group.

It would be much scalable to write down the wanted settings for projects (and groups) in files and apply them automatically, using the Infrastructure as Code principle (or more precisely, “Configuration as Code”).

Let’s start by an example

Let’s say we would like for a specific group to set all their project with the setting “Fast-forward merge”. Not the whole Gitlab instance, not only a few projects. Maybe a few hundreds of them.

And with some exceptions, let’s say in the middle of all of our project we have one where we do not want this settings applied for some obscure reason.

We can manage to use the API ourself, thanks to the amazing Python-Gitlab module. But if we add another settings, a few other exceptions, and we will finally end up with a really hardcoded script, hardly maintainable, and that cannot be used on other situations.

Introducing Gitlab Project Configurator

When we started really scaling up our usage of Gitlab, we wanted to ensure that we had a way to align some project settings following the “as code” paradigm:

• configuration is described in a text file
• evolution of the configuration must be tracked like any other software change, ie, in Merge Requests
• tracking who did a change, when and why is extremely important.
  The git history provides it directly.

We tried to work with GitlabForm at the end 2018, but we were not able to do what we wanted with it:

• we want to define a set of logically-related settings in “rules” or “policies”
• several rules can be defined and inherit from each other
• rules are to be applied on some specific projects, or on all projects of a Gitlab group, or matching a regular expression.

Sometime a “generic” rule to be applied to a project needs some kind of customization.

Let’s say you want to configure 3 projects (P1, P2, P3) in a group with the following settings that all projects would follow:

• merge method set to fast-forward
• define a variable “MY_VARIABLE” with a specific value “MY_VAL”

But, one of the project (P3) is already using the variable “MY_VARIABLE” with another value “OTHER_VAL”, and changing may have side-effects.

So, we may want to apply these settings to P1 and P2, but on P3 to keep previous variable value for the moment. This becomes a “Technical Debt” which can be reimbursed later. This is an option often chosen when deadlines approaches.

That’s why we created Gitlab-Project-Configurator, allowing to apply precisely project and group settings, with lot of possible customization.

GPC is command line tool, written in Python, that will take a description of what you want to set on Gitlab’s projects and group, and apply as much as possible. Key features are:

• Security: all the configuration are centralized and it is easy to update credentials or password used in multiple projects.
• Traceability: If someone manually modify a setting manage by GPC, modified settings will appear in the GPC report.
• Reliability: GPC will apply settings defined in configuration files, and help to align multiple projects settings.
• Dry-Run: GPC can run in “dry-run” mode, for example in a merge request, and it will report what will be changed, but without applying the settings. This allow users to review and verify changes before applying the settings.
• Reports: GPC provides reports (HTML, email) of what has been done, and what failed, so post-mortem is easily done.

The main way to use GPC is by using the docker image provided by the project and run it directly on your project:

image: registry.gitlab.com/grouperenault/gitlab-project-configurator:latest

Note: This command will only work on gitlab.com server.

How it works?

Rules Definition

Rules are defined in one or several files.

This is where you describe which settings your project should follow.

For example: all projects of my team should have a default branch named ‘master’, protected and only allowed to merge (no one can “push on it”), with all tags protected.

And so on.

Derivative rules

Then we can imagine a derivative of this base rule that adds a badge and define other rules.

Apply rules on projects

Next step is to apply these rules on projects.

A special keyword named custom_rules allows to add exception to the rules you want to apply. It is probably a good idea to add comment on why this exception needs to be done in this case.

Our experience shows that when transitioning from a completely freely managed project to a project managed under GPC, we often faced situations where we wanted to do only parts of the migration at a given moment: either all variables cannot be migrated to GPC yet, or it raises some minor incompatibilities on some projects that would require manual changes.

But when migrating hundreds of projects at once, we were happy to use some carefully crafted custom_rules for a few days or weeks until this technical debt can be reimbursed while keeping or release schedules untouched.

Recommendations

We have a few recommendation when using GPC:

• you need to store your settings in a private project.
• Add a schedule to apply your change on a regular basis. We apply our change twice a day, so if someone alter some project settings under GPC, we know it will only last for a few hours before the settings are reset.

Project Information

Gitlab-Project-Configurator is released under MIT license starting by version number 3.0.0. We chose to maintain the main codebase in a private Renault repository, and perform an automated synchronization with the Opensource project on a regular basis. We do not have any Renault-specific features, only intensive integrations tests still heavily customized and some internal configuration files.

The open source version is automatically updated using a CopyBara script.

We are looking forward to contribution, and they will be merged internally first before being published back to open-source project, maintaining the original commit authorship.

You can have a look at a live demo project here.

The main documentation is accessible here.

Introducing Gitlab Project Configurator was originally published in grouperenault on Medium, where people are continuing the conversation by highlighting and responding to this story.

I assume the reader of this article knows most common Continuous Integration (CI) technics, knows Kubernetes concepts, especially namespaces and RBAC, knows the basic Helm concepts, like Tiller, Chart and value files are.

Kubernetes makes it easy to deploy simple applications even with kubectl command line tool only. But things get more complex in real life, once RBAC is enabled in the cluster, or when several “flavors” of the same applications needs to be deployed (say, a “prod” and a “staging”). Something you may even want to create your own, on-demand environment to test your contribution.

Enters Helm, that, for me, gives a satisfying answer to our needs for deploying production-level applications.

But first, I need to clarify what I mean by “Helm gives satisfying answer”. Helm is not just the command line tool you can download from https://github.com/helm/helm/releases.

For me, “Helm” is all of the following points:

• the command line tool,
• the Chart and its weird templating syntax (1),
• the excellent Helm Charts available at helm/charts, that provides an reference database,
• the documentation at helm.sh/docs, that provides not only the description on how the Helm tool works, but also gives the best practices on how to write a high quality Chart,
• of course, the best friend of the helm command line tool: Tiller.

Tiller is, sadly, the unloved friend of Helm. It is a small pod that is set to be always up and running inside your Kubernetes cluster and will accept the deployment requests (Chart + values) from the “helm” CLI, either from your development environment or your CI. If you want more control on it you can start one Tiller per namespace, or per team. But still it can do lot of damages if left unsecured.

Tiller can assist Kubernetes itself during some operations, like the rolling update of applications, providing features that Kubernetes does not provide yet: for example, redeploying all the pods that use a given ConfigMap, when this one is updated. This requires some tricks with Helm, but at the end, it does the job.

But like said a few lines ago, having a special pod inside the Cluster that can alter almost anything inside it on-demand is a great security concern. You need to secure your Helm installation for production, but it could be complex. It basically requires the following 4 steps:

• enabling RBAC in your cluster
• use secret to store Tiller configuration instead of ConfigMap
• secure the Tiller gRPC endpoint by enabling TLS
• install one Tiller per team

Creating TLS certificate can be seen as a redundancy of RBAC configuration, since it means you rely on a service account linked to a RoleBind with enough permission to perform any action.

But the most important flaw of this method is that is yet another process to set up, that needs to be well understood and mastered in order not to have, in the end, less security than without RBAC.

And we already have done all this hard work of securing the connection to our Kubernetes cluster with RBAC. It provides everything that we need.

And it communicates through HTTP(S). gRPC is cool, but it makes things a little bit harder. For example, you can be in a case where you might not have easy access from outside your cluster to any service that uses ClusterIP, like… Tiller itself… so without any special trick, you cannot execute any helm command from outside the cluster… and so this special trick needs to be secured as well… again, ANOTHER security process to set up).

Enough is enough, let’s use only the Kubernetes API as sole and unique connectivity to Kubernetes.

We will also use the service account that already has Certificate Authority and a token, and we can use them to authenticate our deployment from our CI.

Securing deployment using Tillerless Helm

We will set up a secured “Tillerless” solution that follow this structure.

1. RBAC is of course well configured in your cluster
2. Helm deployment information are stored as Kubernetes Secret
3. Have one service linked with role binding per user, team, or other organizational entity
4. We will use the service account token to authenticate our CI job

The huge advantage of this process if that we only use the Kubernetes API to communicate from our CI. This also means you have kubectl alongside your helm commands in your CI and both will share the same security configuration.

It is expected that the future version of Helm, Helm v3, to work a little bit like this.

Using the latest version of Helm v2, you can still simulate this behavior with the excellent “Helm-Tiller” plugin for Helm: https://github.com/rimusz/helm-tiller. You can even use it in your CI. What it does is it can start install and run a background Tiller process on your development environment (or CI).

Connection to the Kubernetes API with the service account token

You need to have a service account, for example named “tiller-sa”, in your namespace. Please ensure the Role Binding has the minimum permission possible, restricted to only the target namespace of your application. If for any reason, the service account get compromised, you need to limit as much as possible the blast radius.

Here is an example of the “tiller-sa” role:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: tiller-sa
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["*"]
  verbs: ["*"]

And its matching RoleBinding to the service accound “tiller-sa”:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: tiller-sa-binding
subjects:
- kind: ServiceAccount
  name: tiller-sa
roleRef:
  kind: Role
  name: tiller-sa
  apiGroup: rbac.authorization.k8s.io

If you use helm-tiller plugin, you will see it automatically download the tiller executable matching your helm version, in “~/.helm/plugin/tiller/bin/tiller”.

But first, we need to set up the connection to the cluster. For example, on your development environment, you can rely directly on your RBAC configuration. You can use the Helm-tiller plugin directly.

But in our CI, we will use the service account token.

Just copy the token and ca.crt from the secret linked to the service account (you can find interesting functions here for that), and store it as secret environment variables in your CI, alongside some other environment variables we need to define:

• $TILLER_SA_NAME: name of the service account. In our example, it is “tiller-sa”,
• $TILLER_SA_CA_CRT: the content of ca.crt found in the secret related to the service account,
• $TILLER_SA_TOKEN: the content of the token found in the secret related to the service account,
• $TARGET_NAMESPACE: namespace where you want to deploy your application. Your service account must have the right role to deploy anything in it
• $CLUSTER_URL: the URL to your cluster.

In your CI job, simply execute the follow snippet to configure kubectl.

$ echo $TILLER_SA_CA_CRT > /etc/kube/ca.crt
$ export KUBE_CONFIG=/etc/kube
$ kubectl config set-cluster sa-cluster \
    --server=$CLUSTER_URL \
    --certificate-authority=/etc/kube/ca.crt
$ kubectl config set-credentials sa-user \
    --token=$TILLER_SA_TOKEN
$ kubectl config set-context sa-context \
    --cluster=sa-cluster \
    --user=sa-user \
    --namespace $TARGET_NAMESPACE
$ kubectl config use-context sa-context

Test your connection to the cluster:

$ kubectl get pods --namespace $TARGET_NAMESPACE

If everything if fine, this means your CI job can access to the Kubernetes API using the Service Account Token. Great, now let’s start the real fun: Tillerless helming your application with a background tiller task.

Tillerless Helming

Instead of running Tiller inside the cluster, you will start it as a background job in your CI job. “Tillerless helm” only means running it on “localhost:44140”.

I consider you have set up the Helm-Tiller plugin in your CI.

You can use the “start-ci” command plugin with a bunch of environment variable, the one I recommend are:

$ export HELM_TILLER_HISTORY_MAX=20
$ export CREATE_NAMESPACE_IF_MISSING=false
$ export HELM_TILLER_STORAGE=secret
$ helm tiller start-ci $TARGET_NAMESPACE

Or if you want to start the process manually:

$ ~/.helm/plugin/tiller/bin/tiller \
    --storage=secret
$ helm init \
    --client-only \
    --wait \
    --history-max 20

Note that you do not link Tiller to a service account like when it is set up inside the cluster. Since Tiller is now running as background task in your CI, it will directly use the Kubernetes API, through your already configured Kube config file.

Now you can use helm as usual. Except, remember, you need to specify “--wait” at each command to tiller:

$ helm upgrade --wait --install ...

In bonus, you now see the tiller’s log during your deployment.

You can even execute any kubectl command you might want in your CI, such as:

$ kubectl get pods

Simply ensure to kill the tiller background after everything:

$ helm tiller stop

Usage in Gitlab CI

If you use Gitlab CI, you need to make sure to kill manually the background process at the end of your deployment, of your job will be stuck forever. There is a special trick to be able to use a bash trap in your job. Or you can starts/stops tiller before/after each command with:

helm tiller run $TARGET_NAMESPACE helm upgrade --wait ...

This article is an adaptation of the following articles:

• How to setup helm and tiller with RBAC and namespaces
• Helm Basics — Using Tillerless
• The How and Why Behind Tiller-less Helm

My name is Gaetan Semet, and I work on a daily basis with Kubernetes. I am the maintainer of the Airflow Chart.

[1] I can have lot of complain about the flaws of Go Templating, for example the stupid boolean operations syntax. Ok, Helm is not only a template engine. I don’t really know if Jinja2 is the original or the copy, but to be honest Jinja is so much better.