Last day of Apollo Summit. If you're here, come find us at the Xolvio + 10kR booth and tell us what you'd want a brain for.
After Summit I'm going to write up how we actually build these. BuildBrains.co
BuildBrains.co is live!
@xolvio and 10kR work with your team to turn how they do a job into a brain that runs it, built on @beonauto.
Last month I said the next one after graph engineering would be BRAIN ENGINEERING.
In 20 minutes it's in the @apollographql Summit keynote, with Stephanie Wiseman from 10kR on stage. Pretty excited about this one!
Watch live:
youtube.com/live/A8kOpg8yyMg…
Day 1 at Apollo Summit with the 10kR team. Come say hi if you're here!
Tomorrow's the big one, keynote at 9am PT.
Still not registered? It's free: reg.apollosummit.dev/event/s…
Apollo Summit starts tomorrow! Our part is Wednesday:
9am PT: keynote, with Stephanie Wiseman from 10kR
2:50pm PT: Antônio Falcão, "Your Company Needs a Brain" (in person)
And if you're in the SF area and want to come, it's a completely free ticket: reg.apollosummit.dev/event/s…
We've been doing GraphQL and event sourcing for years, and now AI is demanding it more than ever. When an agent acts you need to know what happened and whether it was allowed to happen, let alone what happens! We're on stage talking about this next week. Come see:
In SF next week? Free Summit ticket: reg.apollosummit.dev/event/s…
The best part of working with a big enterprise marketing team on this: their domain expert, who isn't a developer, ended up shaping the workflows himself.
He already knew exactly what he wanted. We just gave him the building blocks.
We're building the brains with our friends at 10kR. They do strategy, product and design, we do the engineering, and it's a great mix.
We're both at Apollo Summit in SF next week. If you're in the area and want to come, here's a completely free ticket: reg.apollosummit.dev/event/s…
We've been building something on @beonauto that we call a brain.
It takes the way someone at your company does their job (how they spot a problem, what they check, what they decide) and runs it as software. Some steps run on their own, some still need a person to sign off.
Auto and Xolvio have been drifting toward each other.
Auto customers wanted their ways of working turned into something that runs. Xolvio's enterprise work kept needing reusable AI capabilities.
So now it's Auto, by Xolvio: the product plus the engineers to put it to work.
Been quiet here for a while. We've been busy.
Building Auto with customers, we found they wanted to automate how their business works. So @beonauto is now a @xolvio product, and with 10kR we're building brains.
Apollo Summit: reg.apollosummit.dev/ code CHAMPIONS_COMP_AS26
Prompt Engineering → Context Engineering → Harness Engineering → Graph Engineering →...
I'm going to call the next one right now...
BRAIN ENGINEERING!
Been quiet for a while. We’ve been simplifying @beonauto, and now have something to show.
Pretty UIs are great, but getting the workflow right is what separates a toy from a serious app.
Auto gives you and AI a shared “product memory” to build from. Check it out!
This is what is means to really be spec-driven.
A test proves that the system under tests meets the specs. But you cant' do that all at once, so you iteratively add to that executable specs base (aka tests).
Then you can let humans, agents, or magic pixie dust unicorns deliver system. As long as it passes the tests, the specs are being met and you're good.
The argument is always "but you can't cover all the cases, so you need to look at the code"... since when does a human catch all the issues from looking at code??
We look at the outcome, and iterate with new specs, which require tests, which can then be met. That's the magic behind XP, TDD, BDD, and now spec-driven.
Anyone that calls spec-driven anything else has missed the lessons we learned over the past six decades.
AI agents can write code many times faster than a human. What this means is that you, the programmer, have a large amount of time to use those agents to write unit tests, to write acceptance, tests, to write property tests, to torture test, to mutate test, to QA test, and to otherwise ensure that the code meets its functional and quality requirements. And even after spending all that time, you will still be many times more productive than a human programmer, and the result will be better.
This is the way
I’m significantly older than you. I started coding in the late 60s. My current strategy is to not read any of the code written by my agents. That’s the only way I can take advantage of their productivity. What I do instead is to surround the agents with extreme constraints. Unit tests, gherkin tests, QA procedures, quality metrics, mutation testing, test coverage, and a plethora of others. In the end, I have very high confidence in the code they produce because they’ve had to run the gauntlet of all of my constraints and tests.