“A fool with a tool is still a fool.” — often attributed to Grady Booch

I keep coming back to this quote when I watch teams adopt AI.

In my last post I wrote about shifting the engineering process left — spec sessions, autonomous agents, humans reviewing output rather than writing it. A few people asked the obvious follow-up: if an agent implements and an AI reviews, why do I need a team at all?

It’s a fair question. And I think the answer is in that quote.

The agent validates against your prompt. That’s it. If your thinking is muddled, the output will be muddled — just faster and at greater cost. An agent doesn’t tell you that you’re solving the wrong problem. It solves whatever problem you gave it, thoroughly and without complaint.

Most AI usage right now treats AI as a tool. Which means the quality of the output is bounded by the quality of the thinking that went into the prompt. A fool with a tool is still a fool. The tool just makes the foolishness more expensive.

The team is the check on intent. Not after the agent has burned three sprints on the wrong thing — before it starts.

That’s what mob planning actually is, when you think about it. Not a meeting. Not process overhead. It’s the place where bad ideas get caught before they get expensive. Where someone asks “wait, why are we building this” before an agent runs with it for a week.

But there’s something else happening in that room that I think gets underestimated.

It’s where the learning happens.

Not just prompting. System thinking. Architectural patterns. How to decompose a problem. Why a certain approach fits this codebase and another doesn’t. How a senior frames a problem before an agent ever touches it — the mental model that makes the output actually good.

Right now that knowledge isn’t transferring. Everyone is heads-down with their own tools, developing their own habits in isolation. Engineer A gets dramatically better output than engineer B. Nobody knows why. Prompting approaches are one small part of it — but the bigger part is the system thinking underneath. And that only surfaces if there’s a room where people talk through problems together before they hand them to an agent.

That conversation only exists if there’s a room to have it in.

AI is quietly doing something to teams. Everyone optimises their own workflow. Everyone gets faster individually. And the shared craft — the thing that used to live in code reviews, in pairing sessions, in hallway conversations about why the last approach didn’t work — starts to disappear.

The mob planning session gives it back. It becomes the place where system design gets discussed, where architectural decisions get challenged before the agent runs with them, where a junior watches how a senior thinks through a problem and learns something they couldn’t have learned from reading generated code. Prompting is part of that. But it’s the smaller part.

The artifact changed. The need for the room didn’t.

I don’t think teams are going away. I think the ones that skip the room will produce faster, worse work — and won’t understand why.

The ones that keep the room, and take it seriously as the place where thinking happens, will end up somewhere different.

Most teams I see have done the same thing. Handed developers access to an AI assistant and told them to move faster. Copilot in the IDE. Claude in the terminal. Pick your tool. The tickets stay the same. The process stays the same. The planning meetings stay the same. The only thing that changed is how the code gets typed.

The tool got added. The process didn’t move.

And it breaks down fast. One power user with AI can produce more code than a team can review. Two or three power users in the same team and the review process is basically gone. Nobody can keep up, and the code ships anyway.

There’s a term worth knowing here: Spec-Driven Development. The idea is that a detailed specification becomes the source of truth, not the code. Agents implement from it. Requirements change, you update the spec. AI Unified Process is one example of this in practice. It’s a sound technical approach.

But I think it stops short of the actual problem.

The spec has to come from somewhere. Someone has to write it, and someone has to agree on it. That part is still the old process, just with a new artifact at the end.

What I’d suggest looks a bit different. And it has a name most engineers already know: shift left.

Not in the testing sense. In the team sense. The collaboration moves earlier. The engineering work is now about defining what the system should do — precisely enough that an agent can run with it.

That happens in what I’d call a Spec Session. Mob planning instead of mob programming — the whole team, working on one spec. Or async — a pull request on the spec instead of on code. Review comments about intent and edge cases, not implementation. Engineers already know this workflow. The artifact is just different now.

Once the spec is agreed, the agent picks up the work. Not on anyone’s laptop — it’s sitting in your infrastructure, watching for ready tickets, the same way a CI runner watches for commits. It implements, an AI reviewer checks the output, flags what doesn’t fit, cycles back. That loop runs until it’s done. The human comes back in at the end to review the final output — not to write code in the middle.

Stacked diffs are probably the right format here. Smaller, sequential changesets the agent ships incrementally — easier to reason about, easier to review. Gergely Orosz wrote a good primer on why this workflow matters if you’re not familiar.

Ambiguous acceptance criteria used to be something a developer resolved mid-sprint. In this model they surface in the Spec Session, where the whole team can catch them. That’s the point.

I don’t think most teams are avoiding this intentionally. It’s just that changing the process is harder than adding a tool. Adding a tool has a procurement step and a license. Changing how a team thinks about its own work is a different kind of problem.

But fitting AI into an existing process gets you faster typing. The thinking stays the same depth as before.

I think the teams that treat the Spec Session as the primary engineering output — and let the loop handle the rest — will end up somewhere different.

One thing I haven’t figured out yet is what to call it. Mob Planning. Mob Specing. Spec Session. Extreme Specing. All of them borrow from XP deliberately — the idea is the same, just one level up from code. If you have a better name, I’d genuinely like to know.

I don’t know if anyone is actually running this way yet. But I want to try. Especially the part where the agent just picks up the work and runs.

Adding AI to your process makes the typing faster. Moving the engineering work to the spec — and letting the loop carry it from there — is the part that actually changes the depth of the thinking.

I talk to a lot of people right now. Exploring options, having conversations. Every person brings a different view, a different way of working. Combining all of that is genuinely fun. It also generates an unreasonable number of ideas. Hard to keep track. Hard to follow up on all of them.

So I write them down here.

No deep research. No polished arguments. Brain dumps, mostly. I use AI to help structure them — otherwise half of it would be unreadable. The ideas are mine. The shape is sometimes borrowed.

People have called me the crazy professor. Doing too many things at once. Fair. I’m working on it. The goal here is simple: short enough for between meetings, deep enough to matter, worth a conversation with peers.

Maybe something triggers a thought. Maybe it shifts a perspective. Hopefully it goes both ways.

Two small updates while I’m at it: I added GoatCounter to track visitors. Just curious. And I added Giscus for comments — some of these topics are worth discussing, and I’d rather have that conversation in the open than in a DM.

I am looking forward to this, but there is still this feeling of being lost. Before, I had goals focusing around my project, bringing it forward, moving on, increasing visibility. I am still trying to expose OpenFeature to the outside, still generating new talk ideas, pushing what OpenFeature in combination with OpenTelemetry can do. But still there is a hole, and this hole is hard to fill.

I miss my daily check-ins with fellow engineers, discussing ideas, problems, improvements. Figuring out a way to grow and to help others grow. Actively engaging with a community on a regular basis, driving topics which benefit the overall community, but with a purpose, a goal, not just for the fact of doing it. This goal is something I am currently missing.

I feel like I have achieved what I dreamed about back in the days. Ten years ago I looked up to the people speaking at conferences, doing open source, sharing their insights, driving the community. I feel like I reached that point. The question is now: what is the topic, and how will it be sustainable for me in the long run.

The community has shown me that my way of engaging, collaborating, driving, and mentoring is something valuable. The outreach and possibilities following my layoff announcement have been incredible. A lot of great opportunities, but still the bigger question remains: is this my goal, or what is my goal.

I feel like the layoff is also something really positive. I was in the comfort zone, and I was there for a long time. A comfort zone where I chose when to exit, and to what discomfort. Maybe too comfortable. As Kent Beck would call it: the Forest, where you pick what you want to work on. I see this layoff as a new way to grow. The current void is nagging me. Too scared to fully commit to being independent, unsure if I want full employment again. What will my life be after September, after this year.

For now I am trying to summarize my thoughts here. Writing feels like a nice way of reflection. And I feel like we try not to talk about the uncomfortable things that much, although everyone is sometimes in this kind of limbo. Maybe reading how others cope with it could help.

Anyways, this is my current state. If you want to grab a coffee, virtual or in-person, let me know.

Let’s see what the next months will bring. There is a lot moving. Till then, I am dancing the limbo.

That’s not a strategy. That’s noise management.

The reaction path and the reasoning path are different problems. The reasoning path needs breadth, history, correlation, anomaly detection, fleet-wide baselines. That’s where observability platforms earn their place. But the reaction path is different. Signal in, decision out. Local, low-latency, near-source. Asking one system to serve both is where the architecture gets muddy.

So what does a proper reaction path look like.

If you control the SDK, you control what gets emitted in the first place. OpenFeature can gate what your SDK emits. Evaluate a flag, and based on the result decide whether to emit a trace, increase log verbosity, enable a specific metric. The evaluation context is built from OTel semantic conventions — service name, environment, deployment version. The system already knows about itself. You’re just wiring that knowledge into the decision of what to observe next.

The system decides what to watch based on its own state. Not a human configuring a sampling rule once and forgetting about it. Not a dashboard someone checks during an incident. The loop closes at the SDK level.

And it’s cheaper. You reduce noise at the source instead of paying to ingest and filter downstream.

The primitives are all there. OTel for the signal. OpenFeature for the control. The Collector as the routing layer. The wiring between them doesn’t exist yet in any standardized form.

Maybe that’s on us. The maintainers, the spec writers, the standard builders. Making that easier to do, and harder to get wrong, is probably the next thing to work on.

Funny enough, this is the same problem I wrote about earlier this week. We don’t build software anymore — we grow it. Turns out we are still figuring out how to grow the nervous system itself.

But that’s not what agents need.

An agent doesn’t need a pretty graph. It needs data. Clean, structured, semantic data it can reason over. The entire visualization layer is overhead. And if that data has to travel through a SaaS ingest pipeline, get stored, get indexed, and then get queried, you’ve added latency, cost, and distance between your system and the thing reacting to it.

The OTel Collector already does the hard work. It filters. It batches. It samples. It enriches. It can route data directly to wherever it needs to go. Including an agent. No SaaS layer required for the reaction path.

SaaS observability isn’t wrong. For human-facing use cases it makes sense. But for a reflex arc, you want the signal close to the muscle.

The counterargument is obvious. Observability platforms already have the data, the context, the semantic layer. Why not make them the agent’s data layer too. Some vendors are betting exactly on that. And it’s not a bad bet for certain use cases — investigation, root cause analysis, post-incident review. Where you need breadth, history, and correlation across signals.

But that’s still a human-paced workflow dressed up in agent clothing. The reaction path is different. It needs low latency, minimal hops, and no dependency on external ingest availability. When your system is degrading is exactly when you don’t want your response gated on a SaaS API call.

That is probably the bigger challenge for observability companies over the next year or two. Not whether agents can reason over telemetry data. But whether the reaction path still runs through them at all. Human-facing use cases stay. The reflex arc doesn’t need the dashboard layer. Pricing models built on ingest volume will feel that.

I’ve been sitting with a different question. What if the role isn’t in the loop or on the loop, but on the system itself. Designing the thing that decides. Not intervening in decisions, but shaping the layer that makes them.

That framing leads somewhere interesting.

We grow software. Poorly. Slowly. Mostly by accident. Every pull request is a mutation. Every deployment is a generation. Every incident is selection pressure. We’ve been running evolution for years without noticing.

Living organisms solved this differently. They built nervous systems, layers that sense, layers that act, layers that maintain stability without conscious intervention. Proprioception. The organism’s awareness of its own state. Where its limbs are. What’s alive and what isn’t.

Most modern systems don’t have that. They have dashboards. They have flag states nobody queries. They have business outcomes disconnected from the behaviors that caused them.

Mauricio Salatino published something today that I keep thinking about. He calls for a “learning layer” on top of Kubernetes, one that records, synthesizes, and lets agents make grounded decisions. He ends where I always end up: unification, specs, standards. But he doesn’t name what that layer is made of.

I think we already have the ingredients.

OpenTelemetry senses. OpenFeature acts. Something in between evaluates. That’s not a dashboard. That’s a reflex arc. The organism responding to its own state without waiting for a human to read a chart.

The human isn’t in the loop. The human isn’t on the loop. The human designed the nervous system. That’s a different job. And it requires different primitives.

We’ve been building them piece by piece without knowing it. Observability. Feature flags. Platform engineering. Each built for a specific problem. Each quietly doing more than we designed it for.

They don’t add up to something yet. But I’d bet against that staying true.

And now vendors are naming it for us. Proprietary agent control layers. Closed nervous systems. The metaphor is everywhere. Most of them aren’t building on open standards.

That gap is widening.

I have a talk about this. Submitted. Not yet scheduled. But the idea needed to exist somewhere first.

This is the rough version.

Typing code is no longer the defining skill, but software engineering isn’t becoming unnecessary — the value moves up, from writing implementations to designing the systems that frame, decide, and regulate themselves.

This is a post of a series on our approaches.

1. GitLab CI - Configurations via environment variables
2. GitLab CI - Centralization Configuration

Environment Variables

The environment variables offer a good solution to define external changes. There are two was to define them, both use the same variables directive, but one allows us to define a description which will be shown in the UI when manually triggering the pipeline.

variables:
    # without description
    VARIABLE_A: "value"
    # with a description
    VARIABLE_B:
        value: "value"
        description: "description"

Using Environment Variables

Environment variables can be called by their name in a bash like manner - $VARIABLE_NAME.

We will be using our tools.gitlab-ci.yml and our .gitlab-ci.yml from our first blog post for this examples.

# tools.gitlab-ci.yml
job:
    stage: build
    image: alpine:latest
    before_script:
        - echo "some tool specific setup"
    script:
        - echo "default action"

# .gitlab-ci.yml
include:
    - local: tools.gitlab-ci.yml

For the beginning we want to just replace our echo with a variable, let’s call it ECHO.

# tools.gitlab-ci.yml
job:
    stage: build
    image: alpine:latest
    before_script:
        - echo "some tool specific setup"
    script:
        - echo "$ECHO"

Defining Environment variables

There are multiple ways how we can define the environment variables, each of them has their pros and cons. I will try to shed some light and also reveal some of the thought processes behind it.

within .gitlab-ci.yml

I would not recommend to go this way, as the user needs to have deeper knowledge of the jobs.gitlab-ci.yml. At least not fully, in later examples i will show you, how you can leverage this functionality together with the jobs.gitlab-ci.yml

Defining it within .gitlab-ci.yml can be achieved in two ways. Either we define it globally like

# .gitlab-ci.yml
variables:
    ECHO: "our echo"

include:
    - local: tools.gitlab-ci.yml

… or we define it on the job like

# .gitlab-ci.yml
include:
    - local: tools.gitlab-ci.yml

job:
    variables:
        ECHO: "our echo"

within tools.gitlab-ci.yml

When you extracted functionality into an own .gitlab-ci.yml-file, i recommend to provide either a good documentation about the options or make the extracted file as self explanatory as possible. A simple way to achieve this, is using the value and description definition for environment variables.

This might spoil the overview of your pipeline, but there are ways to bypass this, which i will show you later.

Defining it is similar to the .gitlab-ci.yml file:

# tools.gitlab-ci.yml
variables:
    ECHO: 
        value: "default echo"
        description: "this will be printed by the job"

job:
    stage: build
    image: alpine:latest
    before_script:
        - echo "some tool specific setup"
    script:
        - echo "$ECHO"

Overwriting

You also maybe want to overwrite those variables. There are a few ways we can overwrite it:

• Copy/Paste/Replace
• Overwrite and Hide

Copy/Paste/Replace

Therefore we can even combine the two ways of defining them within the .gitlab-ci.yml, and provide a better readable and described variable for our run dialog.

# .gitlab-ci.yml
variables:
    ECHO: 
        value: "our echo"
        description: "this will be printed by the job now as we overwrite it"

include:
    - local: tools.gitlab-ci.yml

This will still show this information on the run pipeline-form.

Overwrite and Hide

The first approach showed us, how we can copy, paste and replace this information. Maybe we want to not “spoil” our form, as we do not need to manipulate it anyways.

If not we are provided with simple tools and replace the definition with the first version.

# .gitlab-ci.yml
variables:
    ECHO: "our echo"

include:
    - local: tools.gitlab-ci.yml

Hiding extracted environment variables

Sometimes we are fine with the default values and do not want to show any information about this variable within the run pipeline-form.

For smaller includes this can be easy, as the number of environment variables is small.

# .gitlab-ci.yml
variables:
    ECHO:
        description: ""

include:
    - local: tools.gitlab-ci.yml

But it again forces the user to have prior knowledge of his include, or if the include changes to also maintain his own build.

with an own file

As we were facing this regularly we came up with a small hack. For each of our includes, we provide a second include, with the sole purpose of hiding the variables. Besides the effect of hiding the variables, we are also able to provide additional information of the basic include to the user.

You might be wondering how we name this file and what the content is. We named it tools.hide.gitlab-ci.yml and it just copies the environment variables of tools.gitlab-ci.yml but replaces the description.

# tools.hide.gitlab-ci.yml
variables:
    ECHO:
        description: ""

The include within the .gitlab-ci.yml file is working the same way. Now somebody can actively turn the description on and off if needed.

# .gitlab-ci.yml
include:
    - local: 
        - tools.gitlab-ci.yml
        - tools.hide.gitlab-ci.yml

Conclusion

It is easy to provide some kind of configuration to the user. It is also fairly easy to document them and make it visible within the pipeline. Also with our hack it is easy to hide them, if they are not needed.

Word of Advice

Those are highly opinionated solutions, which are covering our use cases. They might not be the ideal fit for your solution. But I hope they offer inspiration.

This is a post of a series on our approaches.

1. GitLab CI - Configurations via environment variables
2. GitLab CI - Centralization Configuration

Centralized Configuration

The idea of generalizing configuration or of loading from a different repository was born due to a simple need - or own custom tools. Sometimes our tools do have their own build images and need their own build step, which is a lot of prior knowledge if you just want to apply them to your project and use them.

Therefore we decided to move the CI definitions for those files into own projects or to the build image project. The benefits are:

• lifecycle of job definition and tool are unified.

  If a project updates the job definitions, they will also use the appropriate image linked to it.

• User does not need to know internals of tool

  The user has a simple way to use the tool within his CI. There is no prior logic needed, but if there is the need, it allows manipulation from the outside.

• We can provide versioned updates for tool and job definition

So how those this work?

We will be working within one repository to show this functionality, but it is not much effort to change this to multiple projects. Additionally we use the assumption that alpine:latest is our own docker image build tool :).

A normal .gitlab-ci.yml looks like:

job:
    stage: stage
    image: alpine:latest
    before_script:
        - echo "some tool specific setup"
    script:
        - echo "default action"

Our user is quiet unhappy, because he needs to write all those lines, just for doing the default action. Also he has to know about all those things upfront. Furthermore if the tool implementation changes are changing he also need to be aware of that.

For easier usage, we need to

1. extract the job definition
2. apply the extracted job definition

Extraction into own CI file

Instead we can extract this whole job definition into our own tools.gitlab-ci.yml which will look like exactly within the .gitlab-ci.yml

job:
    stage: build
    image: alpine:latest
    before_script:
        - echo "some tool specific setup"
    script:
        - echo "default action"

Usage of extracted file

To use the newly created tools.gitlab-ci.yml we need to include it within our build.

include:
    - local: tools.gitlab-ci.yml

Voila the first step is done. We centralized the configuration into an own file!

Change the action

As mentioned earlier, we also want to offer the user the possibility to change this definition. Luckily GitLab got us covered here. They over a really great merging of those yml-files and in the end they are combined.

This allows us to reuse the same definition and just override parts of it within our .gitlab-ci.yml

include:
    - local: tools.gitlab-ci.yml

job:
    stage: test
    script:
        - echo "do this instead"

Conclusion

Extracting functionality into an own file is easy. Using extracted functionality is also not that hard. Modifying extracted functionality works also like a charm.

Word of advise

This seems to be great functionality and offers a lot of DRY possibilities. I still urge you to evaluate what you try to reduce and how the user perspective is. It is nice if it is DRY, but it can still be really confusing for the user.

Fixed topics

Misconception

I was not careful enough when reading the GitLab Documentation regarding Gradle and the GitLab Package Registry. It turns out, that you are able to download from two different endpoints:

• Group endpoint: <url>/api/v4/groups/<groupId>/-/packages/maven
• Project endpoint: <url>/api/v4/projects/<projectId>/packages/maven

Also logical you can only upload to one, the project endpoint. My previous implementation did not cover projects at all. Therefore i now deprecated my first API endpoint maven(args). Instead i offer now a groups(args) and a projects(args) endpoint.

Upload

Together with the misconception this was also the reason, why upload did not work. As we still need to somehow provide where we want those repositories to be added, i am currently still stuck with .upload(owner, 'projectId'). But finally it works, and we are at a usable state.

Plans for the Future

Simply said, reduce complexity and make it more elegant. Currently there is too much code in the plugin from trial and error. I think it is cluttered, it is missing structure, and it is confusing as hell.

DSL-like API

My way of configuring the plugin is not ideal. It works, but it could be better and in a nicer groovy way. I will change it to a DSL-like API.

The benefit is within the lazy evaluation, which might be beneficiary. Although currently there is not much to gain, as the configuration is happening during the evaluation anyways, and not when the task is executed.

Hand over from Settings to Projects

The current way is a little bit clumsy and suboptimal - fetching, recreation, applying, etc.

I would love to clean this up, make it more concise and easier to grasp.

Currently I also think that some of those limitations might be also caused by my need to support Gradle 4.10.3. If my understandings are correct, i can remove this handover of artifacts to the projects in the future. As soon as i can drop support of 4.10.3 - the question is, if i leave the functionality, but just ignore it in that case.

How we add repositories

Currently the plugin is applied in two different ways:

• Downloading: Here I rely on the information at hand when the plugin is applied. I store the repositories of the ExtensionAware-Object which was used to instantiate the extension. This works fine for the dependency repositories, but also limits it to just them
• Uploading: Here we pass on the owner and use this information to add the repositories. I do not like this because it adds complexity to the API.

I try now to investigate, how i can maybe unify the API and reduce complexity.

1. Ideally i manage to add a method to the DefaultRepositoryHandler but this seems to be a hard task.
2. Alternatively i could change the way the repositories are applied and return the Action instead of adding it within the plugin.

repositories {
    // Current way
    gitLab.groups('groupId')
    // 1. if i manage to extend DefaultRepositoryHandler
    gitLabGroups('groupId')
    // 2. not having influence on where it is added
    maven gitLab.groups('groupId')
}