I hope at least some of my friends don’t have to run PHP, and definitely all of my friends milk this moment with their overlords, and somehow manage to pass the message that buy-borrow-die doesn’t really apply to tech-debt.

Memes anyone?

And yes, for that special type of people, I got one for you too!

On your toes friends, there’s probably more of it coming.

Cheers!

One must admit. The amount of effort and money that goes into convincing everyone that we live in the era of the mythical AGI is admirable. The models that are so good and we are almost there, and our lives are about to change forever, so much so that we must keep them under tight control or else the universe implodes – because what is the universe if not the adventures of a bunch of tech bros in the open market.

This blog was made to share hard-earned lessons from the “frontier”, and that’s what I’ll attempt here.

October 3rd 2026, still not replaced – building more than ever.

Fables, Dragons and the Unsane

If you were lucky enough to be developing in the open, or, most probably, unlucky if your organisation didn’t care about the sudden departure of the Zero Data Retention option, at some point or another you probably got access to Fable, the safeguarded version of the model class almighty, Mythos. Admittedly Fable is a strong model, an experience that felt like an improvement over the load-bearing Opus 4.8, unless of course you came anywhere near the dark arts of cybersecurity, because come on, play fair, how are the agents gonna hack you if you go and improve your posture.

If by any chance however you or your employer decided that, hey, I may not wanna be sharing all of my conversations with this vendor, because - reasons, you were most probably granted a free dive into the “Unsane”. Unsane, beyond sanity, and yet not insane. A period where all the hard-earned learnings from the eons of Opus 4.6 through Opus 4.8 started to collapse. And not only for the sham that Opus 5 was, but also for models that once worked just absolutely right.

At that moment I either had to do something about forge and its products, or I would be recommending something with demonstrable performance degradation over a very short time. Something that I had indeed used to build a whole lot of things but suddenly was giving me a hard time with laughable issues like agents not trusting each other’s output, going into token apocalypse loops like mad, or ignoring simple instructions that were once followed without significant hiccups.

And lo and behold, forge was reborn, coming back stronger than ever – but this time, with an exit plan.

The Harness

The evidence was not really pointing to the model being the culprit, though that would be a comforting answer. Guilty as charged, I had my “fun” times with Opus 5, but the degradation was clearly there with previous models too.

First suspect, the harness. I did not rush to attribute it to malice, but it could very well be that the harness evolved to accommodate the newer, better, and enhanced Mythos-class models which we mortals were barred from using. I immediately opted for something open source, to give a chance to something whose success didn’t immediately depend on how many tokens I burn.

I tried out various harnesses, I spent some time in the pi ecosystem, then the DeepSeek Harness made a bang and caught my attention, but it was evident that they were all asking me to take care of a bit too much, and with the ground moving under our feet at such breakneck pace, I was certainly not in the “doing too much” business. In fact, the whole idea behind forge is about achieving the most by solving the select few problems that really matter.

Enter opencode

That made the choice to make opencode the second harness that forge supports pretty easy. A comparatively polished product, with Dax Raad et al developing it in public, and a plethora of open models readily available to test, for a mere $10 on the opencode-go subscription.

There were really only a couple of gaps.

forge outputs were tuned to work best with dynamic workflows. Agents organised in workflows of arbitrary width and depth depending on the task, orchestrated from a main session, on the engineer’s command, with the sole purpose of augmenting engineers in walking their code through the steps that the (at least in name) agile process of their organisation dictates, all the way to release and deploy. And this one was easy to solve. opencode is rather easy to extend, and thus, without too much fuss after a few test runs in order to bring the feel as close as possible to the one I was familiar with from Claude Code it was ready.

The other gap is the auto mode. I yielded, I had no time to crack this one yet. But with decision models becoming the new cool kids on the block, I suspect we are going to be able to get quite close real soon.

Was the harness the real problem though? I had to know.

The Workflow

Next up was the workflow itself. And the literature review was clear and brutal; agents traversing graphs perform significantly better when compared to graphs consisting of specialised agents, both in terms of quality and more importantly in terms of cost.

In fact, Google Research, DeepMind, and MIT put a single agent against four different multi-agent topologies, keeping all else the same, finding that, unless the work was truly independent and with clear splits, in multi-agent approaches sequential planning degraded up to 70%, with every single multi-agent configuration doing worse than the lone agent on SWE-bench. Granted, it was never a blowout in terms of percentages, but even the small defeats came at a steep cost.

Tran and Kiela from Stanford say that the reason is annoyingly simple. Information theory didn’t stop applying because we got new toys. Every context split, every summary, every handoff and every command acts as lossy compression, and destroys information that we cannot get back. The spec-driven attraction was too shiny even for me to resist. Facepalm emoji, and thoughts of compassion for my orchestrator agent drowning in the endless Opus 5 blabber.

But more agents, more work done, right? No. Resounding no. UCL ran a couple thousand multi-agent sessions to find that messaging among them increases near-quadratically with team size, and oh the surprise, defining a coordinator among them has little to no effect. What you get instead is your agents enjoying the pinnacle of productivity. A first-class meeting-about-a-meeting situation.

So what do you do? You flip it. One task, one agent, start to finish. The agent traverses the graph with a predefined round budget, loading skills progressively only once needed – understand, build, validate, review, fix, clear, verify, you name it. Fan-out is still a thing, just placed where it belongs.

Trust but verify

There is of course a catch, but this one we know. Agents are terrible critics of their own work and aren’t really shy about demonstrating occasionally treacherous behaviour – quietly modifying test files to pass the tests, falsely reporting successes on utter failures, skipping verification steps, you know the drill. To get past this, the last step of the graph is not agentic at all. We just have to do some work, define what our validation looks like and come up with a deterministic script the agent has to execute to get past the gates.

Pretty much what we had to do for as long as there have been untrusted contributors to our codebases, and quite possibly one of the reasons why substitution by AI is still a myth, at least for some of us.

How did I verify? I pretty much had the graph build itself and then immediately turned it on real work. Not quite the controlled experiment, I know, but we also got work to do.

Long Live the King

Right as all of this was coming out of the oven, Opus 5.5 came along. Ready to sit on its throne, the new undisputed king of the hill, my hill at least, for now. Faith in machines, restored.

However, this time around, the king’s grasp on the throne feels weakened, ephemeral even. Kimi K3 made its landing on AWS Bedrock as the prophecies foretold. GLM, DeepSeek, and the rest of the open crowd on opencode-go and a myriad of other providers now leave a very good aftertaste, albeit not there yet. A “yes, and” kind of feeling. Is this why the king decided to finally show up? Who knows, I enjoy speculation but this is not the place for it.

What I know is that a quick glance over the last few thousand years of history tells us that royalty tends to either be forcibly removed or left to fade into oblivion. Only now, forge has an exit. Some other king, or no kings at all – switching is now just a setting. And if anyone tries to play funny games again, while dreaming of moats that try to lock models out of harnesses, I have the tool for that too.

forge is at v0.10 now, speaks both Claude Code and opencode, and is still very much a work in progress. MIT licensed, issues and PRs welcome.

Code: github.com/ktoulgaridis/forge

Act one, if you missed it: forge init

You Already Have a Format

So here's the thing most AI wielders keep missing; chances are your company already has a system. You already have a Jira or equivalent, or a Github/Gitlab, or both, plus a CI and a review culture and a compliance regime. Whether you operate them well is a separate conversation, whether they are the right ones for the shape of your organization is another, but they exist; people know them, and they hold years of accumulated process knowledge and artifacts. Most agent frameworks however, respond to this by rebuilding the universe, a new tracker, a new memory store, a new workflow engine. All of it yours to maintain now. Congrats! You’ve adopted a pet, a rather complex and rapidly evolving one, to be exact.

If that’s not backwards, then what is? And if it is indeed backwards then why don’t we let the agents play to the strengths of the tools we already run and pay for?

A Generator, Not a Framework

forge is my attempt at that, and I open-sourced this week. Unlike most frameworks, forge is a generator; it interviews your organization, mapping the tools you already run, the process constraints you’re held to, the identities your agents act under, and emits a lightweight, standalone Claude Code plugin that your org owns. Owns. As in it lives in your repo, not mine. That plugin carries built-in adapters for your Jira, your GitHub, your CI; it enforces the boundaries between six distinct agent roles; and it keeps a wiki schema where code remains the source of truth. From then on every new project starts from it, as one command opens a project workspace with your org’s tools, roles, and rules already wired in. Custom by design: forge@Acme ≠ forge@Globex.

Code Is a Commodity. Judgment Isn’t

Every forge product keeps the engineer front and center; we don’t try to automate all the things. The agents type, the engineers solve the problems. That’s what the role boundaries are actually for — humans architect, review, and integrate; agents handle the bulk of implementation. Code was always the cheap part of software engineering, and it just got cheaper (yes cliche). What’s scarce is knowing what to build, what to refuse to build, and whether what shipped is right. Code is a commodity now. Judgment isn’t.

Which raises the obvious question; how do you know what shipped is right, when you didn’t type it? Let’s be honest with each other, nobody reviews tens of thousands of generated lines and does it well, and pretending otherwise is exactly how slop gets merged and shipped. The answer happens to be older than the agents themselves: Test-driven development (TDD). The engineer writes down what done means (an executable test, failing) and the agents iterate until it passes. The test is the spec, the contract, and the leash, all in one artifact. And this is where the engineer’s judgment actually lives now; not in reading every line, but in defining what correct looks like before a single line exists. TDD was always good advice that we mostly aspired to. With agents it stops being a discipline and becomes the steering wheel.

And the north star all of this serves? Continuous delivery. Once acceptance tests gate the work you can ship in slices small enough that any single one of them is boring; trunk-based, always releasable, integrated within hours instead of weeks. And you will need it, believe me, because agents produce a week’s worth of code in an afternoon, and the only safe way to absorb that kind of throughput is small batches through a pipeline you actually trust. Big-bang integration was already a bad idea back when humans were the bottleneck. With agents it’s malpractice.

And underneath both sits a single rule; undeniable proof. Agents are happy fools when it comes to their own progress, and “done” from an agent means precisely nothing until it cites an artifact. Think a green pipeline, a merged request, a manifest sitting in the repo where anyone can click it. forge products enforce this everywhere: no status claim without a receipt, and the wiki obeys the same law, pages cite code rather than restate it, because code is the only document that cannot drift from itself. If the proof doesn’t exist, the work didn’t happen. And if that sounds harsh, just wait until the first time an agent proudly reports shipping something that doesn’t compile, but you’ve most probably already been there by now.

It Pays to Be Lazy

The same economy applies to context. The fastest way to flush tokens down the drain is to dump your entire org brain into every agent's window and pray that relevance emerges. forge products work on progressive disclosure instead; a thin schema tells the agent what exists, the wiki layer gets pulled in only when the task actually needs it, raw sources sit behind that, and code remains the final word. Each role loads what its job requires and nothing more, and the reviewer sees the diff – never the implementer's reasoning. Which, if you think about it, is progressive disclosure doing double duty as a quality gate. Smaller contexts, sharper agents, fewer bucks into the token-grinder.

And forge stays deliberately thin, because the most underrated strategy in AI right now is laziness. Anthropic ships faster than you can maintain scaffolding. Every clever layer you build today is a layer you’ll rip out when the platform does it natively next quarter; remember subagents, hooks, plugins, skills, dynamic workflows? They were all somebody’s custom harness once. What really pays, is to build the minimum that encodes your org, and stay light enough to absorb the next Claude Code feature without throwing anything away. With forge you don’t fork and you don’t migrate: when the generator improves, you re-run it over your config and re-emit.

Everything Changed. Nothing Did

Everything changed, and yet everything remains stubbornly the same. TDD, continuous delivery, small batches, proofs over promises, code as the single source of truth, options; none of it is new. It’s the same boring canon we’ve all been nodding along to at conferences for at least twenty years, and practicing on our better days. The agents didn’t repeal software engineering, they just raised the price of skipping it. What was good advice yesterday is simply mandatory today, and the teams that already live the boring fundamentals are already moving embarrassingly fast.

It’s still very early, v0.3.0, working but incomplete. The full generator design lives in the repo (docs/GENERATOR.md), and the distance between it and the code is the roadmap. But the patterns aren’t theoretical: production platforms do ship like this, built by a handful of humans and teams of agents working exactly this way.

If your org has more than one team using Claude Code, you do have this problem. Whether you’ve noticed yet or not is up to you, but your bill and your outcomes certainly won’t lie.

github.com/ktoulgaridis/forge - MIT License. Issues welcome.

This is the first post of discoinferno.dev! learning through pain, fire, and production incidents. SRE, platform engineering, software craft, and AI from the trenches. Subscribe any of that’s your thing.