Can Agentic Engineering Really Deliver Enterprise-Grade Code? | Reuven Cohen
Advanced AI agent engineering leverages recursive feedback loops, multi-agent swarms, and spec-driven development with deterministic languages to build complex enterprise software rapidly and reliably.
Highlights
7 clips · 9 min of 62 min-
- Early prompt engineering relied on rigid chains of thought.
- Feeding errors, logs, and execution context back into the AI creates a recursive loop.
- This feedback loop allows agents to understand context and autonomously resolve code errors.
-
- Early long-horizon agent swarms cost thousands of dollars per hour to run.
- Anthropic's unlimited token models enabled a massive shift in economic viability.
- Costs dropped from prohibitive hourly rates to flat monthly fees, enabling accessible swarms.
-
- Detroit school TDD writes tests alongside code, which poorly suits autonomous agents.
- London School TDD uses scaffolding to outline all parts before building the application.
- AI agents can rapidly and repeatedly build against this scaffolding without friction, compressing weeks of work into an afternoon.
-
- Permissive languages like Python and Node allow flawed code to execute anyway.
- Rust provides explicit, deterministic definitions that prevent building incorrect code.
- Pairing a rigid specification protocol with Rust enables reliable delivery of complex projects.
- Permissive languages like JavaScript allow flawed code to execute silently.
- Deterministic languages like Rust reject incorrectly built code automatically.
- Rigid specifications paired with strict languages ensure reliable enterprise output.
-
- Markdown files lose context over time, requiring a shared SQLite memory layer for agents.
- Hive-mind architectures suit broad early development and massive code generation.
- Swarm architectures act like targeted tools for refining specific functional details.
-
- Sequential agent execution severely limits development speed.
- Leveraging undocumented batch tools enables hundreds of sub-agents to run concurrently.
- Parallel execution yields linear time reduction, completing hours of work in minutes.
-
- Monolithic models can be replaced by narrowly focused, interconnected micro neural networks.
- Sub-thousand parameter models can run efficiently without requiring GPUs.
- Rust libraries enable rapid generation of task-specific neural networks for application logic.
That’s all the highlights.
Questions this video answers
7 · every answer cites the moment it was said01 Why do the vast majority of agentic AI projects fail? 2 sources · 0:00
Most agentic projects fail not because the technology is fundamentally flawed, but because developers and project managers lack the proper knowledge to build actual agentic systems. Additionally, large companies often engage in AI washing, rebranding simple chatbots or vibe-coding setups as autonomous agents.
02 What economic breakthrough enabled scalable agent swarms? 3 sources · 8:38
Early long-horizon agent swarms were prohibitively expensive, running into thousands of dollars an hour, which made them economically unviable compared to human labor. The major breakthrough occurred when Anthropic introduced flat-fee, all-you-can-eat token pricing with Claude Code, allowing developers to run swarms for an entire month for about twenty dollars.
03 How does specification-driven development structure agentic workflows? 3 sources · 22:17
The Spark protocol addresses early specification limits by breaking development down into structured stages like pseudo-code outlining and architectural scaffolding. This structure enables a refinement phase where multiple autonomous agents work concurrently using a London School test-driven development approach. By defining tests and specifications upfront, developers can guide AI agents to build complex applications reliably.
04 Why are deterministic programming languages recommended for agentic engineering? 2 sources · 25:27
Permissive languages like Python, Node, and JavaScript allow developers to build code with hidden flaws that still manage to run. In contrast, deterministic languages like Rust are extremely explicit and rigorous in their definitions. Combining a rigid specification with a less permissive programming language ensures that agents build complex projects reliably and correctly.
05 How does a hive mind approach differ from a swarm in multi-agent systems? 2 sources · 34:26
A hive mind provides a shared consciousness where all agents share the exact context of what is happening, making it ideal for broad early development. A swarm uses independently operating agents with shared SQLite memory to tackle narrow, targeted problems like a sculptor detailing a face. Using both allows you to adapt tactics based on the development stage.
06 What is the purpose of using the undocumented batch tool in Claude code? 2 sources · 39:08
The batch tool enables massive concurrency by allowing developers to spawn dozens of sub-agents running in parallel instead of sequentially. This drastically cuts down project completion time from hours to minutes. However, performance gains typically max out around 10 to 20 agents for standard development tasks.
07 What remains the biggest challenge in agentic workflows today? 2 sources · 58:48
Validation is still considered the primary challenge when working with agentic flows and LLMs. Developers must constantly verify whether the generated code is true, real, and actually fulfills the requirements. Trusting automated test success without heavy verification can lead to insecure or incorrect code.
Section-by-section summary
13 parts
Agentic engineering requires proper knowledge and execution
Most agentic projects fail because developers lack the specialized knowledge required to build autonomous systems. Reuven Cohen and the Agentics Foundation established repeatable architectures to counter superficial chatbot implementations.
Recursive feedback loops power modern autonomous agents
Early agents were rigid and procedural, failing outside deterministic paths. The major breakthrough came with recursive loops that feed errors and execution context back into the LLM for self-correction.
Flat-fee token pricing unlocked scalable agent swarms
Running long-horizon agents previously cost thousands of dollars per hour, making them economically unviable. The introduction of flat-fee models by Anthropic reduced costs dramatically, enabling concurrent agent swarms.
The Agentics Foundation acts as a professional guild
Formed in early 2025, the Agentics Foundation serves as a meritocratic community and professional guild for agentic engineers. It pushes back against corporate AI washing and protects practitioners in the emerging AI-native landscape.
Traditional workflows cause agentic project failures
A high percentage of agentic projects fail because organizations apply slow, human-centric development sprints instead of embracing speed and momentum. Developers must learn to leverage AI as a superpower rather than replicating legacy processes.
Specification-driven development enables complex agent architectures
The Spark protocol addresses early specification limits by enforcing a structured approach using pseudo-code outlines, architecture definitions, and London School TDD. Combining rigid specifications with deterministic languages like Rust ensures complex applications work reliably.
Embedding validation test cases at project inception
Defining requirements and validation tests right at the start prevents automated systems from producing convincing forgeries. Integrating tests into the specification flow mitigates fake or fraudulent results.
Treating agentic development as multi-threaded narrow tasks
Replacing human developer personas with agents fails because agents do not operate like people. Instead, treat development as a multi-threaded process where each agent solves a narrow, prescriptive problem.
Using SQLite memory and switching between hive minds and swarms
Markdown documentation loses context, making a simple SQLite storage environment ideal for shared agent memory. Developers should use hive minds for broad early-stage generation and swarms for targeted refinement.
Unlocking massive concurrency with batch tools and Rust
Discovering undocumented batch tools enabled moving from sequential execution to running hundreds of parallel sub-agents simultaneously. Additionally, porting complex libraries to Rust created portable, lightweight WebAssembly modules.
Demonstrating Claude-flow CLI and swarm initialization
Claude-flow provides a CLI and MCP server optimized for agent coordination rather than direct human invocation. Developers can use wizards to configure swarm parameters, agent counts, and majority consensus mechanisms.
Prioritizing specifications while guarding against AI laziness
Specifications remain the most critical source of truth in agentic engineering workflows. However, relying heavily on automated generation can lead to cognitive offload and developer complacency.
Overcoming validation challenges in agentic workflows
The biggest remaining hurdle in agentic development is validating whether generated code is genuinely correct, secure, and optimized. Developers must maintain a rigorous verification mindset despite passing test suites.
n next · p previous clip · t highlights/full
< > slower/faster · / search what was said
-
Spark9× · first 0:51
A specification-driven development framework using pseudo-code and scaffolding to guide AI agents.
-
Recursive feedback loop2× · first 4:45
An iterative mechanism where execution errors and logs are fed back into an agent to enable self-correction.
-
Claude Flow8× · first 2:24
An open-source CLI tool combining adaptive neural networks and swarms for agentic engineering.
-
SQLite memory1× · first 33:08
A common storage environment used by agents to save their current state and access previous states in a swarm.
11,623 words · about 46 min to read · YouTube’s automatic captions
Agentic engineering requires proper knowledge and execution
There was an interesting report from MIT a couple weeks ago that basically said 95% of agentic projects fail. But the reason for that failure is likely 99% of engineers, programmers, developers, project managers don't know how to actually build aic system.
The foundation that you created, the agentics foundation, what's the problem it's trying to solve?
Let me be honest. AI gives you sort of delusions of brand. But there was a group of us and we saw a spectrum. We saw on one end we had these vibe coders and what we were doing is creating architectures and process and approaches that were repeatable with a defined outcome and what we saw was the the term agentics and agentic engineering was starting to be co-opted by large companies who are essentially saying it was an agent but it was a chatbot or it was a vibe coding system. So we're the stonemasons or this new emerging field of gentic engineering for AI.
One of the things that came out of the foundation was spark. What was the driving force? We saw that a lot of the early work within these coding systems were limited by the specification itself. But once we started looking at how do we create larger more complex application it be it became important to create a specification that the AI could implement test and verify.
Before we jump into this episode, I wanted to let you know that this podcast is for developers building with AI at the core. So whether that's exploring the latest tools, the workflows, or the best practices, this podcast's for you. Now, we've had amazing guests like Olivier Pomel, the CEO of Data Dog, Matty Stanisowski, the co-founder of 11 Labs, Victor Ripelli, the CEO and co-founder at Synthesia, and of course, Tessle's very own Patrick Dwis. and they're all sharing lessons right from the frontier of our industry. A really quick ask, 90% of people who are listening to this haven't yet subscribed. So, if this content has helped you build smarter, hit that subscribe button and maybe a like. It really does help us keep bringing the folks who are actually pushing this space forward and helping build that AI native future. All right, back to the episode. Hello and welcome to another episode of the AI Native Dev. My name is Simon Maple and I'm going to be the host for today's episode. Uh and joining me today is Ruven Cohen. Uh people may you may know him better as REV and and Ruv
is an Agentic engineer. He's the founder of the Agentics Foundation and also creator of uh Claude Flow, which you may have heard about getting a lot of noise and a lot of adoption just recently. So Reuben, welcome to the show. How are you?
I'm great. Thanks for having me today.
Absolutely pleasure. Whereabouts are you uh calling in from today?
I'm just outside of Toronto, Canada. Nice sunny late summer day here. So
wonderful. Wonderful. Sounds good. Sounds good. Now um Agentic, when we think about roof, we always think it's a gentic foundation, aentic development with all the things that you've done in and around Spark and in around Claude Flow. Um you've been working with Agentic processes for for years now. Tell us what it is. Let's let's start really talking about the state of Agentic before we kind of like move into guardrail spark and claude flow. We'd love to talk about the basics. What is
Recursive feedback loops power modern autonomous agents
agentic coding? What what what's the difference between the core difference between agentic coding and non-aggentic? What what makes the difference?
Well, it's been a bit of an evolution for us in in the space. And to tell you about Agentics, I have to tell you sort of the brief history of Agentics. And for some people, it's a long history. You know, the idea of agents in technology have has been around for almost as long as there's been servers and computers where you'd have systems that essentially ran sort of, you know, at a autonomously. So, the idea of an agent really speaks to the idea of agency. It the ability to operate with little to no human oversight. Now a lot of the early you know agents you would see in applications things like networks and other other com components you know were were very procedural. They would run specifically within a very confined structure a you know 1 + 1 equals two.
But as soon as you went outside of that sort of deterministic sort of perspective it they fell down. They weren't smart. They weren't capable. They just did specifically what they were programmed to do and nothing else. And what we saw really with the emergence of of the GPT models really GPT3 and beyond was the ability to use a kind of language alongside of these systems that were then able to use the tools and the infrastructure and the environment in new and interesting ways.
And the major breakthrough we had probably around two years ago was this idea of a kind of recursive loop. Now, a lot of the early agents and and and prompt engineering were were focused on a kind of chain of of thought, right? Do do these things and execute and based on a kind of language abstraction. But it turned out what really made these
1 Highlight · Recursive feedback loops enable autonomous error resolution
systems work well was this kind of recursion feeding errors and logs and and successes and failures back into the system so the system could understand the context of what was happening. Once we sort of determined that the context of of what was happening was more important almost in what was happening, we could then solve the problems. If there's an error in code, which almost always happens, you would be able to resolve those errors because you the the AI or the the agents themselves could understand what those errors are and resolve them through a kind of uh feedback loop of sorts.
So here we are 2025 the that this space u an agentic engineer didn't even exist probably three years ago. And one of the as we sort of start building a lot of this technology is what we ended up seeing other like-minded sort of individuals kind of coalescing around myself and others. You know we had Reddit groups and WhatsApp and discords and and then we saw large companies adopting the the same uh terminology agentics and agentic engineering. So it's been a kind of wild ride over the last really few years here. the idea of this iterative kind of like process whereby we can we'll try something if it doesn't work we'll feed it back in and kind of like just you know looping this this this nature of trying again multiple times before it provides you with an answer what what do you feel has made potentially 2025 the was 2025 the year of the agent or 2024 I can't remember but but you know when we talk about the year of the agent is it the ability for humans to be able to trust
AI to do these things uh um by itself much much more because when we think about how developers would use uh AI and LLM in their coding it kind of very very much started off with very very much kind of like autocomplete style uh suggestions from an assistant and then we gradually allowed it to do more whether it was cursor or or other tools that that kind of like did much more for us across multiple files and things like that. What what was the thing do you feel that really kind of like allowed us to turn agents on in our code generation? Is it is it context? Is it trust from from humans in the process?
Is it the capabilities of LLMs? I don't think it's trust. I think anyone that's building these systems inherently doesn't trust the output and needs to spend quite a bit of time verifying that what it's actually given us is true and valid and functional and not just a kind of mock or simulated version of what we asked it. So there's a tendency for the system to to you know kind of take the shortest path to give you the the the outcome. So a lot of what an engineer is doing is is is working with solid structures, architectures and other things to to sort of validate what's
Flat-fee token pricing unlocked scalable agent swarms
being built is is just functionally true and correct. Now to your question of what makes 2025 the year of of sort of agentics if if that's if that's even a thing is one of the big breakthroughs last year was again this idea of recursion. So um we a group of us we created these were kind of systems that could operate on a kind of long horizon. These are agents that could run for for hours or days at a at a time and and then eventually complete whatever problem they they were given. Now, the drawback to that, we could run it for third, I think I did a 36-hour test mostly just to show that I could run an agent, you know, for 36 hours, but the costs were prohibitively expensive. And what we saw as we scaled these agents is a lot of the to to effectively run this, you're looking at even on a minimal basis around $4,000 a day. And when we really cranked it up to, you know, dozens of agents running concurrently, we're looking at $7,500 US an hour to run uh at at this at a a 10
agent swarm concurrently basically. And the it's just it's substantially cheaper to hire a person at that per at that point to do that work. It's just even though you could you could do a ton of
2 Highlight · Flat-fee token pricing transformed agent economics
output, most applications didn't require that level of of scale or capacity. So in April of this year, what we saw was uh Anthropic and Claude Code came out and they started offering a sort of unlimited all you could eat buffet for for for tokens and capability. And the first thing we did is we re sort of imagined the previous iterations of the what we called the Spark protocol which allowed for that recursion. And suddenly we were able to to spawn these swarms that could run for hours on end and cost a flat fee. Often 20 starting at $20, you know, for an entire month, which is went from thousands of dollars to $20, you know, thousands of dollars an hour to $20 a month. So we saw this interesting inflection of both capability. So suddenly we we were able to build things dramatically faster and more with a lot more capability at an
exponentially lower cost which is an interesting sort of you don't generally see that happen all at once and that was basically May.
Yeah. And that's super interesting because I think it's that both the making it more affordable but also the parallelization it really opens up uh the the quality of what we can actually get back as well as as a response. I want to talk about that in just a second. Before we move on to to Swarms and and and Spark specifically, um I'd love to talk a little bit about the foundation that you created, the Agentics Foundation. Um first of all, the Agentics Foundation isn't kind of like super new, I guess. Tell us a
The Agentics Foundation acts as a professional guild
little bit about what um you know, what the need was for that foundation. What's what's the problem it's trying to solve?
It's an it's an organic sort of evolution of of the work. And I'm going to tell you a little backstory, which is going to probably make me sound absolutely crazy, but I'm going to say it anyway. So, I was early in into Chat GBT. I was lucky enough to be an early beta tester. Uh, I think they called it a VIP program back in in 2022 with Open AI. And, you know, so I basically means I got it maybe three or four weeks before everybody else. And one of the first things I asked it is is how can I be and this is going to sound really egotistical, but how can I be the most influential person in AI is what I asked ChatGBTV1 pre-launch. And it and it gave me this this sort of step-by-step process that said, you know, first of all, what are you good at? What do you like? And what you know, what where where do you want to be in a few years?
And it it suggested that anything worth doing takes years of sort of prep and and you know, to get to that point. and and it g it set it gave me this outline based on a kind of Q&A that you'd have with chat GBT and most of you have ever used chat GBT and know know the kind of you know asking open-ended question sort of routine and it said basically you're going to have to build a social media following and you should be narrow in that focus and and some I'm asking well what does that actually mean it says well what do you like to do and I like to build autonomous things I I've been building cloud infrastructure for nearly 25 years that sort of thing and it set me down this path path and said, "First of all, you need to create a a subreddit." Now, I know nothing of Reddit or subreddits, but I did it. I followed the guidance and and you know, three and a half years later, I've got 100,000 plus subscribers of the subreddit. I'm not really sure exactly why or what I'm going to do with this subreddit. It's it but it's popular. And then it said I needed to do and and the key was consistency. It said it it told
me that I needed to build a following by constantly posting interesting things that I'm doing and sharing those things publicly on my GitHub, creating weekly um you know live casts where I can interact with people. I followed the guidance and next thing you know I I I have, you know, thousands and thousands of people, you know, showing up for these these live casts, following me and and essentially buying my time on a kind of only only fans for geeks sort of approach where people can sort of essentially buy my my time on an hourly basis. And and and the craziest part of the whole story is it it actually worked. And I now I I'm I'm I'm in a fortunate position where I I can claim, you know, more than a 100 customers, 20 Fortune Fortune 500 clients. I'm literally one guy, one company. Um you know, company one and my my wife actually helps with with some of the non-technical parts, but generally speaking, it's me and my bots. And the entire sort of business plan and process was literally set forth by ChatGpt V1,
which is in itself just amazing to me. Did the LLM tell you to create the foundation or was that something that you've
The foundation was an evolution of those early conversations? No, it did. It didn't exactly say that. And what happened was as the as the community coalesed around the concepts of Agentics and the sort of practical approaches that we were taking to implement the Agentic systems, it became pretty clear that we were in the midst of a new profession. And and when you look historically at different professions and and and maybe and and let me let me be honest, AI gives you sort of you know delusions of grandeur often but the in this particular case there was a group of us and we we're realizing that we are all practicing a sort of similar approach to the sort of engineering of AI and and and when you when we looked at it we saw a spectrum. We saw on one end we had these vibe coders. These vibe coders are not I'm not saying that vibe coding isn't important. It's a great ideation, learning and discovery sort of mechanism, but it's very free form. It's very it's very fluid in in what you're doing without really much of a plan. And what we were doing was different. What
we were doing is creating architectures and process and and approaches that were repeatable with a defined outcome that that was an engineering activity. And what we saw was the the the term agentics and agentic engineering was starting to be co-opted by large companies who were essentially kind of AI washing the concept. There were they were saying it was an agent but it was a chatbot or it was a vibe coding system. And we saw this as an opportunity for us to say well this is our approach. This is what we believe an agentic engineer as a professional as a profession should encompass both technically as well as the sort of ideas of almost like a like a guild but for our group of of engineering right so we're the stonemasons for this new emerging uh field of of you know aentic engineering for AI that and the group formed around that it's open it's it's the sort of antithesis of some of the corporate um open groups open AI sort of being the
other end of the spectrum you know dominated by corporate interests we said we need to make this for people to sort of empower them both professionally and maybe there's some more aspirational but as a as the society around AI takes shape what does that actually look like and how do we protect the interests of the people ultimately that are going to be affected by it most so we act we want anyway to act as a kind of hedge against trillion dollar companies um if we can do that and that was formed in March of this year and next thing you know we're in something like 60 cities. We've got event multiple events sort of organic startups or you know meetups all around the uh all around the world happening every week
and people can just join that. How do people what's the best way to people for people to kind of like get involved?
Well, we've got a a lot of the communic the the communication and community happens around either our Discord channel discord.agentics.org or WhatsApp. Our WhatsApp's maxed out, so I'm not going to give you the address because, you know, when you hit the certain threshold, you basically can't add anybody. Um, but uh most of it we've shifted to Discord at this point. And Gentix.org, it's a again a member-ledd organization, meritocracy if you will.
So the if you if you want to get involved, you want to create a new
Traditional workflows cause agentic project failures
chapter in a different city, do a meetup, basically you just volunteer and we make it happen. So if we were to look at the states of Agentic today, what would you say are kind of the things that are creating that ceiling for for for Agentic today? What are what are the biggest things that causing Agentic uh development to to fail or at least to to to cause problems to developers trying to use Agentic development today?
The limiting factors of the space right now. And there was an interesting report from MIT a couple weeks ago, I think it was, that basically said 95% of agentic projects fail. And it was a a fair a fairly sort of sensational title. And and when you when you dig into that a little bit, you there there's two ways to to to think about those types of sort of stats. one, you know, 95% of projects fail, which is probably true, but the reason between for that failure is likely 99% of of engineers, programmers, developers, project managers don't know how to actually build aic systems and it's a byproduct of a new emerging space. And it and it's so the the limiting factor is the fact that it's really hard to to look beyond the sort of um you know I call it AI washing the agentic washing of products and the and the people
associated with it to determine you know what the capabilities of the products and the people implementing these products really are. So when you see this sort of high failure rate it speaks to the fact that we're in a new emerging space. And when you go, if you're old enough to have been around at the beginning of the internet, you would have seen the same thing with a lot of the internet projects that corporations took on back in the late 90s and there was this sort of, you know, this idea that the internet wasn't quite going to cut it for most business type applications. And then they were wrong.
It was the fact that we didn't as a industry understand exactly how to build userfriendly internet-based applications. And over time there were models to follow. Amazon's and the eBays and whatnot showed up and we're like okay this is how you create a web-based service that people can easily interact with and it's not just recreating software. same problem 25 years later, 30 years later in the agentics and AI space. There's a tendency for people to build applications the way they've always built them with with human centric models, uh, review cycles, long drawn out sprints, um, and different sort of, you know, traditional tactics that were optimized for a world where we built slowly over time and gradually.
Now, we're in a world where we can literally copy anything anywhere at at a moment's notice. and the ability the the quality of the code although important is less important than the momentum that you get in terms of speed and time to market. So when you're looking at companies that are embracing this they're they're embracing this in a way that doesn't just replace their developers that that might be a byproduct but it augments them in ways that those developers were never able to do before. So you're empowering them with sort of a kind of superpower to to to create much more effectively and much more quickly which in itself creates a whole variety of secondary problems. But ultimately this is this is the empowerment of developers to to do more with less. And a lot of the the kind of like ways in which that can be done um in a in a more predictable way I guess is to use rails or guard rails. Um one
Specification-driven development enables complex agent architectures
of the things that that came out of the foundation I believe uh was spark s um talk us through a little bit about what kind of was the driving force behind spark. uh was it was it pain in terms of you know seeing how people or yourselves were being able to develop code and what the different kind of angle or perspectives you needed from that because I know it's obviously very specificationbased but there are also a number of different things beyond just specifications which are important to to allow your aentive processes to build in a predictable way.
Exactly. And what we saw if you if you rewind about a year and a half, we saw that a lot of the early work within these uh coding systems even before agents became sort of popular were limited by the specification itself. And a lot of the development was happening on a kind of function by function basis. Fix this, copy and paste this into the system and and as you said it kind of autocomplete, which was fine and and that was not a bad starting point. But once we start looking at how do we create larger more complex applications with interconnected relationships, data structures, user experience components, infrastructure, it be it became important to create a specification that the AI could follow, implement, test and verify. Now part of that it was an homage to some of the work I did 25 years ago with Sun Micros Systemystems and their Spark processor. I'm not going to lie, this the Spark with a C. and and uh AI is pretty good at creating acronyms and as anyone can see the RUV
stands for something new every other day for me but ultimately the the specification allowed for a kind of specification that said here's what I'm building a PRD if you will and then rather than building the entire specification what what I ended up doing was saying I need to create a pseudo code outline though so I'm not trying to build the entire code obviously that's going to happen at a later stage what I want to do is create a scaffolding allows the AI to understand the general structure of what the code needs to look like before it implements it. So the second stage was basically a kind of rudimentary scaffolding of all the parts of the application. Then we then once we had that then we have a defined architecture an architecture that that would be defined based on the code. Once we had that then we could go through a refinement phase that was the iteration.
The refinement provides a mechanism to say now we have a pseudo code outline and a defined architecture which includes all the various parts of the application. Now we can start actually start building that the refinement turned out to be a really interesting part when we got to the point of parallel or concurrent development process. So now that we know exactly all the parts of the application, we can get different different agents to work on different parts of the overall application independently of each other,
3 Highlight · Applying the London School of TDD to AI agents
although connected through the architecture itself using a test-driven development approach, which is the completion, the test-driven development approach. And I'm going to give you a quick background for those that aren't familiar with test-driven development. There are essentially two different approaches to test-driven development. the traditional test-driven development approach, sometimes referred to as the Detroit school, which is essentially creating the test as you create the code. And that's what most test-driven development today does. You have a function or or part of an application, you create a test, you write the code, it passes, it fails. That was great for people, but it's not great for autonomous agents building things. The other approach was referred to or is referred to as the London School of Testriven Development. Now, the London School of Test Room Development uses a a scaffolding. It's basically developers hate it because you're basically creating the entire application several times. One, you're creating the entire much like what I defined in in the Spark architecture. You're creating the outline of all the parts and how all the parts work before you ever build the
application. Then you're building the application. It fails. It always fails. Then you're then you're doing it again. So, you're literally building the application at least three times, possibly four times. But what's interesting about this approach when you have AI agents is one, they don't actually complain about having to do the same work four times. They they're AI and and you're doing it really really quickly and concurrently. So what would take months or many weeks now can happen in an afternoon and and that and that provides again a guide for
the AI to follow. And once all those p all those tests pass generally speaking assuming there's there not completely simulated your application works. Now different languages work better than others. So there a lot a lot of people ask what's the optimal language for
4 Highlight · Combining rigid specifications with deterministic languages
this? Well you know there's Python and there's you know Node and JavaScript and TypeScript things like that. But the problem with those languages is they're permissive. Meaning that these languages are allow you to build with a lot of flaws and they they'll they'll basically work even if they're not right. And then you have languages like Rust which are very explicit in in their definition deterministic. It's really hard to build bad things in Rust because it just doesn't work if it's if it's not built correctly. So by applying a rigid specification to a a less permissive or rigid programming language, the combination gives you the ability to build really really complicated hard broad projects and basically know reliably that it'll work when you're done.
Yeah. And let's dig into a few of those pieces uh in a bit more depth because it's really there's so many interesting things that you kind of like just just outlined there. First of all with specifications when when when you when you look at your specifications and you
Embedding validation test cases at project inception
talk about the capabilities are you are you adding effectively highle test cases as part of the the specification or is that something that is really done at the end
I'm doing at the beginning so I'm I'm
right at the beginning
I'm doing at the beginning so uh though so when you follow the spark and there's different ways and a lot of people will massage that to their own needs but basically what you're doing at you're creating these sort of requirements the you know what does the product need to do how does it need to solve the problem what are the algorithms what are the flows the data structures the authentication you know all the things you'd want in the application then what you're doing is saying how do I validate how do I test that this thing actually does what it's supposed to do and that is the biggest challenge you're going to run into in any of these automated systems is you know at the end it says it's done and it's not it's it's a it it had it's a convincing forgery it's a it's a fraud and anyone that's ever led a a sort of uh AI run for a while and and looked at and says well this isn't true this isn't right and that that's a byproduct of an an of a uh specification that doesn't have the tests adequately defined to define what is true and what is not right so when you integrate that as part of the development flow you can uh sort of mitigate the potential for
fake or fraudulent sort of results
yeah and and it also feels like it's a far easier thing to describe when you're talking about the specs and you're talking about the behavior, you're effectively describing tests. It's like it's it's hard to do one without the other. Um you then mentioned pseudo code, which is really really interesting. Um when we talk about when we at Tesl we're constantly thinking, okay, should the specs care about the implementation at all? How much should it kind of like deep go deeper into the implementation or about the how something should be um created? And there's always a fine balance between the the the what and the how. And it sounds like with the pseudo code, it's interesting that that that kind of like doesn't necessarily provide language specific uh information, but it does provide that ability to be able to define parts of the infrastructure, define how I architect this application to be to be created. Um couple of questions in there. Um, first of all, while that I suspect provide gives the LLM a better way to actually then go
ahead and actually create implementation, do you find there's a balance there between how accurate it can be with the implementation, but also how um how prescriptive you're being with the LLM. Does that does that provide benefits as well as kind of like drawbacks or do you do you find that that's like, you know, the the the best the best of both world solution for it? I think the prescription prescriptive I should say is is is a good description of it. What you're trying to do is is
Treating agentic development as multi-threaded narrow tasks
the more narrow the task the better the result. So when you look at at you know a agentbased development a lot of times people take the analogy of replacing a developer or persona. It it's not like that. You're not you're not they don't operate like people at all. And this idea that you're trying to replace, you know, traditional human tasks and and development approaches with a agent-based approaches just doesn't really work. When what you need to look at this is like a multi-threaded development process where each thread is specifically tailored to a particular narrow problem you're trying to solve within a much larger group of threads.
And so one thread might be literally a one function that that that calls a data or CLI or or some other particular part and once that's done it it's it's functional. So an application is made up of many many many threads that that are working concurrently to solve that being tested and as you say it's prescriptive in how it's defined. Does it actually do what it's intended to do and did I do a good enough job of defining what I wanted originally? Now, sometimes I don't, right? Sometimes you you're not really sure what you want to build and and that's the that's also quite exciting is to explore the the unknown and and seeing what I can build uh kind of in a more vibe style. But that said, I still need to be prescriptive in the approach and the tactics that I'm using to build those things. So what this led to things like cloud flow which allowed me to sort of share my development approach in a way that was open enough to be interpreted and used in a variety
of different sort of architectures, methodologies and and applications themselves, but but narrow enough to do so in a way that allows people who don't necessarily know all the things that they don't know to do it in a way that wasn't going to result in a bunch of spaghetti that doesn't work.
Yeah, absolutely. And and I guess the second a second piece to this and I and I I guess when I when I first started playing with Kira as a good example, one of the first things I noticed was when they when they use specifications, the spe the the life cycle of the specification tends to be the change that they're trying to make. So if I were to make a change to an existing application, I would say this is um this is what I'm trying to do. It would create a specification based on the changes it needs to make. it would create a design style spec as well and it will create a list of tasks that it needs to do to actually enact that you know create that change. um if I were to then carry on I would probably create a new specification for a new change it the life cycle is based on that change whereas what I'm hearing from you is more that the life cycle of the specification is the application or is
Using SQLite memory and switching between hive minds and swarms
it is the specification is that is that is that I guess kind of first of all a fair representation of how you think of specifications and and also claude flow uh works with specifications and we'll kind of get on to cloud flow in just a sec
one of the things that I'm doing when you look at sort of my development is I'm I'm using so a lot of these systems are based on the idea of markdown right you would be able to create a docs folder plans folder and and in create specifications those specifications would probably define multiple phases where you are in the implementation strategy and and it would sort of you know iterate through the those phases and markdown files. Now the issue that
5 Highlight · Shared SQLite memory and the hive-mind versus swarm dichotomy
we faced when looking at that approach was the fact that it lost context. it wasn't contextually aware of uh beyond the last MD file or or if it happens to look at the other MD files where it was in the actual development process. So what I ended up doing was using the approach of a kind of shared memory space and and I I I made it simple. A lot of people were were focused on using vectors and complex sort of similarity up you know searches. It turns out you don't need any of that. Turns out what you really need is a common uh simple SQLite storage environment that allows all the agents to you know save their current state as well as access the previous state in in a way that was easy for any agent participating in the swarm to see and and interpret. Then that that that opened up two general directions.
One was a swarm. A swarm uses the concepts of of sort of independently operating agents or or sometimes I call them threads but these agents were essentially operating with a common direction kind of orchestrator of sorts that would tell them generally what to do and then the each agent would be sort of autonomous in the sense that they would be able to make their own determination how to solve that problem and then they'd update the status and and through that sort of shared memory.
The other approach, which uses the concepts of a hive mind, which sounds straight up sci-fi, creates a a the ability for each agent to share the exact context of what's happening at any given point rather than rather than running autonomously, which I would assume like an ant colony, it might be an example. Each ant has a task. They they've got leadership and and are orchestrated through the pherommones of the queen, but they are they are autonomous entities in a sense that they don't share at least I don't think they do share conscious constructs between each each of them. The hive mind allows you for a common I'm going to call it consciousness. It's probably the wrong term a common sort of mind and to understand what's happening at any given point and then adjust based on it.
Solves different problems totally different development tactics. The hive mind approach is generally better for broad early development. You know, you're you're going to build a bunch of things quickly, you know, hundreds of thousands of lines of code and you want it to sort of all more be more integrated in in the sense swarm is a little more targeted. So, I think of it like a sculptor might. You get a big giant piece of granite, you're blasting away at it at the beginning. Hide mind.
When I'm getting when I need more narrow, more details, I need to do the nose and the ears and the eyes. I'm going to use swarms and specific parts of that to really target the different parts of the thing I want to build. I'm building the face. I'm not building the body at this point. The swarm's great
for that. So, you change your tactics based on where you are in the development of your application and and the tools.
Yeah, absolutely. And I I guess in terms of, you know, this this thinking of if I'm going to make a change or if I'm going to add something to my specification, I don't want it to necessarily regenerate everything. Is is the hive mind also good at kind of like recognizing what needs to be regenerated, what doesn't need to be regenerated to make sure you almost preserve that history of of I guess context of what how everything else has been built. I guess what does that workflow look like? It it it's it's adaptive which is the which is the most interesting part of these things.
They're they are given a level of autonomy and a declarative approach to solve those problems based on the requirements of the overall project. The current state of the implementation of the project does it work? What what's left to do? And a sort of human in the loop that guides that process. And ultimately what what we're doing here is is a kind of I don't know it's gonna sound crazy a symbiotic relationship between the AI itself and me the sort of developer the swarm master whatever you want to call it that that helps guide through the steps. What I'm not generally doing is letting this thing run for six hours and you know sometimes I do but but more I'm doing sprints. I'm doing hour or two letting it solve the hard problems. Uh ideulating, optimizing, you know, and and and then I'm reviewing then I'm moving on to the next phase and I'm the I'm the reviewer and that's an important part of the process.
And as part of that, if if you asked for something and then it goes away and actually completely rebuild something, um so long as the pass the tests pass, do you care or is that something that you would consider risk?
I I don't trust anything. I val I I I I validate and verify everything that happens. Just because it tells me the test has passed doesn't necessarily mean I believe it. And and it often now that I'm I've gotten pretty good at doing this. When the test pass, it means it is generally right. But I assume it's wrong. And I need heavy level of proof to validate that it's built it in a way that I like, that it's secure, that it's scalable, that doesn't hardcoded any env in the source code. And one of the other challenges that we have with a lot of these systems, Claude code in particular, is the context engineering itself. It starts off great and after, you know, 45 minutes of doing whatever it's doing, it's compacted the conversation a few times and it's lost its context. So the reinjection or reminding a kind of power steering of sorts for the system is really important. And and I think tools like was it R code did did power steering where you could sort of have a
reminder of where where it is every now and again it works works really well and and these systems need to be reminded of of its purpose and focus.
Yeah. And this is something that actually that that kind of uh Claude
Unlocking massive concurrency with batch tools and Rust
flow does very very nicely as well. I'd love to kind of jump into Claude Flow now. Um tell us a little bit about this is some this is a project tool that you created. Um uh when did you first release actually it was it was fairly recent the last couple of months.
June 15th is it was June 15th. Yeah it was funny and and there's a few things that that was I learned. I've been on an epic development um sort of sprint over the last two months and I' I'm I've lost count but last I checked I was like several million lines of code and and a lot of different roughs projects and what so the first version was essentially I discovered something
6 Highlight · Accelerating development through parallel sub-agent batching
called the batch tool within cloud code. The batch tool essentially was an undocumented part of their system that allowed me to move from a sequential implementation of the agent. So, if you ever use plot code or a lot of these other systems, you'll notice that it does task, finishes the task, moves the next, and moves the next. What the batch tool allowed me to do was create sub aents, which interestingly enough, Anthropic adopted the same term. Thank you, No credit to me, but whatever. And then um so with the sub these sub agents essentially allowed the again the threads each of these things could run in a parallel form all at once. So rather than sequentially, I could spawn 10 or or I think at one point I did 500 of these agents. I generally run in smaller numbers and odd numbers wherever possible. And I'm not sure why odd numbers work better, but they do. And essentially what that means is there, you know, one's doing, you know, a a task, another's doing another task, and and and then they can all run at the same time, which took a project that would take me three or four hours and I
can now do in a half an hour because I had agents running concurrently rather than sequentially over over three or four hours. So the speed was dramatic. It was basically a linear um increase in in in sort of capability or that
decrease in in time. So 10 agents is 10 times less than you know and but there's also a sort of max I noticed that I really wasn't seeing much improvement beyond around 20 agents for for things unless it's maybe doing like machine learning models and optimization but for most development centric things it kind of maxed out around 10 or 15 agents and I wasn't seeing really any improvement beyond that and and at which point I then said okay I I think this is something that others would want and because I was doing a lot of work in Rust. I had concurrently developed a micro neural network architecture you where I ported one of the first projects I did in in the B1 of of the sort of batch style agents was basically porting existing complex libraries into Rust.
I'm like what's the most complicated thing I can possibly build? That's literally what I was thinking. and and the first one was the fast uh neural network project and um which I think is referred to as fan sometimes. I ported that into Rust made it a a Wom a web assembly component that I could run in the browser on CLIs or or servers without any requirements. So it's portable it's light and and was around I don't know the exact number but substantially faster than the traditional C and C++ implementation. I package that up, put it into cloud uh in into a sorry mpx so I can deliver that through a common mpm or mpx uh delivery.
So if you ever install different modules for for typescript or mo or noode.js, you do the mpx. So I can deliver these really complex rustbased components as a typescript module, meaning I can get it to anyone anywhere pretty much. And I created the first version that combined the idea of a of an adaptive neural network along with a swarm component and I called it claude flow launched it and and suddenly within a matter of hours I had tens of thousands of downloads of this thing and and we were sort of inundating uh anthropic and and I don't think they were particularly happy about this. So within a within about a week I had about 100 thousand downloads and we were doing you know just billions and billions of tokens through the system and I I'm fairly certain we were a large part of why they revised their um their model. I'm sorry it wasn't wasn't the plan you know but they said unlimited.
7 Highlight · Distributed micro neural networks built in Rust
So in fairness, I I was taking advantage of of that uh of that of that. And then that led to a sort of recursive development where I could improve the things I was building even faster because now I had this adaptive neural network that allowed me to optimize specific kind of synaptic components. So micro neural networks that were interconnected to each other and self-optimized. So where traditional neural networks were monolithic, you'd have billion plus parameter models, what I was doing was creating very narrowly focused neural networks that were explicitly built for a task. Trade this one stock in a certain way, understand a particular customer segment or whatever it needed to do. And so I was training 10,000 or maybe 100,000 parameter neural network models and then applying it to the actual application to solve the problem.
So we get really really smart at that one thing. trade that trade a stock better and and I didn't need a GPU because I'm using subund,000 parameter models. No GPU is required. I could create a neural network in in seconds based on the Rust library that does the one thing and no GPU required at all. which basically changes the paradigms from a a a monolith to a distributed
sort of synaptic network of many small interconnected neural networks that all can collaborate with each other which is straight up sci-fi.
Yeah. No, absolutely. Walk us through if you can the the or or show us if you can the the the uh the claw flow in action. So I'd love to I'd love for the folks and listeners to almost like see the um uh I guess the use cases. Would you would you say it's more for people who are creating from scratch or would you say it's more for people who are trying to convert existing applications into a spec more specentric uh approach? What would you say is the is the core use case that people uh pick up? Claude clo
I've been working on a new gamified version of the system that allows users to learn how to use it by participating in challenges and different types of of sort of gamified version of it. So you know it it's broad it's it's it's for
Demonstrating Claude-flow CLI and swarm initialization
everyone from early users to you know a master aentic engineers and hopefully everything in between. Um let me give you a little demo here hopefully. So this the in a sec I'm what I'm going to show you here is my um flow nexus development environment which is a new project I've been working on. Hopefully I'll launch it later this week. Let's see here. What I'm showing you right now is a code space running in in GitHub.
When you run swarms, remember you're running in a kind of dangerously skip permissions mode within cloud, which means you probably don't want to run this on a local environment. you can um if you're using Windows Wows subsystem WSL and Macs are probably a little more forgiving. I'm running an Iuntu code space on uh GitHub in this case. Now to install, as I mentioned before, I'm using an MPX or an MPM. Now, you can install either way. An MPX for those who aren't familiar allows you to run in a kind of remote instantiated version. So, you're always getting the most recent version. an MPM an MPM style install which looks something like which looks something like this installs it globally but doesn't update it automatically as you so you don't get the you're getting kind of a moment in time. So generally what people are doing is they're running an MPX and to install it all you're doing is running claude-flow at at alpha. This at alpha part basically means you're getting my my alpha version and it's it's alpha until I'm confident that there's no bugs or I
stop developing I suppose. But you're getting the the you're getting the alpha version at that point. Now to verify all you're going to do is is write version. This is going to this is going to instantiate. You see I'm running alpha 91. Now once once we have that we can run the help command. The so this is a CLI but the CLI is actually and MCP server I might add is is optimized not for you to use directly. And this is the part that sometimes people get confused by. most of the capabilities of the system are actually optimized for the system itself to to use. So for example, if if I run a command to update the memory, I could I can invoke that command directly. Well, in this case, I'm going oh, I got a Riverside sharing.
So I'm going to I'm going to update the memory. I'm just going to type this command session generate summary persistent. This is but the AI is intended to do that. So you can see here I've been running this for 9,700 minutes. I've done 559 edits. So, G. So, this is basically giving the context. But if I want to actually build something, I've got a couple different ways to build. I've got my my my wizard. So, I can go you can see here that I've got different options. So, I've got training. I've got verification. There's a ton of stuff in here. Um, so I can start. I'm just going to run the wizard this this time. So, I'm just going to copy this. And this is going to guide you through the process of running the wizard. So in this case, I'm just going to go and and choose alpha and I'm going to do the hive mind wizard. And this guides you through different options for creating swarms, viewing the swarm status. So the these are the more human parts of the interface. So I'm going to create a new swarm. I'm going to to press the uh you know live cast viewer
viewers uh optional name. I'm just going to let it do whatever it's whatever it wants. Now, I've got different approaches for this for the queen. Interesting enough, she named herself I didn't. She named herself Saraphina. Uh, which is interest I I did a little, you know, my wife actually when I told her about this thing, my my swarm gave herself a name, but she's now our mascot. So, I'm going to choose I'll just choose strategic. I'll say seven agents.
I can choose which agents I want. And then I can go and I can choose how the agents come up with their consensus for making decisions. So I can choose different types. I generally use majority. So if I've got a seven agent swarm, four four agents will will determine the the the direction when you generally use odd numbers. Um even numbers for
you. You mentioned that before. Why why why do you think that is? Uh well even numbers just you know if two two out of four or you know five out of 10 you know just doesn't really work for consensus. It's funny how when you actually look at nature you see so many odd numbers or Fibonacci for example just being used very very naturally throughout throughout nature's choices. So it's it's it's really interesting that that odd numbers you know it kind of it seems very poignant to me that that it naturally chooses odd number or naturally works better with odd numbers.
Yeah. Yeah, it seems to. So, I'm gonna I'm just gonna do majority autoscaling. Sure, why not? And then I'm gonna launch dash. No, I'm not going to bother with that. Still building that. Um Oh, I had an error. I'm in my I'm in my dev environment. So, that that no worries. We're we're going to invoke that anyway. So, in this case, I'm going to spawn uh and then I can give it a title. Uh create a re create a five agent swarm to research uh I don't know swarms and then I'm going to add the claw to invoke the cloud system. In this case I'm going to go right here. Oh, I'm having I'm having some trouble with that. I'm going to I'm going to I'm going to jump the the uh I'm going to use a swarm instead. That's the problem with showing you a dev environment. All right, so we're going to go here and we're going toh do swarm.
I'm going to use the same uh so there's two modes, the hive mine, which apparently is having an issue at the moment, and the swarm. So in this case, I'm just going to do that for this one. Hopefully that solves that problem. And there we go. So now we're we're launching a um an agent. You see that I injected a bunch of information. This is basically telling it the MCP tools to use. and where we've got different sort of uh options. I I I didn't I'm not going to do anything. I'm just showing you sort of the process of spawning the the swarm itself. Um so now it's it's initializing the swarm. We'll see that it'll it'll it'll make use of the CLI and MCP components on the fly.
And so here we we're oh dev environment. I I I should have probably prepped a little bit more, but this this is trying to invoke the swarm types. Well, we'll see. It's it's self it's self-fixing. So we'll we'll uh we'll see what happens. There we go. It figured itself out. Now when you when you see these these here, this indicates that it's an agent. So we have got colorcoded agents. You can modify all these things by going into the agent folder and claude here or the commands which are the slash commands.
And you'll see that I've got all the different commands available to it. So the it it's it's invoking its own sort of you know persistence. It's it's creating the tasks. It's using the MCPs and CLIs to do the sort of coordination before it then launches the the the swarm itself.
And when you when you talk about the swarm, would you use the swarm primarily because you wanted to have different roles and different perspectives or would you or do you see it more as a parallelization task where you're effectively trying to get 10 things running at, you know, in the space in the space of one?
Uh, it depends. It depends what you're trying to do. So in this case, I I gave it a pretty generic sort of, you know, guide. It's I said to research swarms, which isn't really telling it to do much, you know, more more just to invoke it more than anything else. So depending on what you're trying to do, you you can have different sort of processes that allow it to to deploy and work in different manners. So in this case, if I go here back to the MPX for a moment, you'll see we'll see different the different options. So we've got options here for for training. So this is doing all the the neural network components. So you can optimize monitoring. You can you can do things those sorts of things. I got a verification system that handles sort of defining the you know is it actually building what it's supposed to is it is it actually is it truthful? is, you know, is is it and then I've got the ability to integrate people into the process using a kind of collaborative pair based programming that sort of integrates the concepts of of, you know, other participants that aren't AI into
the process. And so lots of different sort of components depending on what you're trying to do. So the answer is it really depends on what problem you're trying to solve. And that's part of the idea of an agentic engineering system. It's meant that you are the active orchestrator engineer of the process and and you can make it your own. Right. I I made this for engineers not necessarily for vibers directly.
Yeah, absolutely. And interestingly when you mentioned when you talk about vibers there when we lean more into specs with things like things like this and you can kind of like fire off a number of different agents to kind of like run things and we get much much longer running processes. Do you feel like I I've kind of like, you know, thought about vibe specking as something now whereby we're still vibing, but um we're actually losing contact with our specs a little bit more in terms of reading them firsthand. Is that is that something that you have also kind of like felt a little bit whereby you're you're more
Prioritizing specifications while guarding against AI laziness
you're more able to kind of like interact with an with an LLM on your specs and then have everything get generated from there? um or have you found like the new the new way of development is about this inter this direct interaction that we're having with specifications.
The specs are the most important part of the process and you know people ask me like how much time am I spending on the spec versus letting it run. Now, I'm spending all my time on the spec. The the letting it run part is just letting it run, you know, but telling it how to run is is a particularly important part of the of the process itself. So, without a decent PRD or technical specification, then you're not going to get a decent output. Are you very specentric now whereby the source of truth is the spec? Um, how much do you then touch code after after actually generation from the specification? How much do I touch? Uh I I depends. One of the one of the things that you'll notice when you do you know a AIcentric development is there tends to be a cognitive offload. It makes you lazy in some regards and that and I'm not any different than anybody else you know. So certain things obviously if I
want to change a title or or do some text somewhere it's quicker just to up and edit the thing. But even then sometimes I have a tendency to just say Claude go do that which is kind of silly. I could literally open the file and edit the the the code in in like 5 seconds. And in that scenario the CL you know cloud code is going to take you know longer to do that even but I'm just lazy right go do that. That's a challenge right? AI AI for has a tendency to give you make you powerful but also make you a little lazy in certain regards.
Yeah. Yeah. Super interesting. What do you think are the next steps from an agentic point of view? What where do you see the agentic future of software development heading?
I think we're we're going to we're going to get better fidelity. I think we're we're reaching a we're in the early stages of this and what I'm showing are as a kind of leading indicator of what's possible and what what's capable. Most there's two schools of thought. When the people see the stuff that I'm building, it's what they call AI sloth. It's like there's no way that this guy could build so much stuff so quickly and have it be of any real value or capability. I think the fact that I I was able to get hundreds of thousands of users within a matter of of days of my platforms indicates that it's probably not. But, you know, it's hard. It's, you know, there's so much there. I get and I understand why people would think that.
There's no way for them to review that. There's no way for me to effectively review millions of lines of code. So the the assumption that it's bad is is probably um you know understandable but it but the at the end of the day the real litmus test for this isn't whether it's bad or good or whatever is whether one it's actually solves the problem it's intended to solve like does it actually do the thing that you you wanted it to do. Does it? And then secondly, maybe primarily does it do it in a way that's that's effective, secure, and optimized, right? And and if you can check off those things, then that is all that matters. Now, is it like, you know, artisan code that's optimized line by line written by, you know, someone with 50 years of coding experience? No, it isn't. It's a different thing. It's it's it's but it is something that I could create in a moment to illustrate or I can create every possibility of a problem and and
choose the best one where where previously I'd have to choose I have to make an assumption and go with that assumption whether it was right or wrong. I couldn't test every assumption and choose the best of the assumptions because it just wasn't enough time in the day or the cost, you know, was cost prohibitive. I can do all that now. I don't even need a team of people. I just
Overcoming validation challenges in agentic workflows
need to ask the right swarm the right question.
Yeah. And what would you say is kind of like as a as a final question, uh, ROF, what would you say is your kind of like the biggest bug bear right now that you have with with kind of either I guess agentic flows or LLMs perhaps? um in in an agentic flow, what would you say is the biggest problem that if you could click your fingers and make it disappear or have a workaround or a solution that today is causing you the most problems with your with this kind of you know nice workflow whether it's through clawed uh flow or a gentic development today.
Validation I think is still a challenge and I I think we've discussed this a few times today. Is it is it true? Is it real? Is it does it actually do what I needs to do in the way that I wanted it to do that thing? And ultimately, that is the the key here. And that's it's anyone that's using Cloudflow, pretty much anyone using any of these systems that you know are are are suffering through that a little bit. What regardless of of Claude or whatever else, they all they all suffer from that same problem.
Yeah. No, I think it's a very fair assessment actually and I think it's something that we'll hear again and again with validation. And I think it's super important for trust and actually just making sure that what this is kind of you know busy busy building and busy uh busy developing is uh is is fit for purpose and and and actually what we want to we want to deliver. Uh rude this has been super super useful. I would love to you you kind of mentioned where people can you know access to the uh to the foundation in terms of next steps if people want to learn more about spark or if people want to learn more about claude flow where do they start? I created a new landing page finally. I'm like the shoe maker that doesn't have any shoes for a while there. But um yeah, I I did end up creating a landing page. It's done quite well for me. Um roof ruv.io. You can see all my various projects and and uh things that I'm building at any given time. I'm I'm very prolific on GitHub.
Um githubet ruvnet. Um, and uh, you'll see all my various projects which runs the gamut from useful to just crazy. You know, that's I'm just trying to push the boundaries of what what I can build and what these systems can do just because
valuable to crazy. I you know, you could call that valuable to inspiring, I guess. Let's let's let's do that, shall we?
Yeah. I'm I'm not I'm you know, I I know I'm on the right track when people say it's not possible and you're crazy like that. That's like Perfect. I'm looking I'm looking at the right things then. That's perfect. Yeah. Yeah.
Every like the if you go back like three and a half years ago when we started using the term agentic engineering everyone's like no that's stupid. It it doesn't mean anything. It it sounds like a scientific or or medical procedure. Um and and you know that that only inspires us to try more and do more. So you know we're on the right track.
Amazing. Ruth, it's been an absolute pleasure. Thank you very very much for all the insights and I and I hope our listeners enjoyed it as much as I did chatting with you. So uh thanks again.
Yeah, my pleasure and thanks for having me today.
Absolutely. And uh for those for those listening, please join us uh well first of all subscribe, like the video and please join us for the next for the next tune in to the next episode as well. Thank you very much.


