While The Frontier Is Still Open

By Yassine Bekri — May 22, 2026

There are two kinds of software teams now.

The first kind has noticed that something very strange happened, and has rearranged its life around it.

The second kind is still asking whether the strange thing is “production-ready”.

I don’t mean this as an insult. “Production-ready” used to be a real question. You had a new framework, or database, or cloud service, or frontend religion, and you asked: is this stable enough to trust? Will it still exist next year? Does it have docs? Does it work with our deployment pipeline? Has anyone with a conference badge said the phrase “enterprise-grade” near it?

This was not stupid. In the old world, adopting bad tools too early was expensive. You could lose months migrating to something that turned into a GitHub archive and a maintainer’s final commit reading “sorry, burned out”.

But agentic engineering is not quite a tool.

It is closer to a new organism that has appeared in the development process. Sometimes it writes code. Sometimes it writes the wrong code with great confidence. Sometimes it explains an old codebase better than the senior engineer who built it, except for the part where it invents a function that does not exist. Sometimes it is a junior developer, sometimes a swarm of interns, sometimes a compiler for intentions, sometimes a drunk architect with perfect typing speed.

The mistake is trying to decide whether this organism is “good” in the abstract.

Good at what?

Good at replacing a senior engineer? Usually no.

Good at taking a half-specified product idea and turning it into a maintainable system while you go drink coffee? Also no, unless your coffee contains ketamine and you are dreaming.

Good at compressing the distance between intention and working software, if surrounded by the right harness, context, constraints, review loops, and human judgment?

Yes.

And that yes is large enough to reorganize the industry around.

I.

The most visible divide in software right now is not between AI believers and AI skeptics. That was last year’s debate, and it was boring even then.

The divide is between people who have emotionally accepted that the workflow has changed, and people who have only intellectually accepted that models are useful.

The second group will say things like:

“Of course we use AI.”

Then you ask what that means.

They use Cursor occasionally. Someone has ChatGPT open in another tab. A developer once generated a unit test. The CTO has a slide about AI productivity. There is a policy document explaining which data may not be pasted into which chatbot. A task force is evaluating Copilot.

This is like saying your army has adopted aviation because one colonel owns a kite.

The first group looks different. Their workflows are mutating weekly. They no longer think of the model as a clever autocomplete box. They think in terms of context surfaces, tool permissions, memory boundaries, task decomposition, agent roles, eval traces, failure modes, recovery loops, and harness design.

They do not ask, “Can AI code?”

They ask:

What does the agent need to know?

How do we stop it from knowing the wrong thing?

Which parts of the task should be decomposed before the model sees them?

Where does human review add the most value?

When should the agent be allowed to touch the filesystem?

What counts as done?

What should be persisted between runs?

How do we prevent today’s clever hack from becoming tomorrow’s haunted cathedral?

These are not philosophical questions. They are engineering questions. More precisely, they are what engineering questions look like when the engineer is no longer the only mind touching the work.

II.

The strange thing is that smaller, younger teams seem to understand this faster.

The young teams have less to unlearn.

This is unfair, because senior engineers really do know things. They know why rewrites fail. They know why demos lie. They know why the database is the way it is. They know that the customer’s simple request will interact with the billing system, the permissions layer, the one table nobody is allowed to touch, and Frank, who left in 2019 but whose opinions are still running in production.

All of this is real knowledge.

The problem is that real knowledge can become immune response.

A new workflow enters the organization. It looks dangerous, because it is dangerous. It produces code too quickly. It ignores implicit conventions. It doesn’t respect the ancient trauma encoded in the architecture. It makes juniors too confident and seniors too annoyed. It suggests replacing a carefully maintained internal library with twelve lines of fresh nonsense. The organization produces antibodies.

The antibodies are not wrong.

But sometimes the pathogen is the cure.

Small teams have fewer antibodies. They can say: “This is weird, but it works 30% of the time. Can we make it work 50% of the time by tomorrow?” They do not need to schedule a governance meeting to define what “agent” means. They can break the workflow, notice where it broke, and rebuild it before the big company has decided whether agentic engineering belongs under Engineering, Product, IT, Innovation, or the new AI Transformation Office, whose first act is always to create a SharePoint folder.

This is the part that feels new.

For most of software history, the big players had structural advantages. They had the best engineers, the best infrastructure, the best distribution, the most data, the largest customers, the most credibility, and the most lawyers. Small teams could still win, but they usually needed either a sharp product insight or a market the incumbents ignored.

Now a small team can sometimes be ahead simply because it is willing to change its development process every ten days.

This should not be possible. And yet here we are.

III.

There is a depressing version of this post where I spend the next 1,500 words trying to convince skeptics that agentic engineering is real.

I am not going to write that post.

Partly because others have written it. Partly because the people who need it most will not be convinced by it. Mostly because it has become less and less obvious why anyone should spend energy persuading the other camp.

This is the recurring pattern in technological shifts. At first, smart skeptics are often right about the flaws. The early version really is ugly. It really does fail in embarrassing ways. It really cannot do many of the things its evangelists claim. But the evangelists, by using it, get exposed to the next layer of problems earlier. By the time the skeptics have won the argument about version one, the practitioners are on version four, and the argument has become a historical reenactment.

Agentic engineering has many real flaws.

Agents drift. Context rots. Models hallucinate. Tool use is brittle. Long-running tasks collapse into subtle nonsense. Generated code can become architectural debt with better grammar. The model can obey the letter of the task while violating the spirit so completely that you start to understand why ancient people believed in trickster gods.

All true.

Also: irrelevant, unless you are using those failures as raw material.

The interesting people are not saying “agents work”.

They are saying “agents fail in specific ways, and those ways imply specific harnesses”.

That sentence is the whole game.

IV.

Since roughly December, the people who have accepted this have started to move like a loose collective intelligence.

Not a community in the soft, HR sense of “people with shared values”. More like a distributed problem-solving organism with a bad sleep schedule.

A pattern appears somewhere.

Karpathy names something, or half-names it, or makes a remark that causes everyone to realize they have been circling the same concept without a handle.

Someone posts a diagram.

Someone else posts a repo.

A third person says the repo is wrong because it ignores memory.

A fourth person says memory is a trap and the real issue is context hygiene.

A fifth person coins a term that is slightly worse than the previous term but somehow catches on.

Substack digests it.

Twitter compresses it into slogans.

A small lab implements it over the weekend.

By Tuesday, it is no longer the frontier. It is assumed background knowledge for the next argument.

This is exhausting if you want stability.

It is exhilarating if you like being alive.

There is a rhythm to it now. Each week, the collective seems to chew through one bottleneck and expose another.

First the problem is prompting.

Then the problem is that prompting is too weak a concept, so you need workflows.

Then the problem is that workflows lose state, so you need memory.

Then the problem is that memory poisons the agent, so you need selective memory.

Then the problem is that selective memory requires judgment, so you need evals.

Then the problem is that evals are too static, so you need traces.

Then the problem is that traces show the agent doing something insane, so you need better tool boundaries.

Then the problem is that tool boundaries slow it down, so you need permissions.

Then the problem is that permissions encode your organization’s ontology, which turns out to be less a clean tree and more a drawer full of cables.

At each stage, the “solution” does not solve the field. It buys admission to the next room.

This is how progress looks when nobody has the map.

V.

This will not last forever.

The current phase has a slightly deceptive openness. It feels as if anyone with taste, curiosity, and enough willingness to break things can keep up. For now, that is often true.

But fields do not remain liquid forever. They crystallize.

We are already seeing the early signs in the terminology.

Nobody knows where context engineering ends and harness engineering begins. Nobody knows whether agentic engineering is a subset of software engineering, a replacement for software engineering, or just software engineering after it ate a glowing mushroom. Nobody knows whether an “agent” needs autonomy, tool use, persistence, planning, or merely a sufficiently ambitious README.

The same word now means five things depending on whether it is being used by a researcher, a founder, a developer, a consultant, or a LinkedIn person standing too close to a ring light.

This is annoying. It is also normal.

A field first discovers phenomena, then invents words, then fights about the words, then builds institutions around the winning words, then teaches students a simplified version in which the words seem to have been obvious all along.

We are somewhere between “discovers phenomena” and “fights about the words”.

Later, this will fragment into real specialties. There will be people whose whole craft is context architecture. Others will specialize in agent evaluation. Others in coding harnesses. Others in human review interfaces. Others in tool environments. Others in compliance layers for regulated industries. Others in legacy-system agent integration, which sounds boring until you realize half the world still runs on software that treats UTF-8 as a rumor.

At that point, the frontier will become harder to reach casually. You will not be able to stay current by reading a few posts and hacking on Sunday. The problems will require depth, accumulated failures, benchmarks, infrastructure, and probably a few German procurement documents.

But we are not fully there yet.

Right now, a small team can still compete.

Not with the foundation model labs. Let us not become delusional. An eight-person team in Düsseldorf is not pretraining the next frontier model in a basement unless the basement contains Norway’s energy grid.

But in the application layer, in harnesses, in workflows, in the practical art of turning model capability into shipped software, small teams can absolutely be near the frontier.

Sometimes they can be ahead.

This is one of the most cheerful facts in software right now.

VI.

There is a funny humiliation in watching a big company announce, with professional lighting and a launch video, a product that resembles something our small team built three months earlier with caffeine and contempt for sleep.

This should make the small team proud.

It should also make them afraid.

Proud, because it means we were looking in the right direction.

Afraid, because it means the big company is looking there now too.

The comforting interpretation is: “We are as good as the big players.”

The more accurate interpretation is: “The frontier is so young that the big players have not yet converted their structural advantages into dominance.”

That window is precious. It is also temporary.

When there is no playbook, experience has a strange value curve. Some experience helps enormously. Taste helps. Engineering discipline helps. Knowing how systems fail helps. Having shipped real software helps. Having scars helps, provided you do not start worshipping the scar tissue.

But some experience hurts.

The older process says: define requirements, assign tickets, estimate, implement, review, test, deploy.

The new process says something more like: define intent, construct context, delegate exploration, inspect traces, constrain tools, recover from failure, fold discoveries back into the harness, then maybe implement, except implementation has been happening the whole time and the boundary between design and execution is now suspiciously blurry.

If your identity is built around the old sequence, the new one looks like chaos.

If you have no identity yet, it looks like Tuesday.

This is why young teams are often faster here. Not because youth is magic. Youth produces plenty of stupidity. But when everything is changing, stupidity plus fast feedback can beat wisdom plus slow adaptation.

The ideal is not inexperience. The ideal is experience without calcification.

VII.

This brings me to Mia.

Mia is our agentic harness at the Düsseldorf AI Lab. We have been developing it for the last nine months. We built it because we needed to ship.

We were building software for German companies and NGOs, in environments where the constraints were not optional. Legacy systems. Legal requirements. Weird customer processes. Documents that arrive by email in formats last seen in the Bronze Age. Humans who want automation, but also want to know what the automation did, why it did it, where it failed, and whether they can still blame a person.

Mia emerged from that pressure.

It is not “an agent”. That phrase has become too overloaded to be useful. Mia is closer to a harness for making agentic development less like summoning a demon and more like operating a machine shop.

A machine shop has benches, tools, labels, procedures, logs, apprentices, and someone who knows when to stop the apprentice from using the table saw.

The harness matters because raw model capability is not enough. This has been the central lesson of the last months. The difference between impressive demo and useful system is rarely “the model needs to be smarter” in the abstract. Often the model is smart enough, but the environment around it is stupid.

It has the wrong context.

It has too much context.

It has no way to check whether it succeeded.

It has tools but no discipline.

It has memory but no taste.

It has autonomy but no adult supervision.

It has a task, but not the actual task, because the actual task lives in the head of a founder who said “just make it clean and enterprise-ready” and then disappeared into a meeting.

Mia is our attempt to build the adult supervision, without killing the speed that made the whole thing valuable in the first place.

It helped us build and ship software faster. It helped us avoid the common failure mode where agentic coding works for the first 80% and then leaves you with a glittering ruin. It helped us win recognition at OMR festival in Hamburg among the top AI-native builders in Germany. It helped us build systems for NGOs and companies that needed more than a flashy prototype.

And now we are going to open-source it.

VIII.

From a business standpoint, this feels somewhere between generous and stupid.

There is a classic startup proverb that says: do not give away your secret sauce.

This is good advice if you are a sauce company.

But I am less sure it applies when the kitchen is on a moving train, the ingredients change every week, and half the chefs are discovering new forms of fire.

The naive version of open-sourcing Mia is:

“We are giving away our golden egg.”

This is close, but wrong.

A golden egg is a static asset. You protect it because once someone else has it, your advantage is gone. But in a fast-moving technical field, the artifact is only part of the advantage. The deeper advantage is the ability to keep producing artifacts at the frontier.

Better analogy:

We are publishing one map from an expedition, while the continent is still rearranging itself.

This can still be dangerous. Maps have value. People can use them. Competitors can learn from them. Some consultant can put our ideas into a deck, add three hexagons, and charge more than we do. This is the natural circle of life, except with worse fonts.

But the alternative is worse.

If every serious team hides its harness, we all move slower. Everyone rediscovers the same boring failures. Everyone independently learns that too much context is bad, that agents need constrained tools, that memory is not automatically wisdom, that long tasks need checkpoints, that “done” needs to be machine-checkable where possible and human-reviewable where not.

This is not noble secrecy. It is duplicated suffering.

In a slow field, secrecy compounds.

In a fast field, shared learning compounds.

The reason to open-source Mia is not that we have solved agentic engineering. We have not. Nobody has. The reason is that we have solved enough local problems to make our failures and patterns useful to others, and we would like to see what happens when more serious teams build on them instead of starting from zero.

Also, selfishly: the fastest way to find the next problems is to let more people collide with the current solution.

IX.

The future of software is undefined.

Usually this sentence means nothing. It belongs on the opening slide of a keynote delivered by someone with a headset microphone and no commits.

Here I mean it literally.

We do not know what the basic unit of software work will be.

Maybe it remains the ticket. Maybe it becomes the spec. Maybe it becomes the trace. Maybe it becomes the harness run. Maybe the important artifact is no longer the code diff but the structured intention that generated the code diff, plus the evaluation proving it did what the human meant.

We do not know what the developer becomes.

Maybe a developer is still mostly a code writer. Maybe a developer becomes a system designer managing model labor. Maybe the best developers become more like editors, reviewers, architects, and toolsmiths. Maybe juniors become more powerful but also more dangerous. Maybe seniors become more valuable when they can encode judgment into workflows, and less valuable when all they can do is remember how things used to be done.

We do not know what software companies become.

Maybe the same companies produce more output with fewer people. Maybe tiny teams become frighteningly capable. Maybe the bottleneck moves from implementation to taste, distribution, trust, domain access, and willingness to take responsibility for what the agents did. Maybe the whole industry spends five years discovering that writing code was never the hard part, and then another five years arguing about who said this first.

We do not know.

That is the point.

There is no settled playbook. There are only live experiments.

Some of them are happening inside the big labs. Some are happening inside large companies with serious constraints and serious customers. And some are happening in small rooms with young teams who have no business keeping up, except that the new world has temporarily forgotten to check credentials.

This is a rare moment.

The barrier to entry has dropped to something like brainpower, taste, stamina, and willingness to break your own workflow before someone else does.

It will not stay this open.

For now, the thing is still alive.

So we are opening Mia.

Because we want more teams inside the live part of the problem.

Because the next bottleneck is more interesting than the current moat.

Because the future of software will be discovered faster by people comparing notes than by people guarding screenshots.

Because if a small lab in Düsseldorf can build something useful from nine months of collisions with reality, maybe another team can take it, break it, improve it, and show us the next room.

And because, for the moment, walking through the door is still more fun than arguing with the people who insist it is a wall.