DEV Community: Oystro

What a Human Gate Looks Like

George — Thu, 01 Oct 2026 03:30:00 +0000

Writing · October 1, 2026 · George

What a Human Gate Looks Like

A concrete walkthrough: approve the plan, build, review the evidence, release.

Human gates sound like process theatre. But it's the opposite. Here's the actual mechanics, on a real feature. So, you be the judge.

The setup

You are building a feature. Let's say a session manager for a service. You open your agent in the project directory and initialise the harness. Two minutes later you have the constitution, the requirements, the architecture. The agent derived them from the code and docs that already exist.

Gate 1: Design, before any code

You ask the agent to define the feature. It produces a single spec file that has the requirements, the design decisions, the file layout, the task list, and the acceptance criteria. Then it stops.

This is the first gate. You read the spec. You spot that the agent missed the idempotency requirement so that retries are safe. You add it. You say "approved."

Nothing was implemented yet. The one change you made just saved you a rework cycle later. That's the point of the gate. Catch the wrong assumption while it's still one line in a spec, and not when it is a hundred lines of code.

The build with one commit per task

Now the agent works. It follows the approved task list in order. One commit per task. No improvising, no adding features, no "I also noticed this other thing."

If a task fails three times, it stops and escalates instead of thrashing. You're not watching it type. You're reviewing a series of small, traceable commits, each tied to the approved plan.

Gate 2: The evidence, before release

The agent runs the evidence contract. The tests, acceptance criteria, the verification report. It marks the release as pending. Then it stops again.

You read the report. You approve. The agent merges, archives the feature, bumps the version, and records every decision in the build narrative.

Why this scales

Nothing here requires you to be a hero. The two gates take minutes. The agent does everything else. And because every decision is recorded, you don't have to hold the project in your head. Six months later, git logtells you what happened and why.

That's a human gate. Not ceremony. The two moments where a person looks at the work and decides, before it's too late and maybe too expensive to change.

The honest part

No harness guarantees the agent will follow it. The agent may skip steps, forget to update the log, or drift from the approved design. The harness makes the right path clear. It can't force the agent to walk it. Deterministic enforcement is the engine's job, not the protocol's. The protocol is the method, the engine is the paid layer.

So, you still have to watch, correct, and decide. A status command shows you where you are and what the agent should do next, without touching your working tree. But the human stays responsible. That's not a flaw in the harness. That's the whole point. A process that removes the human isn't more reliable, it's just less accountable.

The workflow is free. Bring any agent. Keep your standards.github.com/oystro/oystro-oss

Oystro OSS is a free, open-source ADLC protocol that adds human gates to your agents. Bring any agent. Keep your standards.

Try Oystro OSS

See it in practice: the Oystro OSS User Guide.

The Five Levels of AI-Assisted Development

George — Thu, 24 Sep 2026 03:30:00 +0000

Writing · September 24, 2026 · George

The Five Levels of AI-Assisted Development

Most teams think they're further along than they are.

Dan Shapiro's framework of five levels of AI-assisted development, borrowed from the autonomy levels of self-driving cars, is the most useful way to think about where your team actually is. The insight is that every level feels like you're done but you're not.

Level 0: Manual driving

The AI does autocomplete. You write every line. The bottleneck is typing speed. This was most of "AI coding" in 2022. Feels primitive now.

Level 1: Lane assist and cruise control

The AI handles discrete tasks. You direct what to do. The bottleneck is how fast you can assign tasks. Copilot in 2023. Useful, but you're still doing most of the driving.

Level 2: The trap

The AI does whole features end to end. It feels transformative. Productivity is up, morale is high, the work is satisfying.

This is where most teams are. And it's a trap. In Shapiro's own words, the danger is that Level 2 feels so good that people stop here permanently. But you are still the rate-limiting factor. If you're not at the keyboard, nothing happens.

Level 3: Waymo with a safety driver

The agent works autonomously, but a human is still responsible and can take over. This is where harness engineering lives. The agent runs, the human gates. The agent builds one task at a time, the human approves the design and the release. You're supervising, not driving.

Level 4: Robotaxi

Full autonomy. No driver. This is the "dark factory" horizon. Interesting, but not where most teams are, and not where most teams should be aiming today. Getting to Level 4 safely means mastering Level 3 first.

Why the levels matter

The levels aren't a ladder that needs to be climbed. They are a diagnostic. Most teams think they're at Level 3 or 4 when they're actually at Level 2, because Level 2 feels like the destination.

The harness is what gets you from Level 2 to a real Level 3. The agent runs autonomously, but the human gates stay, the evidence stays, the decisions stay recorded. That's not slowing the agent down. It's what makes going faster safe.

The workflow is free. Bring any agent. Keep your standards.github.com/oystro/oystro-oss

Oystro OSS is a free, open-source ADLC protocol that adds human gates to your agents. Bring any agent. Keep your standards.

Try Oystro OSS

See it in practice: the Oystro OSS User Guide.

Why Vibe Coding Breaks at Scale: The Case for Harness Engineering

George — Fri, 18 Sep 2026 03:30:00 +0000

Harness Engineering · Deep Dive

Why Vibe Coding Breaks at Scale: The Case for Harness Engineering

Published September 18, 2026•By George•6 min read

In early 2024, the software engineering industry embraced a seductive new rhythm: "vibe coding." You open a chat window, describe an intent in plain English, watch an LLM generate 400 lines of code across three files, hit reload, and if the UI doesn't crash, you commit.

It feels magical. It feels like 10x leverage. Until month three.

The Entropy Trap: Speed Without Structure

Vibe coding optimizes for instant momentum , not long-term maintainability. When you ask an AI assistant to build an isolated greenfield script, it excels because the entire context fits within a single prompt window. But real production software does not live inside an afternoon chat session. It lives across quarters, hundreds of commits, evolving API contracts, and teams of engineers.

As the codebase expands, four critical failure modes inevitably emerge:

The Ephemeral Reasoning Void: The crucial architectural decisions - why a specific database abstraction was chosen, what concurrency hazards were mitigated, why an alternative design was rejected - disappear the second the chat tab closes. The code remains, but the reasoning is gone forever.
"Done" Without Receipts: The assistant announces that the task is finished. But did it actually run the regression suite? Did it check whether changing that shared struct broke a downstream consumer? In vibe coding, "done" is a polite promise until production breaks.
Context Amnesia: Every new chat session starts completely from scratch. The assistant re-reads the entire repository and re-derives decisions it already made - often slightly differently - so patterns, style and behaviour drift. The token burn is a symptom; the lost accuracy is the real cost.
Silent Drift Across Repositories: Modern products rarely live in one folder. A change in a contracts library quietly breaks the backend API, which silently breaks the CLI. Without cross-repo verification, team coordination collapses back into frantic Slack messages.

The core problem: AI coding assistants generate code exponentially faster than human engineers can read and verify it. Without an operating harness, AI assistants become firehoses of software entropy.

The Solution: Harness Engineering

The alternative to vibe coding is not going back to manually typing every line of boilerplate. The alternative is Harness Engineering.

Instead of letting an autonomous assistant run unconstrained and hoping for the best, Harness Engineering surrounds the AI with a deterministic, fail-closed operating harness governed by three non-negotiable principles:

1. Hard Human Gates, Not Post-Hoc Reviews

Nothing gets built without plan approval. Nothing ships without evidence verification.

Gate 1 (Pre-Build): The assistant is strictly prohibited from writing code until a human reviews and approves the architectural plan and test commitments.
Gate 2 (Pre-Release): The assistant cannot finalize or push code without producing cryptographic, reproducible test receipts.

2. Persistent Project Memory

Your project needs a durable memory stored with the project - not trapped inside a vendor's proprietary web UI:

A single live snapshot (handover.yaml) that records active tasks, open decisions, and the single next action.
An append-only journal (SLICE_LOG.md) that documents why each change was made and what proved it.

A fresh assistant session reads six lines and resumes in seconds.

3. Proof Over Promises

"It compiled on my machine" is not evidence. A true harness executes the agreed verification checks, computes cryptographic hashes over the test outputs, and binds the verification receipt to the Git commit. If evidence is missing, pre-push hooks fail closed.

Bring Harness Engineering to Your Project

Oystro adds deterministic human approval gates and persistent memory to AI coding agents, so your codebase stays reviewable and maintainable for years to come.

Join Early-Access Waitlist Explore Free Open Protocol Read the Oystro OSS User Guide

Harness engineering vs vibe coding
Every agent session starts from zero
What a human gate looks like

Why the Harness Matters More Than the Model

George — Thu, 17 Sep 2026 03:30:00 +0000

Writing · September 17, 2026 · George

Why the Harness Matters More Than the Model

The model gets you speed. The harness gets you trust.

The same model weights that score 30% on a benchmark can score 95% with a better harness. That's not our line. It comes from Y Combinator's paper club on harnesses, and is the clearest statement about something people are getting wrong.

Lack of a cutting-edge model was never the bottleneck. Lack of a good harness is.

Stop chasing the wrong half

Most AI-engineering conversations revolve around models. Which one is smarter? Which one is bigger? Which one costs less per token? All of it is chasing the generation half of the problem.

But generation was never the hard half. Generating plausible code is easy. Generating code that's "right" for a specific project, with its specific constraints and history, is a completely different problem. And that's not solved by a better model. That's solved by structure around the model.

A harness is that structure. It's the difference between asking an agent to "build this" and giving it a process where the agent states its approach, you approve it, and it builds one task at a time with evidence. Same model. Completely different reliability.

The two halves of why harnesses matter

When people talk about harnesses, they focus on capability. Yes, a better harness makes an agent more capable, because it stops the agent from wandering and keeps it pointed at the approved plan.

But there's a second half that gets less attention. And that is about verification. A harness with gates and recorded decisions makes the agent's work "auditable". You can see what the agent assumed, what it approved against, and what actually shipped. On a project that runs for months, this second half is the one that matters. The risk isn't about "did the agent score 95%." The risk is "three weeks later, no one can explain why this exists."

Capability gets you speed. Verification gets you trust. A real harness gives you both.

The category is forming

The fact that Y Combinator is running a paper club on harnesses, and Uncle Bob Martin is doing video rants on "rethinking harnesses," tells you the conversation has tipped. Harness engineering is becoming a named category, the way DevOps did a decade ago.

This is a shift worth paying attention to. The teams that treat their harness as a first-class citizen, and not "just some prompts and scaffolding," will eventually be able to trust what their agents build.

The workflow is free. Bring any agent. Keep your standards.github.com/oystro/oystro-oss

Oystro OSS is a free, open-source ADLC protocol that adds human gates to your agents. Bring any agent. Keep your standards.

Try Oystro OSS

See it in practice: the Oystro OSS User Guide.

Harness Engineering vs Vibe Coding

George — Thu, 10 Sep 2026 03:30:00 +0000

Writing · September 10, 2026 · George

Harness Engineering vs Vibe Coding

The difference isn't speed. It's who's in the driving seat.

When vibe coding, the agent generates, and you accept or reject after the fact. The decision happens in the prompt, invisible and unaudited.

In harness engineering, the agent stops before it writes a single line of code. You review the design and approve the contract. Then it builds one task at a time, one commit per task, with evidence. Every decision is captured, reviewed, and recorded.

What's the difference? It's not about speed but who's in the driving seat.

Why vibe coding feels fine until it doesn't

Vibe coding gets a lot right. It's fast. It's satisfying. You describe what you want in plain language and watch code appear. For a prototype or a weekend project, that's often enough.

The problem pokes its head up in longer projects. In a longer build cycle, the agent makes numerous decisions. Each decision looks reasonable then but isn't written down for future reference. A few weeks later a feature ships, and nobody can say why it works the way it does, or what the assumptions behind it were.

We think it's a bug in the agent. No, it's the structure. When a decision is a conversation that's already gone, the decision never happened.

What a gate changes

A harness stops the work when it is important for a human to look at it before it proceeds.

Before a single line of code is written, the agent states its approach and its assumptions. You read them. You change what's wrong. You approve. That approved design becomes the contract the agent builds upon.

Then, before release, the agent shows you the evidence such as the tests, the acceptance criteria, the verification report. You read it. You approve.

Two gates. Everything in between, the agent handles without babysitting. But the two moments that matter are yours.

The same agent, two roles

The harness doesn't constrain the agent. It changes what the agent is asked to do at each stage.

During the define and design phase, the agent is a collaborator. It asks questions, finds gaps, challenges assumptions. It thinks with you.

During the build phase, the agent is a disciplined executor. It follows the approved task list in order. It commits after each task. It does not improvise.

Same agent, two jobs. The collaborator produces a better design. The executor produces reliable code. The gate between them is what keeps the two from falling over each other.

Who's responsible

Here's what matters. If the output is wrong, the first question is "Did we review the design carefully?" and not "Did the agent fail?"

That's the shift. In vibe coding, you are downstream of the agent's decisions. In harness engineering, you are the one making them. The agent is fast and tireless. The harness makes its speed trustworthy by putting you in control.

Who this is not for

To be blunt. If you prefer vibe coding, that's a valid choice, and this isn't for you. If you want the agent to make all the decisions, again, not for you. If you think review gates are overhead, this will feel like friction you don't want.

The harness is not about team culture. It is about your standards.

The workflow is free. Bring any agent. Keep your standards.github.com/oystro/oystro-oss

Oystro OSS is a free, open-source ADLC protocol that adds human gates to your agents. Bring any agent. Keep your standards.

Try Oystro OSS

See it in practice: the Oystro OSS User Guide.

Every agent session starts from zero

George — Thu, 03 Sep 2026 03:30:00 +0000

Writing · September 3, 2026 · George

Every agent session starts from zero

Why long projects lose the thread, and why the fix is a process, not a better model.

We spent the last few months deliberating and then building software that runs on top of AI coding agents. The question that kept intriguing us:

Why does every agent session start from zero?

When a team works on a long-running project, the context is not just in anyone's head. It has seeped into the codebase, the PR reviews, the decisions recorded in comments and commit messages. After a few weeks or months, a new person inducted into the project reads, absorbs and continues building based on what's there.

For an agent, every session starts cold. The model only sees your prompt and the files in front of it. The model is unaware of the past decisions you made, the constraints you discovered and the reasons why you did things in a certain way. Unless you type it again!

So we become the memory. The sole entity holding the thread.

This is a risk nobody accounted for. As the agent generates code, you try to absorb it. The context keeps on growing while your memory remains constrained.

We have experienced this and watched teams go through it too:

Senior engineers spending time every day to reiterate a project's constraints.
Relying on one person who has been there from the start and knows the whole architecture.
The "quick resume" that turns into an endless rabbit hole because the summary has messed up.

You write a summary on Tuesday, it veers a bit by Thursday, and by Monday it misleads. So you stop trusting it and start reworking everything from scratch. It is not a tool problem but a process issue.

The fix isn't better agents

A better model doesn't remember the previous session. A bigger context window doesn't help either. It just lets you stuff more reminders. The fix is to make the process hold the context.

We have been experimenting with a simple approach. Even before the agent writes a single line of code, it has to write down its approach and assumptions. That is reviewed. Then the agent works one task at a time, one commit per task, and at each step it records what it did and why. The session can end anywhere. The thread is on a disk, not in someone's memory.

The effect was that we shifted the importance from holding things in memory to reviewing things properly. The agent keeps working, the context keeps accumulating, and you judge the work instead of reconstructing it.

You can't call this a productivity hack. It is moving from babysitting an agent to a reliable process on a long-running project.

The question we are seeking answers to

We are building this as an open-source harness that wraps any agent with these gates, so that you're not locked into any one tool. We want answers from people who have lived this:

Have you lost threads across agent sessions on long projects, or is that not an issue for how you work?

We are better off hearing that "this is a non-issue for us, and here's why" than "this looks cool". We are eager to hear what happens on your project when a session ends and a new one starts. That's what we want to know.

Repo: https://github.com/oystro/oystro-oss

Oystro OSS is a free, open-source ADLC protocol that adds human gates to your agents. Bring any agent. Keep your standards.

Try Oystro OSS

See it in practice: the Oystro OSS User Guide.

DEV Community: Oystro

What a Human Gate Looks Like

What a Human Gate Looks Like

The setup

Gate 1: Design, before any code

The build with one commit per task

Gate 2: The evidence, before release

Why this scales

The honest part

Related posts

The Five Levels of AI-Assisted Development

The Five Levels of AI-Assisted Development

Level 0: Manual driving

Level 1: Lane assist and cruise control

Level 2: The trap

Level 3: Waymo with a safety driver

Level 4: Robotaxi

Why the levels matter

Related posts

Why Vibe Coding Breaks at Scale: The Case for Harness Engineering

Why Vibe Coding Breaks at Scale: The Case for Harness Engineering

The Entropy Trap: Speed Without Structure

The Solution: Harness Engineering

1. Hard Human Gates, Not Post-Hoc Reviews

2. Persistent Project Memory

3. Proof Over Promises

Bring Harness Engineering to Your Project

Related posts

Why the Harness Matters More Than the Model

Why the Harness Matters More Than the Model

Stop chasing the wrong half

The two halves of why harnesses matter

The category is forming

Related posts

Harness Engineering vs Vibe Coding

Harness Engineering vs Vibe Coding

Why vibe coding feels fine until it doesn't

What a gate changes

The same agent, two roles

Who's responsible

Who this is not for

Related posts

Every agent session starts from zero

Every agent session starts from zero

The fix isn't better agents

The question we are seeking answers to

Related posts