DEV Community: m8a.io

The Ball and Chain: Why Git is an Anti-Pattern for AI-Native Engineering

Scott Molinari — Sat, 07 Feb 2026 11:10:40 +0000

In our previous discussions on The Human-Centric AI-Native Distributed Systems Manifesto and Intent Driven Development (IDD), we established a clear vision: the future of software belongs to Architects of Intent, not laborers of syntax.

But there is a problem. A massive, silent friction point is dragging us backward.

We are attempting to build fluid, intent-driven, AI-generated systems, but we are storing them in a rigid, line-based history tool designed in 2005 for the Linux Kernel. We are trying to fly a starship with a steering wheel made of stone.

It is time to say the quiet part out loud: Git is becoming the bottleneck of the AI Era.

To fully realize the promise of Intent Driven Development, we cannot continue treating Git as the engine of our engineering. We must recognize it for what it truly is: a legacy file system that doesn't understand logic.

The "Text-Blind" Problem

Git is a marvel of engineering, but it is fundamentally "dumb." It sees the world in lines of text.

If you rename a function in auth.ts from loginUser to authenticateUser, Git sees this as:

- loginUser(creds)
+ authenticateUser(creds)

Git does not know you refactored a symbol. It only knows you deleted a line and added a line. It sees text; it does not see Logic.

For human-to-human collaboration, this was acceptable. We could read the diff and infer the intent. But in an AI-native world, this "text-blindness" creates a critical disconnect.

In a true AI-Native development environment, the AI shouldn't just look at a flat directory of files. It needs to operate on a System Graph. It must understand the relationships between things—not just their proximity in a file. It needs to know that the User object is semantically connected to the Billing service.

If the AI modifies the User object, it isn't just editing text; it is propagating a ripple effect of logical changes across the entire graph. When we force that rich, multi-dimensional logic into a flat, line-based diff, we are downsampling the intelligence of our system. We are taking a 3D model and smashing it into a 2D drawing. We lose the "Why" (The Intent) and keep only the "What" (The Text).

In other words, we continue to use Git, we suffer from a Cognitive Impedance Mismatch. We take a high-fidelity concept (The Intent) and force it through a low-fidelity medium (The Text File). Then, every time a human or an AI needs to reason about the system, they must burn energy trying to reconstruct the original architectural picture from thousands of lines of syntax. This is a massive waste of computational power and human intellect. We are throwing away the map, shredding it into strips of paper, and then trying to tape it back together every single day.

The Merge Conflict is a Syntax Error, Not a Logic Error

The ultimate symptom of this mismatch is the Merge Conflict.

In a distributed system where multiple agents (human or AI) are working on different Intents simultaneously— say, "Integrate Stripe Payments" and "Enforce Age Verification"— Git often fails to merge them simply because they touched adjacent lines of code.

These conflicts are artificial. Logically, the two changes might be perfectly compatible. But because Git manages Files instead of Functions, it throws a conflict.

We spend hours of our lives resolving these text-based collisions. In an IDD world, this is wasted life. We should be resolving Logical Conflicts, not text conflicts.

A logical conflict looks like this: "You cannot remove the 'Email Address' field from the User object because the 'Send Receipt' intent explicitly relies on it."

That is a valuable conflict. That protects the business. Git cannot see that conflict; it can only see that two people edited line 45.

The Database Must Become the Repo

If Git is the "Assembly Language" of version control, what is the high-level language?

The logical evolution is Database-as-Code.

In an AI-Native future, the "Source Code" cannot remain a folder of text files on a hard drive. It must become structured, versioned data in a Temporal Database.

If you aren't familiar with the term, a "Temporal Database" is simply a database that has a built-in concept of Time. It doesn't just store the current value of a record; it stores the entire history of how that record changed. It is like a Time Machine for your data.

Imagine a world where:

Granularity is Logical: You don't version a "File." You version a Node, a Function, or a Policy.
History is Queryable: You don't ask "What changed in this file?" You query: "Show me the exact state of the 'Billing Logic' as it existed last Tuesday."
Refactoring is Instant: If you rename a verified business concept, the system updates the pointer in the database. There is no "Search and Replace." There is no diff. The entity simply evolves.

This is the architectural reality we need to support Intent Driven Development.

If the AI generates the implementation, why do we need to store the implementation in a text file? We don't. We need to store the Intent (The Horizon Node) and the Verification Policy (The Test). The implementation code is just a compiled artifact—a transient output that serves the intent.

The "Ball and Chain" of Transparency

So, do we kill Git?

Not yet. And this is the paradox.

We cannot abandon Git today because it is the Universal Protocol of Trust. It is our audit log, our backup, and our "break glass in case of emergency" tool. Developers (rightfully) fear vendor lock-in. If the code lives in a proprietary database, they feel trapped.

But we must change our relationship with it.

Git must become the Display, not the Engine.

In this new architectural vision, the Database is the Source of Truth. It holds the rich, structured, intent-based graph of your application. Git becomes a Projection—a mirror. The system automatically syncs the state of the database to a Git repository so you have a human-readable backup.

But the work—the actual engineering—happens in the Graph, in the Intent, and in the Policy.

Moving from "Commits" to "Intents"

This shift allows us to finally clean up the history of our software.

We have all seen a Git log that looks like this:

fix typo
update styling
trying to fix build again
wip

This is noise. It is the frantic scribbling of a human trying to make a machine work.

In an Intent-Based future, we stop caring about the scribbles. We care about the Completed Horizon.

Intent: "Implement GDPR Compliance."
Status: Verified & Sealed.

The "Commit" is too small a unit of measure for a business. The Intent is the atomic unit of value. By moving the "Source of Truth" to a database backed system that understands these high-level concepts, we can finally have a history log that reads like a story of business evolution, not a transcript of syntax errors.

Conclusion: Let Go of the Files

The transition to IDD requires us to let go of our security blankets. For decades, the text file was our safety. If we had the file, we had the power.

But in the age of AI, the power is no longer in the text of the code. The power is in the Context, the Constraint, and the Intent.

Yes, these are still written in text — of course, language is how we define meaning — but that text represents high-level Abstractions, not low-level machine instructions.

Git served us well in the era of manual coding. It was the perfect tool for the "Human Compiler." But as we ascend to become Architects, we need tools that understand the architecture, not just the bricks.

It is time to stop managing lines, and start managing logic.

Intent Driven Development (IDD) is our Current Future

Scott Molinari — Thu, 29 Jan 2026 08:36:54 +0000

For decades, the measure of a software engineer was their command of syntax. We spent our careers acting as human compilers, translating business requirements into machine code, line by painstaking line. But as we transition into the AI-native era, that metric is shifting. We are moving away from a world where we focus on how to implement a feature, and into a world where we focus entirely on what that feature is intended to accomplish.

In our Human-centric AI-Native Distributed Systems Manifesto (if you haven't read it yet, please do), we outlined a future where we prioritize "Verifiable Intent over Syntactic Correctness." To ground this philosophy in reality, we need a new operating model. We need to move beyond the traditional boundaries of Domain Driven Design and Test Driven Development.

We need Intent Driven Development (IDD).

The Inescapable Reality of Distributed Systems

To understand why IDD is necessary, we must first accept the current state of the global economy. It is no longer possible to conduct significant business today without applications that are, in some manner, distributed. The era of the "isolated application" is dead.

Whether you are a logistics giant or a local fintech startup, your digital footprint is inherently fragmented. You are consuming APIs from payment providers, syncing data to mobile devices, replicating databases across regions for latency, and relying on third-party authentication services. "No application is an island," as our manifesto states. Every piece of logic exists within a complex, fragile web of dependencies, network latency, and eventual consistency.

This complexity creates a dangerous trap. As systems become more distributed, the cognitive load required to maintain them explodes. If we rely solely on manual coding, we move too slowly to compete. But if we recklessly hand the keys to an AI, we invite chaos. An AI can write a function that works perfectly in isolation on a developer’s laptop but fails catastrophically when introduced to the latency of a real-world network.

This is where IDD becomes the critical bridge.

The Engine of Intent

Intent Driven Development is the natural evolution of software engineering, accelerated by the "engine" of Artificial Intelligence. In an IDD workflow, the engineer’s primary responsibility shifts from being the manual laborer laying every brick to becoming the Architect defining the destination.

In the past, methodologies like Domain Driven Design (DDD) gave us the vocabulary—the maps of our system—but still required us to manually write the glue code to make those words interact. Test Driven Development (TDD) gave us verification, but required us to write "intent" buried inside unit tests that were often as complex as the code they were testing.

IDD elevates these concepts. DDD becomes the strict Schema that prevents the AI from hallucinating business concepts. TDD becomes Policy Verification, where we define high-level behavioral contracts, and the AI navigates the route to satisfy them.

So, What is IDD?

We have established the philosophy, but how does Intent Driven Development manifest in a daily engineering workflow?

IDD is an "Implementation-Last" methodology.

In traditional software development, we spend 80% of our time writing the implementation and 20% verifying it. IDD flips this ratio. We spend 80% of our time defining the Constraints and the Verification, and we let the AI handle the implementation in the seconds remaining. Specifically, IDD is a three-stage lifecycle:

1. The Definition Phase (The Human Context)
This is where the "Intent" is crystallized. Before a single line of executable code is written, the human engineer constructs the "Immutable Skeleton." This is not a vague prompt like "Make a user system." It is a rigorous set of artifacts:

The Contract (Schema): You define the exact input and output.

The Environmental Constraints: You explicitly select the technology (e.g., Vue, NestJS and MongoDB, or Angular, Spring Boot, and MySQL, etc. etc.). We call these "Foundries" in m8a.

The Behavioral Policy: Instead of writing code, you write the criteria for success (e.g., "Must retry 3 times with exponential backoff").

2. The Generation Phase (The AI Engine)
Once the Skeleton and Policy are locked, the AI is engaged. It is tasked with filling the void between the Input Contract and the Output Contract. Because the AI is constrained by your pre-selected stack and pre-defined business rules, it generates the boilerplate and logic required to satisfy your intent without "guessing."

3. The Verification Phase (The Automated Judge)
This is where "Verifiable Intent" supersedes "Syntactic Correctness." As soon as the AI generates the code, the system runs the Policy Tests. If the output fails the Schema or the Behavior check, it is rejected and regenerated. The human only reviews the solution that has already proven it meets the intent.

The "Intent File"

To make this concrete, IDD relies on a tangible "Intent File."

We are already seeing primitive shadows of this in the developer community today. Many developers are now adding files like CLAUDE.md or GEMINI.md to their repositories to "prep" the AI with context. While this is a step in the right direction, these local files are severely limited. They are static snapshots that only understand the code sitting next to them in the folder; they lack the global awareness of the living system. They are passive suggestions, not active architectural drivers.

In true IDD, the "Intent File" is not limited to a rigid format like YAML, JSON, or a static markdown file. The "Intent" can be anything made of text. It can be a structured design document, a technical spec, or—in advanced platforms like m8a—it can be context injected dynamically via Retrieval-Augmented Generation (RAG). By pulling context from your existing documentation, knowledge bases, or previous system states, the "Intent File" becomes a living entity.

Regardless of the source, the concept remains the same: The Intent is the Source Code; the actual Python or TypeScript files that get generated are merely the compiled artifacts of that intent.

The Non-Negotiable Human Layer

However, a critical distinction must be made to separate IDD from the chaotic "AI-generated" workflows often hyped today. In a true IDD architecture, AI drives the car, but the Human builds the road.
We do not ask the AI to "imagine" an architecture. We do not ask it to pick a database, choose a framework, or decide on a logging strategy. These are the "Rigid Structures" of our system, and they must remain under strict human ownership.

This is not a matter of preference; it is a matter of accountability.

1. The "3 AM" Rule
The primary reason humans must define the stack is simple: Accountability cannot be automated. When a production database locks up at 3:00 AM, the AI is not the one answering the pager. The engineer is. Therefore, the engineer must possess total agency over the tools they are required to debug. If we allow an AI to whimsically choose an obscure library because it "fit the prompt," we burden the human team with technical debt they did not consent to.

2. Guardrails Against Entropy
AI is inherently probabilistic; it craves novelty. If you ask an AI to "build a service" ten times without constraints, it might give you ten slightly different architectural variations. In a distributed system, this inconsistency is fatal. By locking the architecture into "Immutable Skeletons"—human-defined templates—we force the AI to adhere to organizational standards.

3. Strategic Homogeneity
Finally, architecture is rarely just technical; it is strategic. An AI cannot know that we use a specific cloud provider because of a corporate discount, or that we avoid a certain language because it conflicts with our hiring strategy. AI lacks the global context of the business.

The Architects of "Done"

This brings us to the ultimate role of the human in IDD: we are the Architects of "Done."

The AI can iterate indefinitely, generating code that is syntactically perfect but semantically void. It is the human engineer who must review the outcome, not for style, but for meaning. We provide the "Why" and the "Where." We set the hard guardrails, the frameworks, and the templates. The AI simply provides the "How."

By embracing Intent Driven Development, we stop being the manual laborers of syntax and finally become what we were always meant to be: the Architects of Intent.

The Human-centric AI-Native Distributed Systems Manifesto

Scott Molinari — Thu, 29 Jan 2026 06:10:11 +0000

Preamble

We are uncovering better ways of building software with AI at breakneck speed, but at the same time, we must acknowledge that in the modern enterprise, no application is an island. Every piece of logic exists within a complex web of dependencies, latency, and state. We also recognize that AI is not a replacement for engineering, but a powerful engine for realizing intent.

Through this work with AI, we have come to:

Core Values

Verifiable Intent over Syntactic Correctness: We value code that provably matches the system's objective via automated policy and testing, not just code that compiles without error.

System Resilience over Local Optimization: We value the stability and survival of the entire network over the raw execution speed of a single node or function.

Deterministic Execution over Probabilistic Agents: We value AI as a builder of rigid, predictable automation scripts, rather than as a real-time, probabilistic decision-maker for critical processes.

Architectural Guardrails over Manual Review: We value automated, platform-level constraints that physically prevent anti-patterns over relying on human vigilance to catch them during code review.

Managed Metadata over Generative Novelty: We value strict, pre-defined structures and contracts (schemas/templates) over loosely coupled or "reimagined" AI-generated logic.

Human Augmentation over Human Replacement: We value AI as a tool to increase the capacity, velocity, and insight of the engineer, not as a means to reduce the engineering workforce.

That is, while there is value in the items on the right, we value the items on the left more.

The Principles of AI-Native Engineering

1. The Logic is Ephemeral; The State is Permanent

We treat AI-generated components as stateless workers. The AI writes the logic, but the Platform manages the persistence. This ensures that when the logic fails or scales, no data is lost in the wreckage of a hallucinatory variable.

2. The Transition to Determinism

AI is a tool for discovery and construction, not permanent execution. Once a process is fully understood and automated, the AI steps aside, leaving behind rigid, deterministic code to perform the task. We do not ask AI to "think" about a solved problem twice.

3. Contracts are King

The "Handshake" between services (APIs, Data Models, Event Schemas, etc.) must be defined by humans before generation begins. The AI may write the code that fulfills the contract, but it is never permitted to alter the contract alone.

4. Context is Global

We reject the illusion of the "local environment." AI must be prompted and constrained to generate code that assumes the network will fail, the database will be locked, and the service will be unavailable.

The Human Responsibility

We are the Context Bearers

AI cannot see the world outside the prompt. We are responsible for identifying and injecting the external conditions - legal, ethical, physical, and business - that the code must survive in.

We are the Governors of Semantics
Code is math, but Systems are meaning. The AI can ensure a string is 10 characters long, but only a Human can decide if that string should be a Customer ID or a Product Code.

We are the Architects of "Done"
An AI can iterate indefinitely. Only a human can declare that a system satisfies the business need and is safe for deployment.

What do you think of this manifesto?
It is the first document (of hopefully many), which I'll make public while building the m8a platform (working on alpha). I've made this manifesto public, because it is the rules and the perspective I'm working with and I'd love to hear thoughts about this from others.

Next article in our m8a series: https://dev.to/smolinari/intent-driven-development-idd-is-our-current-future-5fh4

m8a scenario #1 - Using Coder to Develop Keycloak Templates Live (almost)...

Scott Molinari — Thu, 09 Feb 2023 10:32:34 +0000

This article will be one of many posts about the trials and tribulations, the learnings and sharings of information as we build out the m8a.io platform (in POC).

The goal of these scenario articles will be to highlight one or more technologies and explain what we did with them.

We want to share these learnings and experiences, because we do believe we are making some cutting edge decisions for our new platform and/ or are coming up with alternative ways to do things that haven't yet been discovered before. And the publication of this knowledge is all in the name of giving back to those technologies that are helping us with our very lofty endeavour. It's a start.

In this article, two of the technologies being highlighting are:

Coder and Keycloak

From their websites:

Coder offloads development from local workstations to your on-prem and public cloud infrastructure. Boost developer productivity with instant onboarding and powerful server resources. Keep code and data under control within your network.

Add authentication to applications and secure services with minimum effort. No need to deal with storing users or authenticating users.
Keycloak provides user federation, strong authentication, user management, fine-grained authorization, and more.

As you can imagine, these are two pretty powerful sounding applications, right?

Scenario Description

Above and beyond these two great applications, we are also using Kubernetes.

Note: This article will assume you have some fairly good knowledge of Kubernetes and Helm and how they both work together. You should also be familiar with Terraform.

As you hopefully know, Kubernetes (k8s) is a very powerful platform for orchestrating container workloads. If you are still reading this and you don't know about k8s, I highly recommend learning about.

Getting back to our two main technologies....we have implemented Keycloak as our Identification and Authorization Management system (IAM). However, as these things go, Keycloak has its own tech stack. One of the technologies, of course, is the language they used, which is Java. And being it is Java, they chose to use a templating engine called Freemarker.

To keep this article as short as possible and because it isn't the intention of this article, we won't go into the deeper details of Keycloak's templating system and how to use it. Instead, I'll refer you to two good articles that explain it all well:

Customizing Themes for Keycloak
How to Customize Keycloak Themes

That being said, if you are familiar with any other templating system for the backend, you'll understand Freemarker fairly quickly too.

And, because Keycloak uses this template system, setting up your Corporate Identity within Keycloak is very much possible and not entirely difficult.

However, despite knowing about templating and Keycloak you'll quickly understand the first hurdle of having Keycloak in k8s.

Above and beyond designing the templates, how can we even get those new templates into the Keycloak pods for use by the application?

There are two suggested ways to get customized templates into the Keycloak pod or pods.

using an init container to "load" the new templates over a shared volume.
using a secret to load in a tarballed archive of the files.

Why won't this work?

Both require a number of steps to make the template contents usable by Keycloak and as you can imagine, are miles away from any kind of live development.

With either of these two steps, you'd need to have a local version of Keycloak to design on, then create a container with the files or create a tarball and load it into a secret and then restart Keycloak. Restarting Keycloak alone takes about a minute until it is ready to go. And if you happen to see a mistake, as it always happen, it's wash, rinse and repeat (pulling out hair or getting grey from the process).

Coder to the Rescue!

Coder is going to be an integral part of the m8a platform. And as it may be, we can also use it for the purpose of (almost) live development of custom templates in a running Keycloak pod.

Point #1 above of getting a template set into Keycloak via a shared volume gave us the initial idea. Why not just use another pod, a Coder agent/ workspace pod in parallel and share the volume between them? That way you can develop on the files in the volume and Keycloak would use them directly. Yes!

So, off we went looking to resolve this challenge.

Installing and Setting up Coder

To get going with Coder, you'll need to install Coder into your k8s cluster via Helm. Follow the instructions carefully and you should have Coder up and running in cluster in no time.

Next, you'll need a workspace template to be able to create a workspace. Again, the Coder's docs explain how to do this well and there is an example k8s template you can start from.

You'll also need to install the Coder CLI onto your local machine for working on the templates.

Coder's templates are basically Terraform modules. So, you'll need knowledge of how Terraform works and the config language itself, to develop them. If you know k8s though, it's fairly easy to pick up.

Getting Everything Set Up

Coder's service account permissions

In order to have Coder work with k8s objects outside its own workspace, we have to give the Coder service account (which should have been installed while installing Coder's Helm chart) enough permissions to work across namespaces. We did this by creating an admin cluster role and binding it to the service account via kubectl.

Keycloak setup

This was the trickier part. And of course, this will require a development environment, and not your production Keycloak. Setting up a complete development environment in k8s is way beyond the scope of this article, but if you are a good with k8s, you'll know what to do, if you haven't done it already (i.e. you really should!).

Ok. So, with Keycloak in a dev environment, you'll need to have only one Keycloak pod running, to not run into caching issues. And, you'll be setting this up in the Helm chart (we are using the Bitnami chart):


extraStartupArgs: >-
  --spi-theme-static-max-age=-1 --spi-theme-cache-themes=false --spi-theme-cache-templates=false

...

replicaCount: 1

These startup args will turn off the Keycloak caching process for templates.

Or, you can also do this:


extraEnvVars:
  - name: KEYCLOAK_PRODUCTION
    value: 'false'

This will start the pod in dev-mode, which should also mean template caching is turned off.

Set up the volume

We are using Longhorn as a more capable storage system inside our k8s clusters. To set up the volume with Longhorn, you can go into the UI and create a new Persistent Volume Claim (pvc)/ Volume.

You can also do this via kubectl, and with any other storage system in k8s.

Once you have the pvc created (making sure it is in the keycloak namespace) you are halfway there.

As a next step, you'll need to bind the pvc to the Keycloak pod via a Persistent Volume (pv). To do this, add the following to the Helm chart and upgrade it:

extraVolumeMounts:
  - mountPath: /opt/bitnami/keycloak/themes/m8a-theme
    name: theme
extraVolumes:
  - name: theme
    persistentVolumeClaim:
      claimName: pvc-keycloak-theme

The mountPath is dependent on where Keycloak is installed in the pod. The path above it where the Bitnami chart puts it.

The claimName is the name of your pvc. Ours is pvc-keycloak-theme. Keep that in mind.

Now you have the Keycloak instance working with a volume that can be attached to other pods. Let's do that now with a Coder workspace.

Setting up the Coder workspace (the pod)

As mentioned above, you can use the example Coder template to create the workspace. The only difference is now, you'll need to have the volume also bind to the workspace pod. To make that happen, you'll need to add this to the template:

resource "kubernetes_pod" "main" {
  count = data.coder_workspace.me.start_count

   ...


      env {
        name  = "CODER_AGENT_TOKEN"
        value = coder_agent.main.token
      }
      volume_mount {
        mount_path = "/home/template-dev/my-theme"
        name       = "theme"
        read_only  = false
      }
    }

    volume {
      name = "theme"
      persistent_volume_claim {
        claim_name = "pvc-keycloak-theme"
        read_only  = false
      }
    }
  }

The volume_mount and volume entries are the important additions. volume_mount is the location of the files you'll be working on. volume is the binding of the pvc to the pod.

Push up or add your template to your Coder instance via the Coder CLI and you are almost ready for development.

The new development workflow

Ok. Now that we have pretty much everything set up. Go into your Coder installation (either via port forward or if you set everything up properly, via the URL), go to the Templates tab and fire up a new workspace.

I like to use my local VSCode, so I press on the button, which will open the workspace in VSCode.

Coder will also let you work directly in the browser too, if that is what you want. We removed that feature from our template and why you don't see the option above.

Remember, this is a pod working inside a k8s cluster. It's true remote development in a just-like-production dev environment.

Once you've clicked on the button shown above, you'll be greeted with this a few seconds later:

With the workspace running, you can add your files as necessary and start developing directly on your Keycloak templates.

Note1: In the image above, the login folder is the one I was working in. You'll need to add the different folders yourself for the different areas you want to customize Keycloak's templates.

Note2: In the future, you'll be able to determine which folder the Workspace should open up in. The suggestion wasn't yet implemented in Coder at the time of writing.

Note3: Don't make the same mistake as I did and have browser caching turned on (and have forgotten about it). If you aren't seeing changes made directly after refreshing the Keycloak page you are customizing, see if it works with Ctrl + F5. Or turn off your browser's cache.

So, that is it. I searched very hard to find something like this and couldn't find anything remotely similar. I hope this will help others, at least those wanting to customize their Keycloak instance more efficiently inside k8s.

Happy Coding!!!! 😁