DEV Community: Dane Balia

AI Harness Simplified

Dane Balia — Fri, 31 Jul 2026 10:49:43 +0000

Two terms are rapidly entering the software vocabulary and they describe two very different answers to the same question: if AI agents write our code, what do we build around them to ensure quality, consistency and reliability?

Harness Engineering

A harness is defined as a piece of equipment with straps and belts, used to control or hold in place a person, animal or object. Some examples are a safety harness if you are doing bungee. Or a baby's harness. Historically, a harness was very much associated with draft animals such as horses, oxen, mules and cattle. An ox pulling a plow is typically yoked with a harness. The intent was to harness something effectively. That is: to direct, control, and use its power effectively for a purpose.

A harness in AI, is everything you put around an AI agent to shape how it works and to check what it produces. The discipline is broken into 3 parts. Guides steer the work forward. These are (a) rules and context files, (b) specs and prompts (c) skills and examples and (d) tools the agent may leverage. The second part is Boundaries - constraints for effective execution. These include sandboxes for isolation, permissions and token budgets. This ensures that the agent is constrained to run safely, but also run in a loop within some predefined resource limitations. The
final part is Sensors. These verify the result. This is done with compilers, linters, tests, security scans and increasingly AI reviewers.

Harness engineering is the craft of combining these deliberately. Early evidence suggests it reduces token consumption, makes output markedly more consistent, and that specific named instructions dramatically outperform general guidance. But there's a catch: the most effective harnesses appear to be those co-developed with their backing models. Harness and model trained and tested together. That's part of why Claude Code punches above its weight, and it raises an uncomfortable question for us around our own.

Software Factory

A factory is a set of buildings where large amounts of goods are made using machines. A software factory is the same idea, where a set of systems are integrated to build, verify and release software repeatedly and at scale, with AI agents as machinery.

The software factory is the harness taken to its logical extreme: remove the humans. A backlog of work items feeds an orchestrator. An orchestrator dispatches an agent swarm to do the various parts of the work. Automated checks gate the output - AI reviews the AI's work and merges it. Deployment is continuous. And telemetry or feedback generates the next tickets. The loop runs and closes without a person standing anywhere on the line of production. Its promise is throughput. Code generation around the clock at near-zero marginal human cost.

Harness engineering will mature into a discipline - from individual craft to team practice and then platform capability, with shared harness components governed centrally and judgement federated back to the teams on the ground. Two problems will define these steps forward, sensor integrity. That is, how accurate, useful and reliable are the sensors we build. The second is, calibration - AI judges are proliferating faster than anyone is measuring them, and the harnesses that endure will be the ones that score their automated reviewers (AI) against human decisions over time and improve through it.

Software factories will find their niche and their ceiling. Factories are genuinely viable when correctness is cheap to verify, and errors are cheap to reverse - transactional back-ends, legacy rewrites governed by strong conformance test suites and internal tooling. The ceiling is structural. Today's models are trained against fast signals - does it compile, do tests pass, and are lint checks clean. However, what they do not cater for is design, maintainability, fidelity to intent and these things will surface over the months for which no automation checks. A factory has no station for slow signals, so it doesn't fail loudly. It instead accrues debt silently behind green checkmarks.

Conclusion
The two concepts are not rivals so much as two settings of one dial: how much do we let an agent decide, and how we stay confident in what it does? The answer depends on the situation. If you can check the result cheaply and trust the check, the agent can be given more freedom. If checking is hard or mistakes are expensive, keep the leash short. We need to place human judgement where it matters most - saying what correct means at the start, and making the final call at the end. But we must also regularly test whether the automated judges in between can still be trusted.

The Human Is Not the Bottleneck. The Human Is the Missing Oracle

Dane Balia — Fri, 31 Jul 2026 10:39:30 +0000

We spent a year optimising the wrong bottleneck.

The harness discourse has been relentless - blueprints, schematics, thought leadership. Impressive engineering, most of it. But read the designs closely and you notice what they're all quietly aiming at: getting the developer out of the pipeline.

The logic seemed sound. Building dropped from days to minutes, and the human became the slow part. The bottleneck. So we designed the human out.

Then the telemetry arrived.

Faros AI instrumented 22,000 developers across 4,000+ teams. Moving from low to high AI adoption: task completion per developer up 34%, epics up 66%. Real gains. Also: bugs per developer up 54%, incidents per pull request up 243%, median review time up 5x, and 31% more PRs merging with no review at all.

Nobody decided to stop reviewing. Reviewers simply couldn't keep pace, and unread merges became normal. We knew this failure before AI. The 2,000-line PR lands in your inbox, and what follows is frustration, cognitive overload, and a silent rubber stamp. The difference is that it used to be the exception. Now it's the throughput model.

The bottleneck didn't disappear. It moved to review and integration - and we'd already removed the person who was supposed to be standing there when it arrived.

Two things worth saying plainly.

First: the human was never the bottleneck. The human is the missing oracle.

We have fast, cheap oracles for correctness. Do the tests pass? Does it lint? Machine-verifiable in seconds. We have no oracle at all for maintainability, intent, or design - and no benchmark I'm aware of currently measures them. GitClear's analysis of 623 million code changes shows what fills that gap: duplication up 81%, refactoring down 70%, error-masking constructs up 47%. Code that looks right and is structurally wrong.

Designing the human out doesn't remove a cost. It removes the only sensor we have for the slowest and most expensive failure mode. "Humans first" isn't sentiment or ethics-washing. It's a claim about where verification capability actually resides right now.

Second: we're borrowing against comprehension and calling it velocity.

Anthropic ran a controlled trial in January. Two groups, same unfamiliar library. The AI-assisted group finished marginally faster and scored 50% on comprehension. The manual group scored 67%. Seventeen points, on code they had written minutes earlier (this is a vendor publishing a result against it's own commercial interest).

That debt doesn't show up in your DORA metrics. It shows up at 2am when nobody on the call can reason about the system they shipped.

The industry response is to build faster agents. So I built the opposite experiment. A harness that puts the human at the centre - not to slow things down, but to make judgment cheap, timely and measurable rather than optional. You can check out the harness here.

Plain bash. Deliberately crude. Built to learn, not to scale.

The rules:

Agents don't move artefacts through the SDLC. They hit mechanical gates.
Humans state intent, write the spec, define acceptance criteria, and read the diff.
Route every check to the cheapest reliable verifier - mechanical gates for what's machine-checkable, calibrated LLM judges only after validation against human labels with explicit thresholds, humans for intent and design.
Diff budget: 200 lines. (Which became 400, excluding tests). If it's more than 400 lines, the feature was scoped wrong. The gate fails and the work gets split.
Only iterate on the harness with confirmed evidence and root cause.

Thirty minutes on an approved spec and a design sketch turns a six-hour adversarial review into a twenty-minute confirmation. The human isn't reviewing more. They're reviewing earlier, where a one-line correction prevents two thousand lines of rework.

237 minutes. 12 features. One engineer, no control group - an experiment, not evidence. I'm publishing the method so it can be argued with.

DORA's finding is that AI is an amplifier: it magnifies whatever your organisation already is. If your answer to a 243% rise in incidents per PR is to remove the last human who might have caught them, the amplifier is working exactly as designed.

What are you actually measuring?

.NET Core: Deploy exe as Service

Dane Balia — Fri, 04 Sep 2020 15:14:13 +0000

So you've built a .NET core executable, it's long running (while(true)) and is ready for deploy to your server. Your initial process involves a manual network copy and some wiring on the server to ensure it runs as a service. Maybe a service wrapper? 🐱‍🚀 After a few refactors and bug fixes with multiple deploys, the process starts to feel a bit like smuggling sand across the Kalahari Desert.

We need a hero.

So let's get to it. The hero of choice for this adventure movie is Ansible.

Requirements:

WSL2 (running Ubuntu)
Visual Studio Code / Studio
A Linux server / localhost
SSH access via authorized key

Steps:

What is Ansible
Install Ansible
Setup our configuration structure
Define our Recipe
Deploy 🎇

Step 1: What is Ansible?

--snip snip--
Ansible is a radically simple IT automation platform that makes your applications and systems easier to deploy and maintain. Automate everything from code deployment to network configuration to cloud management, in a language that approaches plain English, using SSH, with no agents to install on remote systems

In order words, it's our deploy tool.

Step 2: Installing Ansible

Installation on your flavor of Linux is nothing more than,

# <your package manager> install ansible

For Ubuntu the following would work:

$ sudo apt update
$ sudo apt install software-properties-common
$ sudo apt-add-repository --yes --update ppa:ansible/ansible
$ sudo apt install ansible

The installation is not a service but nothing more than a set of executables that you will use to feed a basic recipe to configure the deployment process.

Step 3: Setup our configuration structure

For those who would like to follow on without writing any code I've included a Github repository with the sample.

In my project I usually create a deploy folder as a form of separating concerns. Thereafter, I create my SystemD service file that we will setup on our remote host so we can stop and start our service. You can find a sample service file here.

Next we will create a playbook YAML file that will be our configuration, and a hosts YAML file that will represent the host/s we want to deploy too.

Okay so now we have all we need, let's do the configuration.

Step 4: Define Our Recipe

Host configuration

Edit your hosts.yml in the Deploys folder to match the following. This basically supports a configuration of one or more hosts that we could deploy our service too.

Line 4 is probably the most important as it's the key cross reference (custom name) we leverage in our play book or recipe for the deployment. For more information on configuring your inventory, check out the ansible documentation.

** Be advised you can do this cleanly with an Ansible task, but I haven't, so you will need to create the remote directory or production folder on the remote host.

Deployment playbook

Edit your playbook file and lets add the following code. Anything related to "InfiniteHelloWorlds" can be replaced with your executable name. Just remember, Linux is case sensitive.

hosts - is that cross reference we mentioned earlier from the hosts.yml.
vars - represent our variables that will use within the configuration itself, the tasks. The production folder is the destination folder of the host to which you will deploy. The linux_release_path is the location of the executable after a dotnet publish as per below.

$ dotnet publish --framework netcoreapp3.1 --runtime linux-x64 -c Release

The next aspect are the actual tasks. This configuration will drive the work of deployment.

There are many kinds of tasks in ansible that apply to deploys for Windows and Linux, you can check that out here.

The tasks are broken down into the following functionality,

Task Steps by Name

Compress directory before send: Compress published directory found in working directory of .NET Core project.
Stop service: If the first deploy, you may want to comment this out as the service has not been setup on the host. This is there for ongoing deployments. This can also be done via an Ansible task.
Copy release files to host: will then copy the archive/zip to the remove host to the production folder specified in the vars.
Unarchive the code: involves un-compressing the archive onto the local disk of the host.
Copy systemd file: will then copy from the local unarchived file contents the service file and configure the service by placing the .service file in the SystemD configuration folder.
Restart the service: lastly, call restart on the service.

And there you have it. All configured and ready to deploy.

Step 5: Deploy

Let's deploy in the project folder (not solution).

$ ansible-playbook infinitehelloworlds.yml -i Deploys/hosts.yml

That should lead to a fully deployed service, and this is what success will look like.

We have just really touched on the basics today, and this is still pretty rudimentary and not resilient enough. But it's sufficient for a good start and a foundation for more advanced deploys.

Debugging

To troubleshoot the running of your service, you can stop and start the service separately; run the deploy with verbose output, execute a specific step or even run test commands.

$ ansible-playbook --help
$ ansible-playbook InfiniteHelloWorlds/Deploys/infinitehelloworlds.yml -v
$ systemctl stop infinitehelloworlds
$ systemctl start infinitehelloworlds
$ journalctl --lines 100 
$ ansible all -m ping

HTH!

Research Methods At A Glance

Dane Balia — Mon, 30 Dec 2019 08:54:44 +0000

Light bulbs of the week (Week 51 2019)

Dane Balia — Fri, 20 Dec 2019 09:33:33 +0000

What did I learn this week?

Monolith vs Micro-kernel

Outcomes over Output

How to reason about value

Quick Tour of C# Generic Type Constraints

Dane Balia — Fri, 02 Aug 2019 14:41:10 +0000

Last time we looked at some fundamentals to Generics. Let's peel a little more of the onion regarding Generics and consider Type Constraints.

A Type Constraint is the restriction imposed on a type used by a generic.

public class AGenericClass<T> where T : IComparable<T> { } ...
public class UsingEnum<T> where T : System.Enum { } ...
public class GenericList<T> where T : Employee ...

Constraints inform the compiler about the capabilities a type argument must have by restricting it. Without any constraints, the type argument could be any type. Imposing the constraint/s on the generic increases the number of allowable operations and method calls to those supported by the constraining type and all types in its inheritance hierarchy.

Clarification

So if I had a wooden drawer, it could pretty much take anything. In fact, it would most likely be very difficult to order things and keep things in their place. And with the continual opening and closing of the drawer, one is also unlikely to efficiently access their papers, pens, rulers, stapler etc.

But assume we have a drawer compartmentalized by inner linings of wood. All of a sudden, things have a place and are more structured in terms of access. And this is what Type constraints do. They impose restrictions to provide a more human and safe interface to the Generic type - <T>.

There are 7 constraints one could consider when using a Generic, so let's review a few to get an idea of how to use them.

Value Type Constraint

where T : struct

This constrains the type argument to a value and not a reference type.
Examples of what would be valid:

Votes<int>
UploadedFiles<FileMode>

Examples of what would be invalid:

Swap<object>
ReportContent<StringBuilder>

Reference Type Constraint

where T : class

This constrains the type argument to be a reference type and not a value type.
Examples are simply the reverse of what we just saw in the Value Type Constraint. That is, the type argument <T> can be any class, interface, array or delegate.

Constructor Type Constraint

where T : new()

This constrains the type argument to have a public parameter-less constructor.

snip taken from C# in Depth

public T CreateInstance<T>() where T : new()
{
   return new T();
}

This methods returns a new instance of whatever type you specify, constrained of course by the fact that the type must have no parameters in its constructor. This is a useful constraint when working with the Factory Method Design Pattern.

Sample Using Interface Constraint

In the sample above, we see the creation of a rudimentary Tuple. The type MyTuple has an interface type constraint. Thus the type argument must be or implement IEquatable .

When developing our MyTyple; IEquatable enforces the following constraints:

You must implement it's method - Equals(<T>)
And you should override the base class implementations of Equals(Object) and GetHashCode() so that their behaviour is consistent with that of the Equals(<T>) method.

There are four main generic interfaces for comparisons, two of them IComparer<T> and IComparable<T> are about comparing values and for ordering. That is, one value <=, => or == too another.

The other two, IEqualityCompare<T> and IEquatable<T> are used for comparing two items for equality to some criteria and applying a hash of an item.

The consumer of the code is constrained by a contract that describes the bounds of the generic. So while the generic is supportive of variations of a kind (or type) it is prescriptive around what it should do or be capable off.

Last words

Generic type constraints are nothing more then the restrictions imposed on generic types preventing abuse, but also clearly communicating the constraints for its use and providing compile-time errors.

For more depth, please see the resource below:

Quick Tour Of Generics In C#

Dane Balia — Fri, 19 Jul 2019 10:30:09 +0000

Generics have been around since C# 2.0 and has become a tool we leverage so naturally now in C# we almost don't even think about it. So let's change that...

Definitions

Generics introduce to the .NET Framework the concept of type parameters, which make it possible to design classes and methods that defer the specification of one or more types until the class or method is declared and instantiated by client code.

Essentially generics allow you parameterize types and methods. Just as normal methods have parameters to tell them what values to use, generic types and methods have type parameters to tell them what types to use.

Clarification

Type parameters are placeholders for a type.

There are constructed types and generic types.
A constructed type is when the type arguments are specified. For example,

Dictionary<int, string>()

A generic type is when the type arguments are not specified. For example,

Dictionary<TKey, TValue>()

As per the code snippet below, writing a method to swap two Integer values is pretty rudimentary. But what if later we needed to do the very same but with Strings. This would result in two methods, or perhaps overloads.

Generics to the rescue. We've isolated the type as a form of abstraction (T) to act as a placeholder for the type we intend to use.

When the method is actually called, that placeholder is replaced with the type of the values used.

The value of Generics here is that it grants you productivity improvements, expressiveness and moves some safety concerns from execution time to compile time.

Note the two ways in which the method can be called. One with the type explicit, and the other implicit through type inference. The compiler is inferring the type parameters based on the method arguments you pass.

A generic is simply a placeholder for a type.

C# Value and Reference Types

Dane Balia — Fri, 28 Jun 2019 08:43:50 +0000

Value and Reference types are covered frequently all over the internet, in blog posts, technical articles and forums. Why? Because it's easy to develop software for a long time without stopping to 'smell the roses'. Or in this case, understand what they are and how they work. So here's a note to self, or you.

A Value Type is some object that is the information itself.

A Reference Type is the details which points to an object containing the information. The details include things like type of object etc.

An Analogy:

Let's set the table with an analogy. Kim has just written a book. It's an auto-biography. She would like to get feedback so she prints a copy at home and gives it to her husband Kanya. Later that day she stumbles onto a publicist, who is intrigued and asks to read it. She fires up her Macbook and shares the link to the original via Google Drive.

As time passes the publicist feeds back and is thoroughly impressed. She has highlighted a slew of spelling mistakes and a consideration for re-writing Chapter 4. Kim goes to work immediately and in a few days is done. Updating the original and requesting that the publicist review her changes.

So what's this got to do with value and reference types?
Well, when Kim made Kanya a physical copy of the original. She provided him with an independent version of the truth. In fact after all her changes during her engagement with the publicist, Kanya's copy has now become outdated and obsolete. He had a value type. An independent copy of the source, that was detached and indifferent to modifications of the source.

The publicist on the other hand, well she had a Google Drive URL, a reference to the original. In fact as Kim made changes the publicist could see those changes in real time. The reference provided access to the original but was not the original.

Some Examples

Array types are reference types, even if the element type is a value type (so int[] is still a reference type, even though int is a value type)
Enumerations are value types.
Delegates are reference types.
Interfaces are reference types, but they can be implemented as values.

Stack vs Heap

References types live on the Heap.
Value types lives where their declared.
Local variables and method parameters live on the Stack.

A Stack is a simple FIFO memory structure. When a method is invoked, the CLR bookmarks the top of the stack. The method then pushes data onto the stack as it executes. When the method completes the CLR just resets the stack to it's previous bookmark.

Stack offers:

very fast access
space is managed efficiently by CPU, memory will not be fragmented
local variables only
limit on memory size

A Heap is a random jumble of objects not managed by automatically for you. It is a free-floating region of memory (and is larger). In multi-threaded applications each thread will have its own stack. But all the different threads will share the heap.

Heap Offers:

variables can be accessed globally
no limit on memory size
(relatively) slower access

It's critical to note, that a value type lives where it's declared, so if you have a class with an instance variable of float, a value type. It will live wherever the rest of the object is found and that is on the heap.

A last point, is that a string in C# is a reference type. Why? Because strings can be grow quite large in size and thus have to stored on the heap.

References

C#'s Type System

Dane Balia — Fri, 21 Jun 2019 12:53:56 +0000

Exploring the Terminology:

C# 1's type system is static, explicit, and safe.

Statically typed is where each variable is of a particular type, and that type is known at compile time. In other words, the compiler does type checking at compilation time.

In the test method StaticTypeWontCompile() you can see the string "Hello". But because we gave it the type Object, the compiler sees its type as Object and not String. Hence the .Length method being unavailable. This test won't run because the compiler will state object does not contain a definition for 'Length'.

Explicitly Typed is where the type of every variables must be explicitly stated. Of course, explicit vs implicit types is only relevant in statically typed languages.

Safe Type System is the characteristic of code that allows the developer to be certain that a value or object will exhibit certain properties so that he/she can use it in a specific way without fear of unexpected or undefined behavior.

In the method ThisIsSafe() the compiler will clearly state that an Operator '+' cannot be applied to operands of type 'int' and 'bool'. This safety applies for the majority of C# up until we get to Collections, Inheritance, Overriding and Interfaces as witnessed in method ThisIsUnsafe which compiles perfectly.

Reference