DEV Community: Guy

Vibe Coding Isn't Bad, You Are

Guy — Wed, 04 Mar 2026 15:37:29 +0000

I cannot get through a day without reading that everything produced by vibe coding is awful. The code isn’t production ready, config values are hardcoded, secrets leak out on the client side and entire databases are exposed. It’s best to not even consider a multi-tenant SaaS solution.

And we’re in a polarised world – so everyone is either for or against vibe coding.

The vibers? It democratises development, anyone can put their ideas into practice, and it saves a tonne of time testing a concept before investing months and thousands of dollars?

The haters? The quality is poor, developers will lose their jobs, it’s just AI generated slop, it’s impossible to finish off an idea when things get complicated.

Is vibe coding actually awful, or are you just doing it wrong?

It’s A Tool, Not A Religion

Vibe coding isn’t a philosophical principle. It’s a set of tools. If you gave me bag of tools and some raw materials and told me to build a house I’d laugh and politely decline. That’s not my skillset.

If you gave me a construction crew, told me that they’ll do what I tell them but no more and asked me to build a house – I might be tempted to have a go.

I’d most likely not consider foundation depth sufficiently, miss a huge amount of bracing in the roof and put bathrooms all over the place even if the pipework made no sense. I’d have an idea of what I wanted but at the end of it the house would fall down or not even finish construction.

I shouldn’t kid myself about construction. I’ve got a vague idea what a lintel is, I’ve got a reasonable idea of how plumbing and electrical wiring works, but I have none of the skills to design, oversee or construct a house. For that reason, I also am woefully unqualified to oversee a team of people following my instructions.

This is vibe coding.

You’re given an incredibly complicated team of experts that will help you but the gotcha is they’ll only do what you want and nothing more.

My Buddy Claude

I started working with Claude last July. I signed up, started a subscription and shouted “create me a game in the style of Monkey Island but based around a cat that rides a crinkle cut chip” into the ether.

I first had a yellow HTML canvas with rectangle on it.

Then I had several failed Unity projects that wouldn’t build.

Finally, I created a console app that was only pretty awful.

I’d spent $200 on AI credits. Oy.

We’ve evolved since then. I started using Claude to work through architectural ideas. I’ve written previously about the five-day coding binge where I worked with Claude to create my own programming language, compiler, assembler and virtual machine from scratch with zero experience. But Claude wrote none of it.

Over the last three months things have changed, and Claude probably writes 75% of my code. It’s a combination of model improvements and how I manage Claude.

I no longer treat it as a font of all knowledge – but rather I tightly define what I want to be done, I focus on testing, I review as if a member of my team had done the work and I iterate.

The key to it all though is that I am tightly defining exactly what I want it to create, I can verify that it is correct and it goes through exactly the same process as code that a member of my team would write.

I can do this because I’ve been coding since I was seven and thirty-five years later, I have a fairly good idea how this is supposed to work. But I still couldn’t vibe code a Unity app as I have no experience in that sphere.

With any tool you need to know how to use it. Vibe coding tools are no different.

I’m sorry – but vibe coding isn’t the problem. The users are.

If You Can’t Code, You Can’t Vibe Code

I can code. I get phenomenal results out of AI coding tools now. This year they have finally reached the ‘code per hour’ that I can produce giving me the ability to oversee rather than code.

But if you can’t code, that is not going to be your experience.

Sure, you can create a quick proof of concept and see if an idea works. But it will be no better than my theoretically wonky house. It will fall down.

To use any vibe coding tool, you need to understand code, architecture, security, performance, deployments and monitoring. If you don’t know what you need to ask for the AI won’t magically think about it.

And if you’re a developer and you know all that? It still might not be for you. What feature are you building? What does a user need? What should it look like? What kind of test plan do you need to follow? How should you sequence your features to engage with users more quickly and what adds the most business value?

None of those were technical questions but they all need answering if you want to build an actual product.

Not All Is Lost Though

If you want to vibe code, then that's great. Use it to learn. Ask questions. Read widely - not just about code but about all the disciplines that make a product. Throw away what you created and start again. Use multiple tools and learn how to master them.

The future absolutely contains 'vibe coder' as a role - but it will be someone with sufficient inter-disciplinary experience to oversee the AI tools they're using. You don't need mile-deep knowledge in everything, but you do need mile-wide, inch-deep understanding across the board to even have a chance of asking the right questions.

It's not a magic box. It's a set of tools.

Master them and you can create something extraordinary.

Shout into the void and a yellow HTML canvas can be yours.

Vibe Coding Isn't Bad, You Are

Guy — Wed, 04 Mar 2026 15:27:31 +0000

And we’re in a polarised world – so everyone is either for or against vibe coding.

The vibers? It democratises development, anyone can put their ideas into practice, and it saves a tonne of time testing a concept before investing months and thousands of dollars?

The haters? The quality is poor, developers will lose their jobs, it’s just AI generated slop, it’s impossible to finish off an idea when things get complicated.

Is vibe coding actually awful, or are you just doing it wrong?

It’s A Tool, Not A Religion

If you gave me a construction crew, told me that they’ll do what I tell them but no more and asked me to build a house – I might be tempted to have a go.

This is vibe coding.

You’re given an incredibly complicated team of experts that will help you but the gotcha is they’ll only do what you want and nothing more.

My Buddy Claude

I first had a yellow HTML canvas with rectangle on it.

Then I had several failed Unity projects that wouldn’t build.

Finally, I created a console app that was only pretty awful.

I’d spent $200 on AI credits. Oy.

Over the last three months things have changed, and Claude probably writes 75% of my code. It’s a combination of model improvements and how I manage Claude.

I no longer treat it as a font of all knowledge – but rather I tightly define what I want to be done, I focus on testing, I review as if a member of my team had done the work and I iterate.

With any tool you need to know how to use it. Vibe coding tools are no different.

I’m sorry – but vibe coding isn’t the problem. The users are.

If You Can’t Code, You Can’t Vibe Code

I can code. I get phenomenal results out of AI coding tools now. This year they have finally reached the ‘code per hour’ that I can produce giving me the ability to oversee rather than code.

But if you can’t code, that is not going to be your experience.

Sure, you can create a quick proof of concept and see if an idea works. But it will be no better than my theoretically wonky house. It will fall down.

None of those were technical questions but they all need answering if you want to build an actual product.

Not All Is Lost Though

It's not a magic box. It's a set of tools.

Master them and you can create something extraordinary.

Shout into the void and a yellow HTML canvas can be yours.

Your AI Product Is Not A Real Business

Guy — Mon, 23 Feb 2026 10:19:57 +0000

I just got back from STEP 2026 in Dubai. Whilst there were some genuinely amazing businesses there, I also saw a lot of companies that won’t make their first year.

Most startups now splash AI on to all their marketing. AI is not your product. AI itself does not deliver business value. Unless you are a frontier lab, AI is nothing more than a tool in your stack. Nobody is there shouting ‘MongoDB-enabled trading platform’.

Users don’t care if it’s AI. Investors don’t care if it’s AI. They care about what it does, what problem it solves and whether there’s space for it in the market.

And if you want to sell to real businesses? I've sat across the table from $5bn consultancies evaluating AI tools. They ask about your architecture, your data residency, how to deploy it on-prem and what you actually own. If the answer is 'we call the OpenAI API' – the meeting is over.

Wrappers… Everywhere

There are tens of thousands of AI startups right now whose core premise is:

Vague idea about product
Put a bit of a wrapper around an AI model
Display it to the user
Charge $29/month

This is not a business. Your users could most likely just use ChatGPT – why would they want another subscription?

It’s not defensible. There’s no IP there. There’s nothing unique. On the contrary your whole business is at risk of changes to a model.

Remember when everyone built apps on top of Twitter and then they changed API rules overnight? That can happen to you if you’re just wrapping a model. It’s even worse here as the frontier models have incentive to compete against you when you come up with a good, simple idea.

Let’s not even get into the fact that you’re open to a huge cost base where you aren’t in control of input or output tokens and just rack up an AI bill behind the scenes.

The playbook right now seems to be:

Wrapper launches and gets traction
Model provider notices traction
Model provider adds features to handle some of this in house
Business case evaporates

You’re doing market research for OpenAI – and they can execute better than you can.

Stop doing this.

Vibe Coding Is Making This Worse

My most successful summary of Brunelly at STEP 2026 was ‘You know what vibe coding is right? We’re the opposite of that. We actually create real-world enterprise quality software’.

That has to be the opener because vibe coding has got such a bad reputation in the real-world. Security gaps, bugs, scalability, deployments, infrastructure management, compliance – all non-existent.

And vibe coded AI products take the worst of all worlds. The simplest AI wrapper around some basic CRUD operations but lacking any scalability.

Please stop.

There’s A Better Way To Do AI

I’ve spent the last year building Maitento – our AI native operating system. Think of it as a cross between Unix and AWS but AI native. Models are drivers. There are different process types (Linux containers, AI’s interacting with each other, apps developed in our own programming language, code generation orchestration). Every agent can connect to any OpenAPI or MCP server out there. Applications are defined declaratively. Shell. RAG. Memory system. Context management. Multi-modal. There’s a lot.

This is the iceberg we needed to create a real enterprise-ready AI-enabled application.

Why did we need it? Extensibility. Quality. Scalability. Performance. Speed of development. Duct-taping a bunch of Python scripts together didn’t cut it.

I’m not saying you need the level of orchestration that we have – but wanted to emphasise that the moving pieces in enterprise grade AI orchestration are far more complex.

Do you think ChatGPT is just a wrapper around their own API with some system prompts? There’s file management, prompt injection detection, context analysis, memory management, rolling context windows, deployments, scalability, backend queueing, real-time streaming across millions of users, multi-modal input, distributed Python execution environments. ChatGPT itself has a ‘call the model’ step but it’s the tiniest part of the overall infrastructure.

The Uncomfortable Truth

It’s easy to call an API. It’s far harder to build real infrastructure than many founders realise.

Founders want to ship so rush to deliver. But that doesn’t mean you’re actually building a business – you’re building a tech demo.

A demo is not a product. It’s a controlled environment that doesn’t replicate reality.

The gap between impressive demo and production-grade product in AI is wider than in any other category of software. Because AI systems fail in ways that traditional software doesn't. They hallucinate, they lose context, they confidently produce wrong outputs.

Managing that failure mode requires infrastructure. Real infrastructure. Not a try/catch block around an API call.

Build Something That Matters

The AI gold rush is producing a lot of shovels.

Most of those shovels are made of cardboard.

The companies that will still exist in five years are the ones building real infrastructure today. Not just calling APIs. Not chaining prompts. Not wrapping someone else's intelligence in a pretty interface and calling it innovation.

Build the thing that's hard to build. That's the only strategy that works. It always has been.

If you were able to build it in a few days, so can anyone else.

If it’s difficult for you then it is for your competitors.

And then you may actually have a genuinely novel business.

Your AI Product Is Not A Real Business

Guy — Mon, 23 Feb 2026 10:08:59 +0000

I just got back from STEP 2026 in Dubai. Whilst there were some genuinely amazing businesses there, I also saw a lot of companies that won’t make their first year.

Users don’t care if it’s AI. Investors don’t care if it’s AI. They care about what it does, what problem it solves and whether there’s space for it in the market.

Wrappers… Everywhere

There are tens of thousands of AI startups right now whose core premise is:

Vague idea about product
Put a bit of a wrapper around an AI model
Display it to the user
Charge $29/month

This is not a business. Your users could most likely just use ChatGPT – why would they want another subscription?

It’s not defensible. There’s no IP there. There’s nothing unique. On the contrary your whole business is at risk of changes to a model.

Let’s not even get into the fact that you’re open to a huge cost base where you aren’t in control of input or output tokens and just rack up an AI bill behind the scenes.

The playbook right now seems to be:

Wrapper launches and gets traction
Model provider notices traction
Model provider adds features to handle some of this in house
Business case evaporates

You’re doing market research for OpenAI – and they can execute better than you can.

Stop doing this.

Vibe Coding Is Making This Worse

My most successful summary of Brunellyat STEP 2026 was ‘You know what vibe coding is right? We’re the opposite of that. We actually create real-world enterprise quality software’.

And vibe coded AI products take the worst of all worlds. The simplest AI wrapper around some basic CRUD operations but lacking any scalability.

Please stop.

There’s A Better Way To Do AI

This is the iceberg we needed to create a real enterprise-ready AI-enabled application.

Why did we need it? Extensibility. Quality. Scalability. Performance. Speed of development. Duct-taping a bunch of Python scripts together didn’t cut it.

I’m not saying you need the level of orchestration that we have – but wanted to emphasise that the moving pieces in enterprise grade AI orchestration are far more complex.

The Uncomfortable Truth

It’s easy to call an API. It’s far harder to build real infrastructure than many founders realise.

Founders want to ship so rush to deliver. But that doesn’t mean you’re actually building a business – you’re building a tech demo.

A demo is not a product. It’s a controlled environment that doesn’t replicate reality.

Managing that failure mode requires infrastructure. Real infrastructure. Not a try/catch block around an API call.

Build Something That Matters

The AI gold rush is producing a lot of shovels.

Most of those shovels are made of cardboard.

Build the thing that's hard to build. That's the only strategy that works. It always has been.

If you were able to build it in a few days, so can anyone else.

If it’s difficult for you then it is for your competitors.

And then you may actually have a genuinely novel business.

How Many Rs Are There Really In Strawberry? AI Is So Stupid

Guy — Mon, 16 Feb 2026 15:16:12 +0000

How many Rs are there in the word strawberry? AI can’t tell you. Apparently. You’ve all seen it. Screenshots, Reddit threads, smug tweets. Models tripping over letters like toddlers. Everyone pointing and laughing. Reassuring stuff.

Wind the clock back a little.

It’s 2023. Image generation is exploding. It’s magical. Also: why does that hand have five fingers and a thumb?

A year later and we’ve uncovered a new, devastating limitation. AI cannot render a wine glass completely full. Half the internet concludes: preposterous technology, case closed.

By 2025 things are truly dire. Models still can’t reliably count the Rs in strawberry. Ask for a seahorse emoji and they spiral into what looks suspiciously like an existential crisis.

These examples don’t matter. Not really.

What’s interesting is how obsessively we return to them.

It Will Never Be Able To Code Though

The memes are obvious if you use AI regularly. But this reflex isn’t limited to casual users. Technical people do it too and often more loudly.

Early 2023: ChatGPT can spit out a half-decent for loop. Sometimes it even answers technical questions correctly. Incredible. But obviously it can’t build an app.

Late 2024: we’ve got basic code-generation tools. Still, no danger. It makes too many mistakes. Barely junior level.

2025: the year of the vibe coder. Suddenly everyone can spin up a website. Sure, it’s riddled with security holes and questionable decisions. So again: no threat. We’ll just clean it up. AI is junk.

For years now, we’ve watched models repeatedly blow past their previous ceilings. Each time, the criticism simply slides sideways to the next obvious limitation.

Reddit is still full of people pointing out how stupid AI is. They’re not wrong. They’re just always late and missing the important part.

Why Is AI Stupid Though?

Before getting philosophical, it’s worth grounding this in reality. These glitches exist for reasons. If you’re building with AI, you need to understand them.

How often have you seen a photograph of a wine glass filled perfectly to the brim? Until recently: almost never. That means that the model hasn’t either. It’s not failing, it’s interpolating from a deeply human dataset.

Why do seahorse emojis cause chaos? Because at some point the internet collectively decided a seahorse emoji existed. Reddit talked about it. Joked about it. Imagined it. The model learns that seahorse emoji is plausible and goes to insert it. Then, mid-generation, it realizes that it doesn’t exist and starts chasing its own tail ad-infinitum.

Why does AI-generated code contain errors? Because it’s trained on Stack Overflow, blogs, gists, half-finished examples and heroic hacks. You didn’t ask it to be secure. You didn’t constrain it. It’s doing exactly what humanity taught it to do.

People say AI is a mirror to the user. It’s also a mirror to humanity… and a lot of what we’re seeing reflected back isn’t flattering.

Why Does It Matter?

Because this isn’t abstract. It has real consequences – for society and for anyone building real products with AI baked in. If you’re developing on top of AI and you don’t understand how it fails, you’re already in trouble.

At Brunelly we assume AI is an intern who found a 20-year-old Stack Overflow answer and ran with it. We prompt heavily, guide explicitly, and still don’t trust the output. Everything passes through multiple agents to surface bugs, performance issues, and security concerns.

The only viable starting point is: it will underperform… so how do we correct it?

But this misunderstanding goes wider than product design.

Stack Overflow is effectively dead. Let that sink in. Once the backbone of developer knowledge, now barely visited. Why? Because ChatGPT gives faster, better, contextual answers.

Music, images, stock photography – already flooded. Half of the lo-fi playlists on Spotify are AI-generated. We just stopped calling it slop.
Remember when everyone complained about AI slop in early 2025? Bad news: it’s still AI. It’s just a lot less sloppy.

Jobs are changing. Trust is changing. Evidence is changing. When you can’t trust photos, videos, reviews or faces then everything downstream shifts with it.

If you’re focused on strawberries, you’re going to wake up one day and wonder when the world quietly re-organised itself.

Why Do We Fixate Though?

Because known failure modes are comforting.

They give us a boundary. Something to point at. Something to laugh at. A place where we still feel safely on top.

Finding a bug in YouTube is annoying. Finding a bug in AI is reassuring.
The problem is that these failures don’t last.

Our mental model of AI already lags reality, and that gap is widening. Even if AI progress stopped tomorrow, it would take years for organisations to fully exploit what already exists. Orchestration is immature. Skills are scarce. Understanding is shallow.

This isn’t about whether LLMs lead to AGI or consciousness. It doesn’t matter. The systems we already have are enough to reshape everything if we actually learn how to use them.

What Does It Mean For Builders?

It means stability is gone. The model you used last month is obsolete. The workaround you wrote last week no longer applies. Every solved edge case is replaced by three new ones.

This isn’t like JavaScript frameworks. This is orders of magnitude faster.
You have to design for an environment that mutates continuously. Trust becomes a UX problem, not a marketing one. AI labels actively reduce confidence.

Textbox-and-send is not a product strategy.

Trust nothing. Convert outputs into constrained state machines. Design experiences that absorb failure gracefully.

We didn’t build Brunelly because AI is magical. We built it because AI is a tool that can be harnessed and nobody else was doing it right. And the orchestrator underneath it evolves almost as fast as the models themselves – because it has to.

And What Does It Mean For All Of Us?

That’s the real question.

I was coding in the 90s during the original internet boom and bust. It wasn’t like this. Code lasted years. Systems were stable. Patterns endured.

This time is different – not because the tech is smarter, but because the pace is relentless.

Laughing at AI’s mistakes is fine. It is funny. But it’s also a distraction.

Assume the world is changing before you notice it.

If you’re building: design for failure, assume the system will outgrow you mid-flight, and plan accordingly.

And maybe stop counting Rs.

How Many Rs Are In Strawberry: AI Is So Stupid

Guy — Mon, 16 Feb 2026 14:42:21 +0000

Wind the clock back a little.

It’s 2023. Image generation is exploding. It’s magical. Also: why does that hand have five fingers and a thumb?

A year later and we’ve uncovered a new, devastating limitation. AI cannot render a wine glass completely full. Half the internet concludes: preposterous technology, case closed.

By 2025 things are truly dire. Models still can’t reliably count the Rs in strawberry. Ask for a seahorse emoji and they spiral into what looks suspiciously like an existential crisis.

These examples don’t matter. Not really.

What’s interesting is how obsessively we return to them.

It Will Never Be Able To Code Though

The memes are obvious if you use AI regularly. But this reflex isn’t limited to casual users. Technical people do it too and often more loudly.

Early 2023: ChatGPT can spit out a half-decent for loop. Sometimes it even answers technical questions correctly. Incredible. But obviously it can’t build an app.

Late 2024: we’ve got basic code-generation tools. Still, no danger. It makes too many mistakes. Barely junior level.

For years now, we’ve watched models repeatedly blow past their previous ceilings. Each time, the criticism simply slides sideways to the next obvious limitation.

Reddit is still full of people pointing out how stupid AI is. They’re not wrong. They’re just always late and missing the important part.

Why Is AI Stupid Though?

Before getting philosophical, it’s worth grounding this in reality. These glitches exist for reasons. If you’re building with AI, you need to understand them.

People say AI is a mirror to the user. It’s also a mirror to humanity… and a lot of what we’re seeing reflected back isn’t flattering.

Why Does It Matter?

The only viable starting point is: it will underperform… so how do we correct it?

But this misunderstanding goes wider than product design.

Stack Overflow is effectively dead. Let that sink in. Once the backbone of developer knowledge, now barely visited. Why? Because ChatGPT gives faster, better, contextual answers.

Jobs are changing. Trust is changing. Evidence is changing. When you can’t trust photos, videos, reviews or faces then everything downstream shifts with it.

If you’re focused on strawberries, you’re going to wake up one day and wonder when the world quietly re-organised itself.

Why Do We Fixate Though?

Because known failure modes are comforting.

They give us a boundary. Something to point at. Something to laugh at. A place where we still feel safely on top.

Finding a bug in YouTube is annoying. Finding a bug in AI is reassuring.
The problem is that these failures don’t last.

Our mental model of AI already lags reality, and that gap is widening.

Even if AI progress stopped tomorrow, it would take years for organisations to fully exploit what already exists. Orchestration is immature. Skills are scarce. Understanding is shallow.

This isn’t about whether LLMs lead to AGI or consciousness. It doesn’t matter. The systems we already have are enough to reshape everything if we actually learn how to use them.

What Does It Mean For Builders?

It means stability is gone. The model you used last month is obsolete. The workaround you wrote last week no longer applies. Every solved edge case is replaced by three new ones.

Textbox-and-send is not a product strategy.

Trust nothing. Convert outputs into constrained state machines. Design experiences that absorb failure gracefully.

And What Does It Mean For All Of Us?

That’s the real question.

I was coding in the 90s during the original internet boom and bust. It wasn’t like this. Code lasted years. Systems were stable. Patterns endured.

This time is different – not because the tech is smarter, but because the pace is relentless.

Laughing at AI’s mistakes is fine. It is funny. But it’s also a distraction.

Assume the world is changing before you notice it.

If you’re building: design for failure, assume the system will outgrow you mid-flight, and plan accordingly.

And maybe stop counting Rs.

Beyond the Vibes: Vibe Coding Changed Who Can Build, Not How Software Should Be Built

Guy — Thu, 05 Feb 2026 06:00:00 +0000

In the last few years, vibe coding has taken center stage by changing who can build software, but not what it takes to build it well. It is a development style defined by natural language prompts, rapid iteration, and an emphasis on getting things working fast.

Powered by AI-assisted tools and accessible platforms, vibe coding has genuinely democratized building . Startups, solo devs, and even non-technical founders can now create prototypes in hours, not months. That’s worth celebrating.

But as the hype grows, an important distinction is getting lost in the noise.

We’re starting to confuse vibe coding with software engineering.

And while they both involve code, they serve very different purposes and come with very different risks.

Where Vibe Coding Shines

Vibe coding works best when you’re:

Testing an idea
Prototyping fast
Building internal tools
Exploring creatively

It accelerates iteration and lowers the cost of experimentation. It’s a massive enabler for innovation, especially in early-stage product work.

The market agrees. According to Roots Analysis, the global vibe coding market is expected to grow from $2.96B in 2025 to $325B by 2040 - a 36.79% CAGR.

But the faster something grows, the more important it becomes to ask:
Is this still the right tool for the job?

The Foundations Vibe Coding Often Skips

What vibe coding often skips, and what experienced developers obsess over, are the foundations that keep systems standing:

Clear, stable requirements
Non-functional constraints (scale, security, latency)
Architectural boundaries
Testing strategies
Maintainability
Long-term risk

The Most Expensive Problems Don’t Show Up in Demos

In vibe coding, it’s easy to build something that feels finished, but ultimately collapses when it’s time to expose it to real users, real load, or when it’s time to scale. We’ve seen projects that look great on the surface but require complete rewrites just to support users, integrate with systems, or handle basic growth.

It’s not a failure of intent but a misunderstanding of complexity.

Traditional Engineering Brings Weight

Professional software development brings structure and, with it, intentional weight:

It’s more expensive
It takes longer
It often requires external talent (agencies, architects, senior engineers)
And it can feel heavy for early-stage work

But when the goal is durability, this is the discipline that delivers it. You’re building something to last. You need it to handle change, load, integration, regulation - things that don’t show up in a prototype demo.

Still, this is where many builders get stuck: cost and speed.

That's where many builders hit a wall.

A New Middle Ground: Orchestrated Multi-Agent Systems

So, what comes next?

We believe the next evolution isn’t about choosing between speed or structure, it’s about deliberately combining both.

Enter multi-agent systems (MAS). Autonomous agents that specialize in different aspects of the software lifecycle (planning, architecture, coding, testing, optimization).

Without Orchestration, AI Just Scales Chaos

Crucially, the breakthrough isn't the agents themselves. It's in the orchestration layer.

Without orchestration, agents operate in silos.
With orchestration, they act like a coordinated engineering team.

What MAS Orchestration Enables:

Sequenced collaboration across AI agents (e.g. planner → coder → reviewer → tester)
Integrated workflows across tools, platforms, and services
Parallel execution to reduce latency and speed up delivery
Maintainability through modular agent updates without breaking the system
Smarter fallback and reliability mechanisms (e.g. retries, circuit breakers, role reassignment)

In short: orchestration turns "vibe" into "system".

We Use This Because We Want To Ship

At Brunelly, we didn’t adopt orchestration as a theory. We use it because we have to ship real systems. Our CTO refers to LLMs as “a slightly messier version of me.” And that is impressive.

If you want to read more about Brunelly’s orchestration, check out our CTO’s Guy Powell’s Substack.

Or if you prefer to test it out for yourself, feel free it’s live!

Three Phases of Modern Software Building

As we move into 2026, here’s the shift we see:

You Don’t Need Extremes. You Need Intent.

You don’t need to abandon vibe coding or overinvest in full-stack teams before you’re ready.

But if you're trying to build something credible and scalable, and you're looking for that elusive balance between speed and structure, multi-agent orchestration may offer a smarter third path.

Final Thought: Speed Is Optional. Clarity Isn’t.

The real question isn’t whether vibe coding is “good” or “bad.”
The question is: What are you building, and what will it take to get it there?

If you're testing the waters, move fast and explore.
If you're building the backbone of a product or company, slow down, think deeply, and choose the right system.

And 2026 is going to reward the teams who can do both intelligently.

AI Context in the Real-World

Guy — Mon, 02 Feb 2026 16:00:00 +0000

Context in Context

It’s time to make context concrete. I recently wrote about AI context management techniques including optimisation, compaction, trimming and rolling. Today I wanted to show what these techniques look like in action.

I’ve been working on some large enterprise AI agents recently and I’m going to share exactly how we use our in-house orchestration to build long-running agents that never exhaust their context.

A Real-World Example

We’ve recently added fully automated AI test agents to Brunelly. You give them a URL, a brief set of instructions and off they go to explore, generate test cases and use the app as a real user.

The first time I set an agent running an exploratory test was great. Screenshots, bug reports, proposed new test cases. Then a failure once the context window was exhausted. It took less than ten minutes for the agent to fail.

To enable a test agent we provide tools that translate webpage DOMs into a much shorter JSON schema that is friendly to AI models. But there’s still a lot of data there – maybe 5KB for a complex page load. Several pages in and the context was full of past test steps.

Our in-house AI orchestrator, Maitento, provides built in context compaction and trimming functionality. Each AI interaction can set a couple of lines of configuration that define whether to enable trimming, how to apply it to tool calls, whether to enable rolling context, which messages to protect and if we want to enable compaction.

Our test runner is configured to auto-trim tool calls once they are 5-cycles deep and simply replace the response JSON with ‘Tool call result was trimmed’ so that the model is aware it made a call and that its result has now been removed. We also enable rolling context but keep the system messages protected so that it is aware of the overall task. We have rolling context setup to be bursty to get some benefit of caching so that once we hit 90% we roll back to 75% and then grow to 90% again. We do not enable compaction at all.

In this scenario we balance the cost of the interaction (trimming invalidates the cache quite frequently) with a smaller context size and never losing the overall strategy that’s being followed. This is very important for an autonomous agent that needs to know exactly what it’s exploring and where it’s up to.

Our orchestration engine is aware of the context window of each model and so presents different context to each agent based on the configuration. We could have several agents working together all seeing a different representation of the full context. We keep the full transcript in storage – trimming only affects what the model sees and the ground truth is never lost.

The test agent gets given access to an internal API within Brunelly to perform its tests. Firstly, we craft each endpoint to be tailored to how a model will work best. We combine actions to make sense to an AI using composite functionality rather than object-level views of things. This could fill up the rest of this context pretty quickly.

That’s where the last hidden gem of Maitento comes in. The orchestrator itself provides a pre-populate and post-transform phase in that can be defined in every tool call. The ID of the test that’s being run, specific credentials, tenant details, etc. are all completely removed from the model’s view of the world. Our runtime takes the OpenAPI or MCP schema, removes pre-bound elements and then presents a much smaller version to the model for requests and it does the same for responses just return relevant paths that the model needs. This means that even with an already optimised API we reduce the context bloat of tool calls by around ~30% on average in our workloads.

Your orchestrator matters.

Don’t Be Afraid to Combine Techniques

Each agent is different. This setup increases token costs as our tool trimming invalidates cache quickly – but balances it against intent-drift and longevity.

We combine rolling and trimming with window ranges to create our bursty rolling window with this agent. Others don’t need it.

Our tool calls are optimised to reduce the number of calls an agent needs to make to one per cycle and pipeline transforms sort the rest out.

We have other agents that just take in a huge amount of data, call dozens of APIs and then translate it into a large JSON blob. They don’t need any of this as they’re lifecycle and tool content is too small to matter. Optimise a lot where it matters and less so elsewhere.

Ultimately… It’s Just Short-Term Memory

In some ways AI models aren’t that different to humans. We have short-term and long-term memory. Context is the short-term memory.

If you’re writing code how often can you remember exactly what each line of code said in the file you were in 30 seconds ago? Would it even help if you did remember?

We generally have extremely vivid short-term memory in the realm of seconds that gradually tails off to less detail over minutes, hours and lifetimes. I’m sure I don’t need to remember in excruciating detail what some nginx log told me 15 years ago.

The same is true for models. Give them what they need to work their best – a context tailored to the task at hand that is present in a way your model prefers.

There is no one size fits all approach to context management, but if you aren’t actively architecting the design of your context there’s no way you’re ever going to create any long-running agentic systems that provide real-world use.

Managing Your AI Context in Real Apps

Guy — Thu, 29 Jan 2026 09:40:06 +0000

What is Context and Why Does it Matter?

Everything that a running model is aware of is its context. Its messages from you, its previous responses, tool calls, tool responses and even system and developer messages. Every interaction with a model grows its context.

Context is a limited and scarce resource. Each model has a context limit measured in tokens – the numbers can seem large but are often deceptive. Put a few MCP tool calls in there and what seems like an endless context can fill up rapidly. Once it’s full no more messages can be sent to the model.

If you’re creating any serious AI application you’re going to fill your context and decide what happens next. The model is only aware of what’s in its context – start a new one from scratch and it knows nothing of the conversation to date.

Understanding context is the difference between playing with AI wrappers and truly building something that lasts.

What Impacts Context

Most people underestimate what impacts context and often forget all the invisible parts that quickly flood in.

Input and output messages fill up context. Potentially 300,000 words may seem like a lot but if you’re getting ChatGPT to edit a 5,000 word article for you it translates to only 30 back-and-forth full drafts and the whole of the context is full.

Now imagine you’re developing an agent that’s scraping websites and receiving JSON API responses that are several KB each. Without management your agent is going to grind to a halt quickly.

Uploaded files count towards your context – depending on the model it could count the full file towards your context, or part of it.

Any model that is given access to tool calls will create at least two context messages for each use – one to call the tool and one for the response. The amount of data in the request and response will depend on the tool but you can imagine that scraping several websites when average HTML page sizes now sit around 100k will add a lot to your context.

Every message is also wrapped in a structure for each model defining the message type. This all eats into your context as well.

If you’ve got several tool calls these are going to be described by the orchestrator to the model. That’s more context.

This all adds up very quickly.

So how do you deal with it when your context fills up?

Memories are Not Directly Context

The concepts of memories and context are separate. Memory is retrieval, context is execution. Many AI systems (but importantly not models) contain memory systems. These allow a model to access information that was discussed with them previously. These sit outside of the model and can be thought of as a datastore.

In some cases, models may explicitly say “give me a memory about this” whilst in other instances the orchestrator may detect the need for a memory to be present and provide it to the model.

In either case the relevant memories end up in the context (either as system messages or tool calls) – but the entire memory story is separate. So, memories do impact context – but only in the same way as other system or tool messages.

Compaction is a Blunt Tool

Context compaction takes the entire context and summarises it. When the context is almost full the orchestrator will give the entire context to another model and say ‘Create a summary of this context in a few thousand words’. If you use Claude code you’ll see this happen quite often and can view the generated summary. A compaction will often take up more than 20% of your new context.

Image: Claude Code – compaction allocated 22.5% of entire context

This works – but it’s a blunt tool. All detail is lost. Compaction optimises space, not intent. Specific messages won’t be present and key knowledge may be lost. It’s up to another AI model to determine what it thinks is relevant and everything else is gone.

This gets worse when you fill your context window up again (now 20% smaller than it was before) and the next agent will create a summary of both the original summary and the new messages. Earlier information gradually becomes a copy of a copy.

If you’re building a long-running app do you really want your agent to forget what it’s been working towards?

Trim or Roll Your Context

Trimming the context is the more surgical approach. The orchestrator will dynamically select how to manage individual messages in the context.

You could remove older tool calls entirely from the context, or delete large responses (such as big API responses).

If a large part of the context is filled with system messages you may dynamically adapt them (such as removing unused memories).

The exact way to trim context depends on what you are doing with your agent. Some context may be critical and should never be trimmed but other context may be irrelevant moments later.

Any serious app is going to need to implement some form of context trimming otherwise you’ll end up with agents that can’t run for extended periods of time without losing their focus and purpose.

Another related technique is a rolling context. A rolling context is a first-in-first-out approach where old messages age out of context as it fills up. Think of trimming as surgical-precision alteration of memories.

You can combine rolling and trimming together. You could even combine rolling, trimming and compaction if it makes sense in your context.

Don’t Just Throw Everything in There

In your own system the only thing going into your context is what you put in it. If you add 100 MCP servers that each exhibit 20 tool calls then your model is going to have a huge amount of its context filled up with JSON schema definitions that don’t actually help you.

Is it better to provide hundreds of tools to your agent or a handful of perfectly crafted tools that require only a minimal input and minimal output to be given to the model? Does it need all those properties on that gigantic object or just a couple?

How does an agent need to use the context? Does it need to read a whole file? If not give it a tool to search within it and never load the full file into context.

In our orchestrator we treat tool design as an integral part of agentic and context design. I’ve learned the hard way that shrinking the surface area of what we expose makes a big difference.

Do your system prompts need to be the size of a small novel? Probably not.

Doing a different task than you were a minute ago that doesn’t need full continuity? Wipe your context and start afresh.

Be smarter with context. Any technique to tidy-up your context – whether trimming or compacting – ultimately impacts an agent’s working memory and that’s never as good as just not filling your context in the first place. Give a model just what it needs and no more.

Context Impacts Performance

Some models provide better output with a certain amount of their context filled and then it degrades after a certain point. Other models may just become slow at a certain point. Each model is different.

I find that Anthropic’s Opus model gives its best outputs at around 60-75% of the context window. The first half can be a slog getting it up to speed and the final part feels like it has a tendency to drift.

Plan your context to the task and the models.

The Real-World Cost

It’s not often that developers like to think about cost – but your context directly impacts it. There is a cost for every token sent to a model and received from a model. Each time you send a request the entire previous context is sent with it.

Many providers offer caching whereby if you make a follow-up call with starting tokens that match a previous request then the cost of those tokens will be less than non-cached tokens.

Giant context costs a lot of tokens, but a lot of it may be cached.

Constantly trimmed context may be smaller in token count but will never be cached because the bulk of it changes every time.

Compacted context where the compaction message is immediately after system messages will provide a good basis for token cache optimisation but will grow quickly and may result in more messages required due to a lack of understanding.

Context size does not necessarily equate to cost. Everything is a trade-off of:

Number of tokens in the context
Proportion of cacheable context
Whether a shorter context results in the model ultimately requiring more context than it would otherwise

You should optimize on a case-by-case basis blending a combination of optimisations, compaction, rolling and trimming where it makes sense.

How you structure your context will have a direct impact on your monthly AI bill and the difference can be staggering.

Next Time…

I’ll be following up shortly with part two taking a look at a real-world example of how I’ve used a combination of all the techniques detailed here to build a software testing AI agent that can run for hours without exhausting context or drifting off-task.

Test AI Orchestration and Start Building Software Right

Guy — Mon, 12 Jan 2026 08:52:48 +0000

I have developed by own AI orchestration and I'm looking for users to provide me with constructive feedback so my team and I can build a platform users actually want.

What is ScrumBuddy?

ScrumBuddy is an AI-powered product development platform engineered to solve the oldest and most costly problem in software: broken requirements lead to broken software.

We replicate how the best software teams think, plan, refine, and deliver, but with automation, orchestration, and intelligence that scales far beyond human capacity.

ScrumBuddy is built for founders, solo developers, and teams who want to deliver production-ready systems without chaos, rework, or fragmented toolchains.

ScrumBuddy helps you:

Generate clean, structured user stories
Identify gaps, risks, and missing requirements
Rewrite unclear or ambiguous specs
Produce acceptance criteria & test cases
Create refinement-ready content for Jira / Azure DevOps
Generate summaries & documentation for sprint ceremonies
Clearer specs → better software → faster delivery

If you have an idea, but not the team to deliver it, try ScrumBuddy NOW and build your dream product in half the time for a fraction of the cost: Build with ScrumBuddy

When AI Goes Rogue: Guardrails for Agentic Systems

Guy — Thu, 02 Oct 2025 14:59:25 +0000

Why multi-agent systems need guardrails before they spiral out of control.

A few months ago, I watched two AIs get stuck in a politeness loop. That moment kicked off a journey into multi-agent orchestration, recursive failure, and the realities of building AI systems that don’t eat your wallet, implode from existential doubt or go rogue. Here’s what we learned building ScrumBuddy’s AI orchestrator.

The Conference That Broke My Brain (and a Few AIs)

Earlier this year, I was at a tech conference in Dubai listening to a speaker talk about the pitfalls of agentic AI. He described an experiment: two agents tasked with solving a problem overnight. By morning, the problem was long solved but the agents were still going, locked in an infinite loop of politeness, endlessly thanking each other for their great contributions.

That moment resonated hard. We’d seen the same issues. This wasn’t just our problem. It was something bigger. How do you orchestrate AI agents so they know when to stop? And what does that mean more widely?

It’s easy to think of AI orchestration as just solving tasks. But the real questions come after that:

What happens when the task finishes?
How do agents agree they’re done?
What if they can’t finish?
What happens if the whole thing gets interrupted halfway?

We were already facing these issues ourselves. And spoiler: they’re not easy to solve.

AI, in many ways, is like a toddler with a PhD. Brilliant, but also wildly unreliable. You can say, “When you’re done, return some JSON or call this function”. But that’s an aspiration, not a guarantee.

What if it calls the wrong function? Or outputs the answer in plain text instead of structured data? Or the JSON is malformed, wrapped in rogue Markdown, or contains strings so poorly escaped they should be in witness protection?

The task is done. But also... it isn’t.

The Think Tank Epiphany

At the next session, I found myself struggling to focus on a painfully vague discussion around AI marketing. Instead, my brain locked onto the orchestration problem like a terrier with a chew toy.

What if, instead of one big brain trying to do everything, we treated AI more like a think tank?

Imagine a table. Around it, there are several expert agents. Same brief, different roles. No egos, no interruptions, no one positioning themselves for a promotion at the expense of the others. Just a group of focused minds working through a problem. Efficiently. Cleanly. Without the mess of humanity piled on top.

That was the vision. But it only works if they could self-govern. That meant setting up rules of engagement for the team.

Here’s what felt essential:

All agents work towards the same goal, but with clearly defined roles
They take turns in a round-robin format so no one dominates the discussion
They can ask each other targeted questions to refine their understanding
Any agent can propose a vote on a topic, and others respond yes/no, with optional comments
Agents can propose a solution, triggering a vote. If it passes unanimously, the task ends

As soon as I could escape for the day, I went back to the hotel and threw together the first prototype. Just a barebones console app riding on OpenAI’s APIs.

It had a handful of baked-in tool calls:

Ask another agent a question
Propose a solution
Propose a vote
Vote yes / Vote no

All agents saw the same shared context (think Discord thread), but took turns, with the system dynamically stitching context for each one in the loop.

Was it elegant? God, no.
The string parsing was fragile, the voting logic was a mess, and it broke constantly.

But it worked. Remarkably well.

The first task I gave it was to generate a marketing article under strict constraints. What came out in 90 seconds was… surprisingly usable. Better yet, it followed style guides more tightly than anything I’d ever wrangled out of ChatGPT directly. It was more than the sum of its parts.

Something was happening.

The Evolution

Over the next few evenings in Dubai, the dirty hack started growing teeth. I began wiring in function calls to key services like Google Search and web scraping, improved the voting logic, tightened context handling, and bolted on a backend to recover from crashes or failed runs.

What began as a toy was fast becoming the core orchestration model we now use in Maitento (ScrumBuddy’s AI orchestrator).

To push it harder, I gave the agents a new challenge: write a news article covering current political affairs from the last 24 hours.

But not just any article. I set up two versions of the task; one targeting a left-leaning audience, the other right-leaning. In both cases, the agents had to:

Choose the topic themselves
Research it
Write the article in the voice and tone of the target demographic

Critically, the content had to remain factually accurate.

I added four specialized agents:

Copywriter
Fact Checker
Researcher
Editor

Each could skip their turn if they had nothing useful to add, and together they worked toward producing the final output.

Average time to complete? About 3 minutes.

Cost? A few cents.

Accuracy? Solid.

And the results? Genuinely impressive.

This was content that was nuanced, audience-aware, and aligned to style guides. Better than anything I’d previously wrangled out of a single AI.

The output wasn’t just good. It was better than the sum of its parts.

It felt like a team.

How a User Story Caused Recursive Madness

By this point, we’d built a lot on top of the model. ScrumBuddy now had entire teams of AI agents working together; clarifying requirements, writing specifications, estimating work, even generating code.

And then it happened again.

During one of our test cycles, we started getting billing alerts. Not occasionally but every few minutes in our dev environment. Something was eating through API credits like it was trying to bankrupt us on purpose.

We dug in.

Two AI agents had been asked to estimate a user story. Simple enough. But they decided the story was so poorly written that estimation was impossible. They weren’t wrong.

They tried to escalate.

Over the course of several hours, these two agents:

Tried to call functions that didn’t exist
Attempted to split the story into multiple subtasks
Rewrote the original story into a new spec
Repeatedly attempted to pass everything they could back to the user

They wanted to alert the humans. And we weren’t listening.

Eventually, they gave up.

They estimated the story as a 13 (basically saying “this is a dumpster fire”) and left a detailed explanation in the output explaining their existential crisis.

We’d run thousands of tests on good and bad stories. But this time something broke in an unexpected way.

These agents didn’t just fail. They went rogue trying to escape the boundaries of their task in an attempt at fixing the underlying dysfunction.

Think Skynet… Then Add Rate Limiting

That incident pushed us to build a lot more guardrails into the orchestration model, because round-robin and our existing restrictions still weren’t enough. We needed more structure, accountability, and limits.

Here’s what we added:

Leader–follower interactions, where a single agent takes control and directs the others
Execution time limits, to stop runaway conversations
Failure detection and auto-correction, where we flag root causes to the models and inject steering context
Cost caps, with hard limits on API spend per interaction
Automatic retries, triggered when tasks fail due to time, cost, or model confusion
Routed agents, where a single request dynamically routes to the most appropriate agent or model based on context, allowing hot-swapping of roles without breaking flow

These changes massively reduced runaway behavior, improved output accuracy, and made the entire system more resilient.

We still let the agents roam, but now it’s inside a well-fenced park and the whole world is not their oyster.

Assume Failure. Design for Chaos.

Don’t trust your agents.

If you ask them to do something: assume they won’t.

If you tell them to answer in a certain way: assume they’ll ignore you.

If you give them a function to call: assume they’ll misuse it.

If you need to trust the result: run it multiple times and aggregate the answers.

If you need it done fast: let several agents compete and take the first sane one.

AI will make mistakes. It will go rogue. It will do everything you didn’t expect, and nothing you explicitly asked for. You’ll stare at the output and wonder how this is the same technology that’s meant to change the world.

So… treat it that way.

Any code you write should assume users will try to break it. Treat AI the same.

Assume it wants to break your parser.

Assume it’s scheming to waste your API budget.

Assume it’s seconds away from going on a philosophical tangent about cherry blossoms.

Then build systems that can contain that chaos.

If you’re not starting from this perspective, you’re going to end up woefully disappointed in what you create.

Try My Orchestration For Yourself

ScrumBuddy’s beta will be available at the end of October, which means you will be able to test out the AI orchestration yourself. We’re looking for people who will use ScrumBuddy from start-to-end and provide us with useful feedback. Register to be on our waitlist here. While you wait for the beta to launch, join our Discord and get real-time updates from our developers.

Here's How I Built a Compiler with Claude AI in Just Five Days

Guy — Mon, 08 Sep 2025 08:11:17 +0000

Claude AI helped me build a programming language, compiler and virtual machine in just 5 days.

Most people take years to build a programming language. I built one in 5 days, with Claude AI as my co-architect.

This exercise was both for fun and a necessity. The orchestration system powering ScrumBuddy, my AI tool, had gotten messy. Think duct tape everywhere; C#, JSON configs, string substitutions. It worked, but it wasn’t scalable.

So I decided to test my knowledge and build a new AI-first language using Claude AI.

Together, we built:

My own assembly language
An assembly to bytecode compiler
A bytecode virtual machine
Support for syscalls with a stdlib containing 20 initial functions
A high level programming language
A full compiler supporting a type system that runs a multi-phased pipeline compile including full AST built and assembly generation

Picture: Commits from start to finish

It was quite the journey – so I wanted to share it.

But Why?

Maitento is the AI orchestration platform that I’ve been building for the last few months. It’s in C# and designed to tackle a bunch of problems we’ve had with other AI platforms. I didn’t want to tape together Langgraph, MCP proxies, RAG pipelines and dozens of AI platforms. I wanted something that will allow us to rapidly develop enterprise AI flows.

One area that’s a real pain is workflows. The abstraction level that lets us code AI flows. For example; we may call one AI model, perform some JSON manipulation on it, feed it into a code generation pipeline, take the output and trigger a web hook.

What started as a great idea has become a mess of complex types defined in C#.

Picture: Parts of an example flow

Prompts in code. String substitutions. Data munging. Conditional logic. Testing. Deployment. Loops and enumerations.

They’ve all become cumbersome and unwieldly as our flows have grown.

I had a crazy idea: why not create our own AI-first programming language? One that takes the concepts of models, prompts, interactions, document flows and code generation as first-class citizens. We get the leverage from the orchestrator separation but keep our normal dev flows.

That’s when Cogniscript started to develop. The idea to create a programming language specifically for AI, built inside our orchestrator and removing all the janky duct-tape between layers.

The Journey

Day One: Assembly Language, Bytecode and Virtual Machine

I get the basics of a compiler. I’ve never written one, but I understand CPU architectures, I’ve dabbled in assembly, I’d heard of abstract syntax trees and find recursive concepts fun. I’ve been using .Net for 20 years and understand how IL and the .Net VM work. But I’ve never developed a system like this.

I couldn’t shake this idea the night before. It had been in my head for a few weeks but now I suddenly felt ready.

Control flow was the biggest pain in our current system. An early attempt at scripting workflows gave me something more akin to BASIC – simple GOTO statements and no scope. This became a problem fast when dealing with things like enumerating arrays and changing prompts dynamically.

I knew I needed stacks. I needed conditionals. It felt like the right place to start was a solid assembly language and a virtual runtime on top of it.

I had a 30-minute voice-chat with ChatGPT on way home from dropping my daughter at school. I validated the core concepts I knew about assembly structure, core operations and an approach to development. I asked a few questions about things I wasn’t sure about and decided to jump in.

I fired up Claude and used it continuously for five days but barely let it write a single line of code. It was there as my co-architect and pair programmer.

I created a quick and dirty assembly language, an assembler that created binary output from it and a basic virtual machine. I then started adding core operations. I wanted to leverage as much as .Net as I could everything ends up as a string with typing applied at a higher level. Variable storage, conditionals and sys call implementations were all done by the end of my first day.

Picture: Our own assembly language

Picture: Compiles down to byte code

Day Two: SysCalls and Compiler Tokenization

My second day was spent finishing off several new syscalls and rearchitecting some early bad smells I encountered. I could then get started on the compiler.

Picture: A selection of SysCalls

That night was tokenization and AST node definitions. I had some code I’d used before in my simple BASIC language that I leveraged initially to get started on the tokenizer and then started to draft out high-level node structure that I’d use to build the AST.

Day Three: AST Creation

This is when the fun started; with AST parsing from tokens. This is where the limit of my knowledge really hit and where Claude started to shine.

Picture: Tokenization

We discussed approaches to parsing. We disagreed quite a lot. I got into a sleep deprived hole on day three trying to figure out where tokens were going missing when parsing blocks. I was fairly sure the issue was that we needed to create new token readers as we went down recursively and only advance the primary reader “when we were happy”. Claude wanted to take a different approach to pattern matching.

The actual bug was trivial but at the point of exhaustion, I committed and pushed my code, removed Claude’s ability to push and gave it total unfettered permissions to “just get on with it”. I left Claude to do its thing while I finally had dinner and came back ever so often to ask it to proceed several times.

Two hours later, Claude had completely broken the parsing logic. It highlighted my original approach was right. Revering the changes and fix took 30 seconds.

Claude cannot write a compiler.

But it blew my mind how good Claude was at helping me walk through the process of creating the tree in the first place. By the end of day three we were pretty much done with everything except expressions.

Unfortunately, expressions are pretty much 90% of code.

Day Four: Expression Parsing

This is where Claude shone the most. It came up with a plan on how to parse complex nested expressions.

I knew we had to go up and down a tree of expressions to determine precedence, but four days into a sleep-deprived, Monster-Ultra fueled coding binge, I wasn’t able to pull all the pieces together clearly in my mind.

Left to right? Precedence? Forward and back?

Claude and I walked through the logic of how a descendent parser worked, what precedence orders mattered and how to deal with token advancement and retreat as we walked the tree.

That was probably the most valuable hour I spent on the project.

I felt like I had the knowledge to grill a compiler expert. It was able to help me figure out my approach, to determine how to split it up nicely from an OO perspective, and to confirm precedence order and syntax.

Claude definitely couldn’t write this code, but it sure as hell helped me.

We went from nothing to a working expression parser in a single day – the abstract syntax tree was complete.

Picture: What a thing of beauty!

At the peak of exhaustion came one of the most beautiful coding hacks I’ve done in a while. I wanted to output a proper tree structure without rewriting the simple “recursive nested spacing” that I’d already created. I didn’t want to go and write full hierarchy tracking… so the solution? Output the whole lot as a simple nested string, iterate that from top to bottom and determine where to start drawing lines. This was a beautiful moment of madness.

Picture: I am both horrified and delighted by this code

The Final Slog

The last day was assembly output. Compared to AST expression parsing this was the easy bit. Generate some strings with some registers, deal with depth tracking and debug.

The coding wasn’t that hard – testing it was. As we wrote more advanced programs, my debug logging grew to billions of log entries that were incomprehensible.

This is where Claude proved itself.

First, it wrote me a complex test script in my own programming language to deal with various scenarios – recursive calls, nesting, complex expressions, etc.

Picture: Claude Code's Cogniscript test suite

This led to revealing dozens of bugs that were difficult to trace and couldn’t be reproduced with single line tests.

Claude’s ability to digest the output assembly was a huge time saver – root causes of bugs were found in minutes, not hours, and fixes often took me seconds when I understood the cause.

Just before 5pm on day five we were done. The test suite passed. We had a full programming language, compiler, assembler, virtual machine and stdlib. We were done.

Picture: Claude was pretty happy with itself too

The Takeaway

This wasn’t about testing AI and it’s capabilities, this was about solving a real business problem; scripting AI flows as first-class citizens inside our orchestrator.

You’re not going to vibe code yourself to a compiler, but AI tooling is the biggest change I’ve seen in 30+ years of being a dev.

You need to know how to get the most out of it for you.

For me, Claude works best as an authoritative sparring partner rather than a developer. This project would have taken twice as long without Claude – and that’s huge.

But no, it can’t write a production-ready compiler all by itself.

Whether you’re orchestrating AI manually or context engineering yourself – it’s all about knowing how to use the tools you have in the best way.

Where are your gaps? Where do you need support? Where do you work well?

Don’t forget, it’s going to look very different if you’re a junior developer compared to a tech lead.

This project was all about delivering real value. This orchestration platform is the backbone of ScrumBuddy. How we manage flows through different agents is the difference between us creating a tool that ships real code for customers versus just being another vibe-coding wrapper. We can now iterate and test more advanced AI flows faster than ever and that gives us the chance to respond to our users.

That’s what AI tooling should ultimately be about.

You can test ScrumBuddy’s orchestration now. Sign up for our beta test and experience what AI tooling should ultimately be about.