What does it take to stop babysitting your coding agents? Ajay and Andrew open with how big-tech office politics quietly manage people out, then get into the real news: Luxwander finally has a true progress number (95%), and the workflow that made it measurable has been split out into Rigr — a spec-first system with assurance tiers that let you dial expected quality from NASA-grade down to digital handyman. Along the way: a Minecraft server with a physical gold economy, why front-loading specifications kills a hundred rounds of code review, parallel CI as the new agentic bottleneck, the multi-repo versus monorepo argument, and a closing debate on whether today's models are intelligent or just acting.

In this episode:

How people get managed out, and what an IC can move without authority

Luxwander at 95 percent, and what a real progress bar took

Minecraft Nations: guilds, territory, and a physical in-game gold economy

Assurance tiers: matching AI effort and cost to the stakes of the job

Rigr: specs, slices, and contracts before a line of code is written

Parallel CI, multi-repo orchestration, and the monorepo debate

Are we the intelligent ones, or is the AI acting?

Chapters:

(00:00:00) - Teaser: launch a rocket on tier five

(00:00:18) - Office politics and how people get managed out

(00:06:37) - What an IC can actually move without authority

(00:07:42) - Luxwander at 95%: finally a real progress number

(00:10:36) - From "just build it" to eighteen modules

(00:11:52) - Minecraft Nations: guilds, territory, a physical gold economy

(00:19:28) - Assurance tiers: NASA at one, digital handyman at five

(00:25:39) - Why Rigr got split out of Luxwander

(00:31:39) - Zooming out to an orchestration layer over the agents

(00:38:30) - Front-loading specs to kill a hundred rounds of review

(00:40:55) - Modules, slices, contracts, and isolation

(00:51:16) - Parallel CI becomes the agentic bottleneck

(01:00:25) - Multi-repo orchestration and the monorepo argument

(01:06:23) - Opinionated defaults, and why design stays human

(01:08:43) - Tier thought experiments: rockets and cancer screening

(01:10:58) - Are we the intelligent ones?

Um, I guess I can just talk about real quick about this YouTube video I've been

watching.

Okay.

It's interesting.

It's about office politics, particularly Amazon, which you're familiar with.

There's this retired VP, and I'm only about two hours into the video.

It's three hours.

Oh, okay.

And they're just talking about like how they manage people, fire people.

Oh, yeah.

Okay.

You know, they, you know, they move people around to fire them.

Um, it's, it's good to know.

That's, that's, I mean, a VP individual, that's, I'm curious because that's a level

where they probably see a lot more of it.

Yeah, yeah.

Just like, just like they probably have, a VP would probably be like four or five

hundred people in an organization.

And it's, if you assume like a five percent, you know, year over year of their VP

for, let's say, four years, that's a hundred people at least.

So that's, that's quite a few.

Yeah, no, I, for me, what I was taking from it, I was like, wow.

Wow.

Like, these people are vicious.

I mean, yeah, it's, it's, yeah.

Like, the way he talks about some of the concepts, like explaining like how to, like

how things work in the office or how do you get someone to do something, you know,

and stuff like, like, kind of like really, really like pointed conversations, right?

Like, it's just like, wow, like these are like, kind of like conversations that.

Okay.

Like, you would not want to have done.

Like, in person at the workplace in front of other people.

Yeah, in front of other people.

Yeah, I was gonna, I was gonna say, that's very interesting.

So he's retired.

And I think that's another thing is that I, he wouldn't be talking about it this way

if he wasn't retired, I think.

Yeah, I mean, if you're, if you're gonna work, continue working with people, you

probably don't want to be having these kind of like letting these things out of the

bag kind of approach.

I, it's very interesting.

I had never have any, I had one experience from a non

-engineering person.

And it was very much a, hey, this needs to get done by this date.

And I was like, yeah, that's the target.

That's what we're gonna do.

And they were like, okay, I have heard of other individuals who had more, um,

strained experiences.

Yeah.

I don't think I've really experienced so many of them personally.

I really will say it's an interesting thing is, uh, I don't know.

Maybe, maybe it was just the fact that I was usually just saying yes to everything.

That could just be what I was doing.

Yeah.

Yeah.

I think it was, it was more so from like a management perspective since it was the

ODP.

Probably.

Probably.

Like there's a lot of politics to be done.

Yeah.

And I think just kind of revealing that side of it to me that I haven't really seen

or heard of before.

It was, it was just interesting to hear about.

I feel like though it happens everywhere.

Like some level of that.

Uh.

Oh yeah.

Yeah.

I feel like you get into the multiple hundreds of people.

You get into thousands of individuals.

At some point you kind of don't have a direct line to every individual in your

organization and I wouldn't be surprised.

I mean, I honestly have heard similar weird experiences outside of tech.

Um, clearly I think if you're, especially on a manufacturing line, I think it would

be very difficult to get that experience like of a personalized experience.

Yeah.

Um, with that, with that being said, I'm, I'm curious.

So like, were there, were there.

Were there mechanisms or something that they talked about?

Was it just like every time things are just super harsh?

Like what, what does, what would the learnings or what was their approach?

So for example, like when, um, they wanted to like

get someone to quit.

Oh, right.

They would just move this person to like a different org that people

considered like other.

Oh, interesting.

Yeah.

It's like, it's not an org that is like doing anything in particular.

Yeah.

Like for example, they weren't like working on like the Kindle or, or, or something

like that or the fire stick or whatever.

Right.

They were working on like something that's not seen from the public.

It's just other, they're like, okay, it's just something that has to be done, but

it's not going to get used like visibility, visibility anywhere.

So it's basically a dead end.

So it's a, some deep internal service somewhere that, you know, probably other

individuals who are, you know, internal users exist.

Some subsystems that may be public facing exist, uh, though the actual system that

you're working on might be three levels removed from any external customer.

Yeah.

Yeah.

And I, and I was just like, oh yeah, so that's a, that's a way to, they were just

saying like, okay, this is how we get rid of people like without firing them.

I mean, it is a discouraging motive, right?

Like, I mean, no, nobody in the tech industry who I think is came in with a lot of

energy and a lot of motivation wants to work.

Kind of in that position, um, there are individuals who feel very comfortable in, in

their career, comfortable where they are, who may pick that up and just be, I have

said this before on this podcast is like, uh, engineers, honestly, a lot of times

are janitors.

Those that embrace the janitorial duties actually make out very well if they are

accepting that that is what they're going to be doing.

You can earn a really good paycheck and not care about like, what is your day to

day.

Right.

Right.

Um, but that, that is a different place to be.

So.

So if you're coming into the industry and you're hoping to get like a really cool,

you know, in a big organization, working on Kindle, working on other things like

that, um, yeah, it can be really discouraging.

And I think it can be really like, oh, I'm not getting the interesting work that I

want, especially if you're a high performer and you're somebody who's used to being

like, I'm going to build this stuff.

I'm going to send it out.

Yeah.

Yeah.

I can see that, that being away to push them out quietly.

Yeah.

Yeah.

Yeah.

And there was a lot of other things he spoke of.

Um, but yeah, overall I was just, it was interesting to hear about like high level

office politics and how there were some talk of some ways to,

you know, get into that, like at an engineer level.

Okay.

Um, but, uh, I think we're just getting into that now, so yeah, about an

hour left.

Yeah.

Oh yeah.

I think so.

That's, that's a curious one.

Like from an IC perspective.

Yeah.

Okay.

Yeah.

So, um, this is a lot different than, I mean, if you're, if you're a people manager,

you, you have, that is your role.

That is your, you have leverage to do things that you have control.

Uh, as an individual contributor, I really don't think you can force people to do

things.

Um, you can work with managers to get things done.

Mm-hmm .

Um, I think the one thing I have honestly seen be the most effective

is how do you galvanize individuals?

How do you excite them?

You have to kind of figure out the right, um, common, you have to find common

footing.

Then you have to build on that common footing.

Yeah.

And then you gotta excite that this is the common footing that will help us build

that awesome feature that will get a lot of excitement and really drive, you know,

that feature, uh, and, and drive engagement.

And I don't think I've met too many engineers who hate the idea of driving

engagement.

So I don't know how do you, how you feel though?

I mean, Andrew, you, you, you're, you're aspiring, right?

Like here in that same space.

Yeah.

If you could drive engagement, if you could build something that people would engage

with and try and, you know, use, how would you feel about that?

I mean, it would feel great.

Yeah.

I mean, I, I mean, that is what's motivating me right now with Luxwander.

Yeah.

Right?

Yeah.

Like I, for me, it's like, it's a little bit less of a theory since it's already

been validated before.

Mm-hmm .

So there's kind of like that confidence that I know people are waiting for this

product right now.

Exactly.

Like people are going to use this.

Yeah.

Um, you know, when it's released and, and on that, I'm actually almost done.

I, this time I'm going to say almost done.

Oh, okay.

All right.

So with, uh, Rigr, which is, you know.

Yes.

Yes.

Yes.

Yes.

Um, it, I did, I ported some features back in the Luxwander,

like upstream, but not all of it.

Obviously it's a whole different system.

So, but I took some crucial parts of it that were part of the building out the

different systems.

Mm-hmm .

Um, and so from there I was able to finally get an actual percentage of what's built

out.

Oh.

Yes.

Because I actually have a detailed, you know, specifications of everything that's

supposed to be in this slice.

Like all the, the, the promises that were made.

Right.

And.

Because Rigr gave you what the total spec should be.

Yeah.

At the end of the day.

So at least it gave you a estimated map.

Yeah.

And now you can genuinely compare against it.

Yes.

Yeah.

Before it was like, oh, well.

We don't really know, but now it's like, okay.

Like I, I don't necessarily know how long it is between certain things, but at least

there's some sort of list now that says, okay, 40 out of 45 objectives.

Yes.

Have been, you know, it's, it's feature complete.

Different items on the list may be weighted differently.

Uh, but I'm expecting that just having the number on a piece of paper.

Yeah, it's, it's better than just not knowing what's being made.

Yes.

So, so we're, we're about 95%.

Through.

I, I, uh, I, I love it.

How much is, how much is the weight on the last five percent?

Uh, if, uh, we trust Codex's, um,

uh, analysis on that, it would say, I think it was like

six to eight hours.

Okay.

Yeah.

Six to eight hours is, uh, in Codex land.

I mean.

Yeah.

That'll be like, what, two engineering months or something.

Yeah.

Um.

Okay.

Yeah.

Yeah.

So we'll see.

Um, it's been thankfully, you know, thanks to all the resets that have been

happening mid way and it's just been running ever since I, you know, set it on its

task.

So I was like, okay, I like, I check in and I see, okay, we're, we're actually

getting somewhere.

Um, and I'm really excited to actually use the rigor workflow more formally once

it's done.

Nice.

Yes.

Um, and I'm going to be trying to publish it soon, actually like the first alpha

version of it.

Yeah.

I do, um, want to get into that a little more, but before we get into the rigor, um,

piece, I do want to ask you, Andrew, I guess maybe the question becomes is maybe too

laid out for our audience.

Can you talk a little more about like, uh, the number of modules, what rigor gave

you, what you were dealing with earlier and like how it helped you reconcile?

Like what did, what were you expecting and what did you actually get and how did it

help you?

Right.

So I guess if I start from the beginning, when I started just using Claude Code and I

set out to build the project out, I knew from the beginning I needed different

modules for different features for at least from an architecture perspective.

But as we just built it out, I kind of just said, well, build it,

right, right.

Here's the modules.

One shot, go.

Build it.

Right.

Yeah.

And so as you remember, I scrapped all of that.

I quickly realized that that was a bad idea.

This was way too complex for something like that.

Um, it was a, you know, 30 page game design document.

There was a lot in there, a lot of different modules.

I think about 18 modules and I think, uh,

not everything is like in the first phase.

So phase one has like a certain amount of modules or a certain amount of features in

these modules.

And then if I may ask, so specifically we were looking at the game design documents,

it was saying that there would be nations, there would be guilds.

So it's kind of like a hierarchical, can you maybe talk a little more?

Yeah.

Yeah.

Just a reminder of you.

Yeah.

So basically the game mode or the server or whatever, it would be called a Minecraft

nations.

It was actually based on the very first server I ever made.

Um, and so groups of people will be able to join one of three nations and

from one of those nations, they'll be able to create guilds and you capture land,

defend territory towns.

There's going to be like a real physical money trading, not like, not like Diablo,

like, but in game, there's going to be like an actual gold economy, an in-game gold,

in-game gold economy.

Yeah.

And, and that money will actually, um, it's all physicalized.

So there's no like digital inventory, you know, you can't just open up your, uh,

thing and see like a number for your like little, like hottest gold or something.

Yeah.

You actually have to have it in your inventory.

We, we'll probably have a function to count what's in your inventory to kind of keep

that in line with your inventory.

So you're carrying gold with a modern take on it, but you still need the gold with

you.

So you're carrying gold.

You're carrying gold.

And you have to basically be able to account for that gold.

And that was also one of the modules.

Um, and I think that's maybe the thing is like, uh, we were talking about how the

nations existed, the guilds existed, um, the economy was its own module there.

And so there's all these, uh, features and capabilities that you're enabling.

Yeah.

Um, essentially when you had the game design documents, I read them more as

narratives, kind of like a narrative of explaining what.

Yeah.

The nation, nation relationship would be what the guilds relationship would be.

How guilds would be related to nations.

Um, I think there was some graphs also, if I'm remembering right back then, which,

so I, I akin to, I was, uh, uh, maybe relating those a lot more to design documents.

Yep.

I'm curious what, uh, rigor workflow has given you now.

Is it similar?

Is it different?

If I may ask.

So for its usage and Luxwander, it's not like a, I haven't actually

used rigor for, uh, for Luxwander yet directly.

Okay.

I only took some of the concepts while I was, I was like, okay, I like this certain

piece of rigor.

And that piece was the very specific and detailed part where it was like,

okay, here's the design documents now from this create a very specific

and detailed version of her spec sheets slice by slice.

Got it.

Okay.

So, so that way the, the work was both.

Um.

Yeah.

More portable.

Of course.

Right.

Yeah.

Uh, because that didn't happen the first time.

Yeah.

So, and because it's portable, there is many checkpoints of where we can see how we

completed.

Go and verify this is work actually done.

Can you check a few specific things like in the game open kind of maybe, maybe at

some point we haven't done that yet, I believe, but that could be, could have, could

be one of the checks you put in the future is like, as you build it, like, can the

game be like run kind of thing at that point.

Um.

Um, I, I think I was gonna jump into one question there as well as like, uh, it, it

is great to see that you're able to take slices and actually experiment with them

individually.

That's amazing.

Um, I'm curious, like, uh, in this thing we just talked about, what did the spec

sheet give you?

Was it more like just a checklist or just specifically like what, what was, what

were you looking at when it actually came out with a portable, um, spec?

So there is a lot there.

I would actually say before I say anything, we should just go take a look later.

All right.

Okay.

Okay.

I, I, I have meditated it so much and I haven't actually used the actual workflow.

I see.

Yeah.

Except for in a dog fooding way.

Okay.

So it is now, it is now successfully building itself.

All right.

Yeah.

So it's actually engaging the workflow, upgrading its own conflict files.

Okay.

Okay.

And stuff like that.

So it's, it's, it's kind of like you're saying that, Hey, Claude, go do the original

spec.

It gave you a bunch of stuff back then.

Yeah.

This time you're saying, Hey, go rigor, go do the same thing.

And now I can actually compare.

And as I go along at like, or don't like things, I'll actually go improve.

So maybe, maybe I'm putting the, uh, uh, cart in front of the horse a little bit

here.

Maybe we'll, maybe I'll, I'll give you an opportunity to, you know, release and, uh,

you know, and the alpha version and then we can talk about it more.

Yeah.

Yeah.

Once it's like actually done, like I'll be inspecting, um, and

critiquing those parts once I can actually see it for now.

So now it's like, okay, I can see based on things that it's working.

And there was actually, um, part of testing the first alpha for it.

There was like 18 different scenarios that we painted out.

Um, and we, Claude Code or Codex.

Right.

And basically created like a web store, um, that was able to, you know, save data,

you know, you could render it in a browser.

Right.

Yes.

And so there was like an acceptance criteria for each scenario.

Yes.

Yes.

And then running all of those different scenarios through it, did it accomplish it

or not?

That was one of the first ways we were testing the workflow to see if it was

actually working at all.

Because, you know, obviously waiting for it to work for Luxwander is just a big

task.

Yeah.

It's just a big project.

So I was just kind of like, okay, how can we have smaller tests where I can at

least, you know, get a result today.

Oh yeah.

And, and, and, and be able to visually see and like start up the web server.

Manually inspect it.

Say, okay, I see it's working.

Like I see it built this out.

I can see that it matched up to what we were looking for.

Um.

Exactly.

Yeah.

Absolutely.

Uh, that is actually, um, exactly what I was, uh, you, you answered my question.

So at this point that, that, that is precisely what I was, uh, curious about is

like, yeah, you're seeing a specification set along with like a specific acceptance

criteria kind of thing.

Yeah.

Um, software engineering land, you know, and, and.

But actually I'm, I'm having, I'm, I'm having my hands right now because that's

essentially, you know, it's very hand wavy.

Everybody has their own way of representing that.

Um.

You know, I think I've seen a lot of cases where it's a simple as saying that, oh,

this is a heading.

This is a short description as to what we're achieving.

And the acceptance criteria is when X user can do ABC and sounds very similar

at the end of the day to that.

Right.

Yeah.

Yeah.

Yeah, so, and the reason why I haven't said, like, what level, because I haven't

inspected the spec sheets directly yet.

Yeah.

Right, and so I don't want to say, like, well, I know how detailed they are,

but I haven't done, like, a line-by-line check yet.

Got it, and Claude is basically giving you an estimate based on the lines that it

generated using Rigger and what has already been completed so far, and that's a 95%.

So, for the 94 Luxwander, so that wasn't using the actual, like, Rigger workflow

again.

Oh, got it, okay, my bad.

Well, I went down this whole rabbit hole, and we, okay, my apologies.

Yeah, it is, I was talking about that for, like, those, like, scenario tests, test

scenarios with, like, the web store front.

Okay, okay.

I do not know about that.

That's an interesting one.

Okay, but we have been also, like, I am curious, Dennis.

It sounds like Rigger is being iterated on.

Yes.

It's getting better.

I mean, we're, it's already at first alpha.

Now we're doing, I'm doing polishing for first publish now.

What can one expect with first alpha?

Like, can you maybe point to three or three to five, like, feature capability

slices?

Yeah, yeah, yeah.

So, first, it will be able to ingest some

documents, design documents, right?

From that, again.

And you do, you, they're called assurance tiers now.

Assurance tiers, yeah.

And you'll be able to choose, you know, from one to five, right?

And one being the highest, five the lowest.

Digital handyman being the five, and, you know, NASA being one, like, expectation of

quality.

Yeah, yeah.

And then, so, let's say you choose three, and that's the standard, like, average

production.

Like, it's not dealing with money or lives or anything like that.

It's just, like, you know, everyday use, right?

They'll be good enough, right?

So, from there, that standard will be applied to how the model will

spit out the actual specifications.

Okay.

Because there's different levels of detail for each tier, right?

So, once it's, you know, puts that out, from there, it will use those specs

and actually build it out, right?

And then, from there, it will do a short review.

Mm-hmm.

Mm-hmm.

Because it's actually not going to be, the reviews are actually really short now,

because the first review happens on the spec sheets.

Okay.

Yes.

I, if, just a, just a really quick recap.

So, we're saying, basically, in just my current documents, my current plans.

Yep.

Figure out what I want to do.

Yeah.

Rate, would you be rating it?

Would I, if I'm the user, would I be rating it saying that the expectation is tier

one or tier two up to five?

The user is supposed to.

So, I'll give it my spec sheet.

I'll give it the tier rating.

Yep.

Um, and then, it'll basically go do a initial, um, generation of some specs.

Yeah.

And it'll do a self-review of those specs.

Yep.

And it will have that conversation with you.

Like, me as a user.

Yeah.

Yeah.

So, it'll have it like, okay, yeah, if there's anything to check over.

Mm-hmm.

Thankfully, the spec generation is actually specific enough so far in my usage of

it.

Mm-hmm.

That there hasn't really been, there's actually no need for review anymore.

There are review processes.

Mm-hmm.

Right?

Right.

And, like, short enough, I'm assuming once we get up to more complex things, it's,

we're going to run into hiccups because of context, maybe.

Yeah.

Um, but, like, the storefront and stuff, those have been validated pretty

straightforward things, I think.

Which, which is totally reasonable, I think.

From, uh, how would I put it?

The, you don't want to get too specific too early.

No.

Yeah.

It might be actually distracting and, uh, taking away from the ability to look at it

holistically.

Yeah.

Yeah.

Because right now, what I'm trying to do is, like, I've kind of learned from my

mistakes earlier with Luxwander, trying to get everything done all at once.

And this is Luxwander iteration two or three?

Oh, the, the, the, the project as it's going now, like, you know, scrapping all the

original code, right?

Yeah.

Um, I, I'm trying to just get it working as fast as possible now.

I, I want to see it play from A to Z.

Yeah.

And then I'll go back and start to critique it because I already had an idea, it's

all played out in my mind.

Like, I already have all of it, like, written out of what I wanted it to look like.

And basically I'm going to let it finish building out.

Then now I'm going to do a pass on actually critiquing each module, like working

through it.

And that's when I'm going to start looking at the specs, right?

Because I can see that the tests had worked, but now I'm going to be like, okay,

well, what's in there?

What is it missing?

What would I like it to be there?

You know?

Right.

, um, like for example, I'm like, oh, well, I remembered, like, for example, this

could be, this could be something I find.

I was like, oh, for some reason it's choosing the assurance tier on its own.

Let's say that I'm like, okay, that's not what I want.

And I wanted to be able to select it.

Yep.

Yep.

Because that is an explicit input that you want to gate.

So you don't get it to do too much work when you actually don't want it to do too

much work.

Alternatively, you want it to have a higher bar when it may not assume you should.

Yeah.

So, um, yeah, are you, are you thinking, so it sounds like it is a particular case

where because Codex is doing its own thing, it's going the goal oriented, you know,

solutioning that Codex can do, just ignore everything else is YOLO, let's go build.

Um, that sounds like it is doing certain things where you want to inject a more

specific, um, expectation at each phase.

And that is kind of like the part that's missing and you want to, or I guess, what,

how are you thinking you're going to solve that?

Well, well, I, again, um, like now that we're basically at first alpha,

uh, now it's when I'm going to start to manually review and work the process.

Got it.

So you're going to, you're going to feed it to rigor and then rigor.

I'm actually going to start using it and seeing, seeing where it doesn't live up to

my expectations and then I'll be able to.

Kind of like now is the dogfooding session now that you've, uh, you've been building

the main, you know, product for quite a while, which is a Luxwander, you know, game

with all of the nations and all the, oh, sorry.

What was the name that you gave it?

Minecraft nations, Minecraft nations.

And, and so you've been building that product for a while now.

Uh, you have, uh, now also recognize that there's all these learnings about how to

build it.

And that is essentially where rigor is becoming this, uh, solution to help build it

more effectively in a more organized way that you can track more effect, you know,

software engineering, life cycle almost as DLC style almost.

And, and, uh, the intention now is to start plugging in rigor and use it in a more

organized way.

Would you start using it in the remaining portions of the Luxwander or, uh, you

know, like, or in this case, I'll say Minecraft nations, or would you say that you

will basically

restart from scratch maybe?

Um, I'm definitely not going to restart Luxwander from scratch.

Yeah.

Fair enough.

Um, but.

We did joke about being like a hundred, 200,000 lines of code or something.

It's a, it's up to 600 now, but, but, um, yeah, I'm definitely not going

to restart that there.

I think like there comes a point.

There comes a time where, um, you just have to ship it.

Mm.

Right.

And at this point I'm like, okay, I'm not really worried cause I'm not shipping it

to like the public yet, but I need to start shipping it internally so I can start

testing it.

Right.

And so it's funny because I was doing so much work with

Luxwander and the workflow itself.

That's why I separated it out to rigor because I was like, okay, I'm iterating so

much on the workflow.

Yeah.

That now.

Luxwander is not getting iterated on cause I keep going back and say, oh, this can

be better.

That can be better.

This can be better.

This is one of the fun moments of when we talk about parallelization.

This is a valid case of parallelization in software engineering where you're like,

okay, we recognize there's a bunch of things we could get better at.

Should we stop our product development to do that?

No, no.

Let's just, let's just go do it at the side when, when it reaches a reasonable

version, a usable version, we will now pull it back in and then the next iteration

of our solution.

So we're not changing.

We're not building rebuilding from scratch.

We're the solution.

The workflow that we build has to accept an existing project or product and

essentially build on top is what it sounds like.

Yes.

Yeah.

So, so basically I've, I've ripped out everything that now from there, well, I guess

copied and that turned into rigor in a different repository.

So now they're both being worked on at the same time, but Luxwander has the older

version, the brainchild version.

Right.

So it's not actually running rigor because it's not implemented there.

Right.

But it does have its own version with some influences, like some key features that

I've extracted out of rigor.

Some unavoidable things that you were like, I really need this right now.

Exactly.

This needs to be there.

Just enough to get it going.

Yeah.

And then after that, I set it off to complete it because I was like, I was like, it

would take too long to integrate now at this point.

I'll do that on phase two.

That is, that is, that's very.

Reasonable thing to do.

I just bumped my mic stand.

So if you heard something, my apologies.

The, that is a totally reasonable approach.

And, and I think you can't fix everything.

No.

There might be things that if you fix a use, the benefit is so big or things you

just absolutely need to build confidence in what you're doing.

Yeah.

Therefore you will actually go ahead and implement it or pull it back in.

And that's exactly what I did.

It was like, it's like you kept asking me, how's it going?

Yeah.

And I said, I'm not sure.

Yes, that's fair enough.

And so that's, was one of the things, like, I would like to be sure of how long this

is going to take.

The confidence levels were low.

Yup.

But be from taking that feature out of rigor, putting it into there just like that

one piece.

Yes.

I was able to finally get an actual progress bar going.

Yeah.

And interestingly, I will, um, I'm going to digress just a little bit here.

Um, I think the thing I'm thinking about in this particular scenario is, uh, it

feels like.

Um, we have been talking about, um, Minecraft worlds as a

Minecraft nations.

Sorry, didn't mean to, again, I'm, I'm going to get used to that name Luxwander.

We've been talking about Luxwander as, as a project and kind of been focusing on it

from a, uh, 30,000, uh, more, more like actually 5,000 feet view.

Yeah.

So if I imagine if I use a plane analogy, um, I can see your mic is bothering you

there, but I, I can appreciate that, uh, I'm having the same challenge, but.

Yeah.

Uh, coming back to the plane analogy and, uh, the way you've been operating right

now has been actually very close to the code.

You've been watching the coding assistants do a lot of the work very closely and

tracking their work on a day-to-day basis, almost hourly basis at times.

Um, now it almost feels like you are pulling a little bit higher because you're

like, okay, it did this in these last few iterations.

These were certain behaviors that did not give me any confidence.

You, I feel like you've actually gone from, let's say.

5,000 to almost 20,000 feet where you're like, okay, what happened the last four

times?

And tell me now, uh, it's not an exact analogy.

It was just, this is just now.

Um, and this is sounds like there are certain things which you've discovered where

you're like for the next, you know, next few iterations.

I need this.

I just, I need this capability, even if it's being built in parallel and that other

project and the workflow, like in rigor workflow creation, there is certain things I

just need as part of Luxwander for me to build that confidence that we can actually

get there.

And, uh, this is, I think the plain analogy working out where you were, you were

monitoring mostly at that 5,000 so far, but now you're coming up and you're

observing that there's things going on in many places that I can kind of start

putting together.

So that is, that is really cool.

That is actually part of the also thing in software engineering and software

development, where at some point you must recognize that there may be parallel work

being done in two separate places that need to unify in a way and need to come

together.

Um, and I think those are things that really excite me, uh, because as an engineer

who has worked in large engineering teams in the past, uh, you know, repeated work

in slightly different ways is completely mind boggling and also very impossible

to maintain long-term is, is just not tenable.

It's just like things just change.

Like there's just everything.

Most of the ideas are the same, but then there's just like variations, just like

slight cracks going, you know, or slight branches going.

Yeah.

Left and right.

And, uh, in, in the two separate work streams.

And I think that's, that becomes really dangerous and unmaintainable and long-term.

So I think what you're doing now is awesome.

Like in terms of recognizing that there are things that could be unified now

providing immediate value while also, uh, being unified in the long-term and,

uh, providing a good value in the long-term.

So I don't know if that's what you feel like you're doing though, Andrew.

I think that is actually what I'm seeing.

Yeah.

I actually agree completely.

Like, uh, I mean, just from how I'm using it now, I used to kind of babysit like

the agent, right.

I'm like, okay, like, but now it's like, okay, it's, I, I'm confident that the

specifications were written out and detailed enough to actually get it done

correctly.

And now I'm just, just waiting for it to complete it.

And so essentially it's been coding itself for, you know,

maybe like two weeks.

Yeah.

Yeah.

Yeah.

Yeah.

Um, the, it's funny as I kind of zoom out more, I see

more bottlenecks, right.

And so now I'm actually in the process of kind of brainstorming a

kind of like automated orchestration layer that has my

objectives, broader objectives there.

So that way when something occurs at a lower level agent that, uh,

you know, broader agent would be able to actually redirect and push them in the

right direction.

Um, I, I really love the idea.

Also dangerous game where the, where the, uh, workflow basically becomes a project

at some point.

Uh, so, so I, I think I'm curious about like that part too, is like, there is a day.

I haven't, I haven't used it yet, but it's essentially just what I, what I'm finding

is like, I have a lot of different projects, right.

Um, I'm confident if I can become confident in the specifications and the

instructions, that are put to the models, which that's what I'm trying to do right

now is like, can I be confident that the instructions, the specifications being

written down are going to be, you know, you know, like satisfactory

to my acceptance criteria, right?

Like, will it come out the way that I want it based on the tier that you've selected

based on the tier that I've selected, right.

Okay.

Um, if I can become confident in that, then I can become confident, become confident

that that layer can then be automated.

Got it.

I see your point.

So, because so far you have let it do its work and you've been monitoring it

closely.

You've observed that it may say it's actually done, but it's not really done a lot

of the times.

And it keeps telling you things.

And then when you tell it, oh, this doesn't look right.

Then it goes back and there's no end.

There's kind of like that loop that's constantly occurring.

And at some point you get frustrated.

And at some point you're like, how do I now actually get it to truly measure?

What is an objective criteria?

And then how do I actually figure out if the, if, when it says it met the objective

criteria, it's meeting it or not.

So it's, it's a little meta.

We're kind of like saying like the confidence layer of the confidence levels, you

know, confidence on top of confidence.

But the idea is like saying that, can I figure, put some mechanism in place that

lets me let it go with a high level of confidence and meaning that let's say 80% of

the time, it'll get it right.

Maybe in the future I get, I figure out why that 20% is failing.

I go from 20% of the time.

And from a 20% failure rate to like, let's say five.

So then eventually it'd be 95% of the time.

I just let it run with enough information and it's doing it correctly.

I interestingly, I think I've actually experienced a lot of this in my own personal

projects.

And it's like, there are these iterations where I will run through and be like,

okay, I'm going to go, I tell it to go spawn up sub agents, do work in the sub

agents.

And interestingly, the orchestration layer that you're talking about is essentially

something I've been playing with just directly in cloud in this case.

So I'm telling Claude, Hey, you are the main orchestrator, go spawn up the sub

agents, get, give them the right information to go do the work.

When they come back, I want you to verify and tell me if they've done their work or

not.

And then, excuse me.

And then explain to me what that, what that, you know, proof was.

I'm curious.

I, my experience from this has been relatively good because Claude will actually be

like, oh no, I didn't actually do everything at times because the sub agent will

have less contacts.

Sometimes it.

Uh, will not have everything it wants.

And then the parent orchestrator will recognize and do a little better next time.

Um, that is, that is kind of like one approach.

I'm still trying to figure out how to extract those learnings out of that one

orchestrator session and make it more usable across different sessions.

Um, which is, which is interesting to me is because I'm hearing a lot of the stuff

you're building.

The workflow you're building is very exciting and sounds very like, like it can do

what really, like what a lot of people.

Are hoping for, uh, in my opinion, uh, I'm trying to figure out, um, in your

mind, do you feel like this is something that maybe is still like focused on games

at game design?

No, no, absolutely not.

Uh, for rigor as a workflow is meant to be project generic.

Okay.

And it's, it's supposed to be able to, so once, like, I think, I don't know if this

is in the current phase.

I don't remember, but there are multiple phases for rigor and there'll be different

layers of customization.

Okay.

Yeah.

So it's at some point there's going to be like, literally like when you're

installing it, it will ask you certain things to customize.

Okay.

Um, the, the, the workflow.

Is, is, is this already there right now in the alpha you were thinking about this

for the future?

Um, I don't think it's, I don't think it's in the current alpha now.

Okay.

Okay.

Yeah.

It's there's a lot of features.

We'd like to get everything done.

We'd like to boil the ocean, but you know, we are reasonable.

And the only reason I say that is because I haven't like focused on it at all.

So I'm going to assume it's not, I, you know, I'm, again, I'm, I'm, I'm raising my

arms here.

I'm telling Andrew.

Yeah, I totally agree.

I totally, totally can understand.

Uh, we would love to do everything, uh, especially with the eye.

We feel like we can do everything.

Um, but we need to be reasonable and like pick one thing at a time.

So I guess that is coming back to it is, um, in the current effective state, what

would be in your mind, the alpha, like what is a killer feature?

What is it doing really well?

Because I think we talked a little bit about this previously.

The tiers is something I love the concept of, uh, where are you at about like, Hey,

this is something that most individuals probably run into when buildings they're

like projects.

I maybe not even forget software.

Just you're using a digital handyman.

You're trying to do something in particular, you know, like, uh, Claude Code is your,

uh, is your like, you know, software engineering, uh, you know, AISs.

And, uh, Codex is your digital handyman.

They can do things, but rigor start using rigor with them.

And all of a sudden, this is one thing you will see that is very helpful.

What would you say is that very helpful piece in your mind?

I'm putting you on the spot here.

So I, yeah, no, I, I think I, to be honest, it was the part that I extracted for

Luxwander.

Right.

It is, it's actually building out the specifications to the level of detail where

review cycles are not as relied upon.

Because what I found when I was working with Luxwander without this workflow, right.

This little piece was again, you saw like, oh, this is round a hundred for review.

And I thought to think to myself, well, there's got it.

Why are all of these gaps here?

A code review.

Code review is what we want to be very specific.

Yeah.

There's a hundred rounds of code review amongst multiple models.

And I think we've talked about this before, but yes, code review.

Yes.

That's a lot.

Yeah, no, that is a lot.

And I was like, that actually took longer than generating the code.

Mm-hmm .

Well, significantly longer.

Mm-hmm .

And so I guess it's obvious looking back now, but I was like, okay, well, how can I

shorten the rounds of review?

Mm-hmm .

One way to do it was to be more specific on how to fix it.

Mm-hmm .

Or I give me more specific on how to make it.

Mm-hmm .

And so.

Better discovery upfront.

Yeah.

Yeah.

So now I'm front loading the kind of effort to the actual generation

of the specs.

Mm-hmm .

Before it even touches any code.

Because it's a lot cheaper to generate a few, maybe a dozen documents, like each

being about two or three pages versus 600,000 lines of code.

Yep.

And so essentially it will build out all of those contracts.

Yes, Scott.

In this specification.

You're talking my language now.

You're hitting contracts.

Yes, Scott .

And there'll be different slices for the actual features.

Nice.

Nice.

And then the modules.

So now it's like there's three layers now of it's actually building

out those things individually.

Not even in code.

Mm-hmm .

It's just for specifications.

Awesome.

And so that's where I get the confidence.

Mm-hmm .

And then there's also when you do the review, there's actually something to look at.

Before.

Before.

Yeah.

The code was even written that it's supposed to be there.

Yes.

So now it's like, okay.

The review is like, okay, unless there was like a coding error that the model did,

which doesn't really happen too often.

It doesn't.

No, not anymore.

Yep.

So it's a specification errors happen a lot.

Yes.

Yeah.

So as long as it has the right context.

Yes.

It can write it correctly.

And I think you're really hitting on the right points because I think the more

specific you can be about the ask, based on all my experience, based on all my

readings and everybody else I've talked to, the more specific you can be about the

ask.

The more specific you can be about the task to the model, you know, Claude Code,

Codex, Gemini, whoever it is, some are going to be better than others regardless.

But the more specific that you can be upfront, the better job it will do.

You can one-shot things as long as your one-shot is so detailed that there's very

little left to interpretation.

I'm not sure if that's necessarily the case here, but it sounds like at least that's

a direction this is starting to drive towards.

And these primitives, now that you're establishing the primitive of a contract, the

primitive of a feature and module.

I'm sorry, I might have butchered the slices, the feature slices.

Yeah.

Okay.

So are you calling it slices or features just for my own sanity?

I am calling it slices, but they're meant to be, each slice has a different feature.

Got it.

So you can have like a single contract and have multiple features under it maybe?

Or is it hierarchical at all?

It's a slice can have several contracts.

Okay.

Got it.

Absolutely.

And then the modules, you can have multiple modules as part of a single slice.

There are multiple slices make up a module.

Got it.

Okay.

So I flipped it around.

I'm going to turn that tree upside down in my head.

So got it.

Absolutely.

So you have the module.

The module has multiple feature slices or slices in particular.

Each slice may have one or more contracts that help essentially execute or provide

that capability, the features capability.

Yeah.

That's awesome.

Like these primitives, I do feel like are a great way to at least start

conversations.

And in this case, a conversation with your coding assistant.

Again, in my history.

In my experience as a software engineer, that is what we were talking about as like

coming kind of circled back to the YouTube video as a individual contributor,

as a software engineer and not a manager.

Really the only way, in my opinion, not the only way, but one of the easier ways

that I have found personally to convince others and get engineers like human

engineers to actually get excited and then build something really awesome is to

start with a common set of primitives that we can all align on.

Right.

And then once we have that common footing, how do you then explain when you put

these things together and you start putting those Legos on top of each other, you

know, is going to create this awesome thing.

Absolutely.

And I guess I wanted to expand on like the slices and the contracts a little bit.

Absolutely.

The reason why I kind of directed it that way was because I was finding that during

the reviews on the original versions of the Luxwander that was having all those

troubles with all those rounds of review.

Mm-hmm.

Mm-hmm.

Was every time it did fix something, it broke something else.

Mm.

And so that was leading to the The regression.

Infinite loop.

Yeah.

The regressions led to an infinite loop disaster.

Right.

It did eventually finish it.

But how many days of tokens that I waste to get something what I thought should have

been rather straightforward was not.

Right.

And this is obviously when you're dealing with a module that has like over a hundred

thousand lines of code.

Mm-hmm.

And so there needs to be like, I was like, well, how do we, how do we fix this?

Right.

And so each slice is isolated for that feature.

Another word that I love.

Yeah.

Absolutely.

Isolation.

Woo.

So that way, if we need to update that feature.

Mm-hmm.

It's only going to mess with that component.

Mm-hmm.

That slice.

Mm-hmm.

Those contracts in that slice.

I love it.

I, I mean.

Mm-hmm.

Mm-hmm.

Andrew, you've heard me talk about it, you know, isolate things, paralyze things,

create the contracts.

Oh my gosh.

Wow.

All right, here we go.

And yes, those slices have been built in like intentionally.

I've been specific about it, that it needs to be able to be paralyzed.

Paralyzed and in the slices.

Yes.

Those slices can have an individual agent working on each one.

This is exciting to me and for very specific reasons, because I've actually used a

lot of open source libraries for spec driven development.

We've talked about GSD, OpenGSD now a few different times.

I will not say the whole word because we might, you know, we might get our podcast

taken off the air from Apple again.

So the idea there that I really loved was creating specs ahead

of time, doing some things.

So there are open source libraries that do this.

Parts of this.

What Andrew has just mentioned though, I think is a very clear distinction is how do

you break up a larger problem?

How do you actually then create into different tiers and like tier?

Based on like what level of, you know, accuracy you need?

Like, you know, error rate needs to be really low.

And then based on that tier, how do I actually create a broken down problem?

Multiple modules, multiple feature slices, multiple contracts as needed in order to

achieve that?

I mean, I guess I will say this Andrew, just to keep ourselves honest and just to

keep this honest as we are, it's an alpha.

So there's clearly, there's going to be some work here in refining that.

I think I'm really excited by the concept of that because instead of it just saying

that.

The other approaches I've seen, which do really well, they, they,

they, I feel like are a little more still on that 10,000 foot level in the plane

analogy.

And they're very focused on like certain capabilities.

Once you start getting into that 20,000, 30,000 feet, I feel like they've kind of

fallen down for me a little bit where they start creating so many slices and that's,

they're mostly doing like phases of implementation.

GSD in particular does phases of implementation.

At some point, I've got too many phases, I'm losing track and things are getting too

like untenable.

Again, that is where I do feel like this approach of like, Hey, I have a module.

The module got completed.

The next module is also there.

Now I can match the, figure out the relationships between them.

That I think scales better when you look at it from like that 20, 30,000 feet.

And I, I have had to do the modules.

I've had to do the, you know, feature slices in my head and work with like different

cloud sessions.

So I'm definitely excited too.

To hear about this and like actually try some of this out.

Yeah, very excited.

Absolutely.

No, I'm excited too.

And I, I think it's close.

All right.

Yeah.

I mean, it already, the first alpha is, is ready now.

It's just kind of like, I am, it is like, it's already been tested.

It does work because of the scenarios.

Now I'm just trying to go back and fill the gaps so that I can start confidently

using it essentially.

And I think the, the thing I will maybe ask and hopefully we can work through this

because, as I said, this is alpha where, where there might be a million things we

want to do.

We want to boil the ocean.

We can't necessarily do it.

Yeah.

This is not trivial.

I think the question is again, like you are very specifically saying the capability

is spec building, you know, building that is the most important part of this yet

to start.

Right.

I think there might be other interesting things, which even I'm like, I have talked

about a few other things.

I think getting the start getting the correct starting point, getting like that

really good footing.

Yeah.

I do a hundred percent agree.

That's really important.

I am also curious, like how we can, you know, get to the next

phase beyond that with rigor.

And I think that's going to be the curious part of like, would you, may I join as a

contributor is, you know, I've got a few interesting questions and a few interesting

hypotheses myself.

So I think I have some, if you, if you don't mind, maybe I'll, you know, give it

some of my own flavor.

Yes.

That's part of the past I'm doing now as I'm adding like a security.

Contributing.md so that I can actually open it up.

I like, I want to be able to, I'm going to try to create something small with it,

like as a, as a bigger test scenario, something that like those test scenarios were

made by Claude Code or Codex.

I'm actually going to write one out on my own.

So I know the product from, you know, from the very top and bottom, then run it

through the pipeline and see where the gaps are.

Mm-hmm.

Um, and from there.

Yeah.

I'm going to publish the first alpha.

Awesome.

I, I, and I think I'm excited.

So don't take too long, Andrew.

It's funny.

I was, I was, I'm going to try to get it done today.

Actually get it done today.

Oh, it's actually, there is a part of it is being run on right now.

Um, and behind the scenes.

Yeah.

It's already, I've already identified all the gaps that after this first alpha.

And so it was just planning out specifications to be able to patch all that.

Awesome.

I, I, and that is basically patching potential issues in the workflow right now

as part of the original alpha.

Yeah.

Uh, so would we say, what can we say is like zero point version 0.1 kind of idea?

Yes.

0.0 right now.

And maybe you're creating 0.1.1.

Yeah.

Yeah.

Is that true?

Yeah.

0.1.1.

0.1.1.

You know, that's, that's, that's the version.

Yeah.

And it's just like with any kind of like.

AI coded project, just because you wrote it down, doesn't mean it remembered to put

it in.

Oh, that's true.

Yes.

So you got to go back.

That's why I said earlier, I was like, I'm not sure.

Okay.

Because I remember thinking about it, but I don't remember if I wrote it down in the

specs.

Absolutely.

Absolutely.

And, and it, I haven't been focusing on user runtime right now at all.

Yeah.

Cause it's like, I'm not publishing it yet for people to use.

I'm just like, I'm trying to make sure that the workflow works.

Then we can put the scaffolding around it, like a Docker image or something like

that.

So that it's easily portable and deployable right now.

It's like, okay, it's kind of like it works the way that it made it.

Absolutely.

I'll make it portable and deployable later.

I mean, or somebody else.

That's true.

That's, that's the idea of like bringing in contributors and having multiple people

look at it.

I think in one of the conversations we had previously was how do you go beyond one

individual?

How do you scale beyond one individual?

And then being like, you have your own individual project being built right now.

Yeah.

How do you now let others into the room and kind of start working together on it?

I feel like we have kind of played, played on this already.

Like, I think as part of the podcast, we have like the audio mastering project that

we have on our own private repositories intentionally because it is, it is rough,

but it is an intentional thing for our system.

So we can essentially do the audio mastering for this podcast.

I am really excited to maybe try a private version of Frigger.

And, you know, maybe I can have my own Flare and have my own commits and send you

some pull requests, you know?

Absolutely.

You can poke all the, poke all the holes.

Poke all the holes.

Or maybe the holes are there just to walk in.

Yeah, just, just walk in.

The doors are already open.

Um, no, and I think I, I love the idea of this super focused approach of like, uh,

my alpha, my first version might just be spec or at least for now we'll focus

entirely on that.

And I think the concept of tiers, as I said, I'm super excited because there's a lot

of, a lot of depth that we can jump into just there.

That is a whole nother topic.

Do you want to, do you want to jump into that?

Sure.

Yeah.

Because that's, that's maybe just, just to kind of preface for our audience.

We are talking about a, a different kind of tool altogether.

We're not sponsored yet, but we're open.

Love it.

Love it.

Let's let's wait.

Okay.

Okay.

Blacksmith.

If you're hearing this now, but yeah, please, please.

This is a different topic, but yes.

So essentially there's, you know, I have rigor connected to my private repository,

which it's already, I believe, run through GitHub actions a few times.

I hadn't started doing PRS until about the first alpha, because

I was just in such a deep, just tearing everything up mode, like reorganizing

everything.

I didn't think it was going to be beneficial to have to check everything every five

minutes.

But now that I'm reaching that first alpha stage, getting too close to one, I'm

like, okay,

let's start doing PRS.

Let's having the code get checked.

Let's actually have, you know, the linters run, the CI running,

but, GitHub actions and

it's internally built one.

It's actually quite slow.

Yeah.

And so Blacksmith, thankfully, apparently they're, this sounds like a giant

advertising now at this point, but, but it was really beneficial to me.

Blacksmith, did you listen to that?

It was really beneficial to me because what I found on the Luxwander workflow was

that, you know, some builds were taking like 20 minutes.

Yeah.

Yeah.

And when you're coding with AI, 20 minutes of waiting for that build

is a long time.

Maybe 20 minutes wasn't a lot before, because it's like, okay, I can, I can look at

another ticket and reply to something on Jira or something like that.

But now it's like, okay, that 20 minutes is pausing development.

Yes.

Because we need, we, we, we like.

As long as you have the tokens.

Yeah.

Yeah, exactly.

As long as you have the token.

So now I think fast CI and paralyzed CI in particular is actually probably

going to be a critical part of agentic workflows.

Yeah.

In, in, in.

Just in general.

In general.

Wow.

Well, it's because it's like.

This does sound like an advertisement.

Well, yeah, it does.

It's, it's because it's just the speed of work is now being bottlenecked by that

now.

I, okay.

I, I see your point is more the idea of like, when I do my deterministic checks, the

deterministic checks, if they start taking too long, it is painful.

Yeah.

This is, this is not new.

In my opinion, this is something that has existed for a long time.

There is a reason Blacksmith exists and is a company that has gotten interest and

is, is I think something that I've also heard a lot about.

And I, I think there's a really, really good reason for this, especially

as we start building more repositories.

Building more projects.

And then we start expanding on those projects and we getting like really in depth.

I will also maybe mention a little bit that the Luxwander project, the

Minecraft, you know, Nations.

I, I will get that sometime, sometime at some point.

Project is fairly large.

I, I believe it is again, not only code wise, but I think it's also Java.

So that typically does include more of a compilation element does include some

additional like work.

Yeah.

That needs to be done to run the test, run the deterministic stuff.

I think I'm also curious if you ever moved to a different language, let's say, you

know, I'm not saying Python's fast.

Python is an option because it's interpreted.

TypeScript is an option because again, you don't necessarily need to compile or

doesn't do the same amount of work when you do it even.

So I, I think the Rust is another one, which is very, very performative.

The question becomes as well as like,

I'm, I'm not, maybe I'm just winding back that advertisement part here, but, but I

still feel, I agree with you.

There are these languages are still super popular.

Like Java is still very, I, I used a Java forever before I moved into Python heavily

last year.

So I think I totally agree with you that, you know, reducing the amount of time for

deterministic checks.

Absolutely.

Absolutely.

Yeah.

Yeah.

No, I mean, I think that helped a lot and that's actually part of the rigor workflow

as well.

It there, I've specifically, you know.

Okay.

It included specifications in rigor.

Wow.

All right.

That it needs to plan out the tests in ways that it can be paralyzed.

Oh yes.

Yes.

Oh, okay.

I, I, I like that a lot.

I like that.

Yeah.

Because that was what I ran in with Luxwander.

All of the, a lot of the tests were some of these modules.

I didn't think of that.

I did not specify that these tests needed to be paralyzable.

So guess what?

Everything was built in the way where it was all serial.

Yeah.

And that's why it was like, okay, I added four more cores to this test.

So you think it's going to go faster.

Nope.

Nope.

I just spent twice as much money for the same exact speed because it was bounded by

a serial process.

Yeah.

I think, I think there's another very specific use cases.

If you were ever dealing with audio, if you're ever dealing with video, um, trying

to paralyze they're, they're inherently expensive, uh, to do processing on, to do

tests with, because if you want to do a real time kind of test with like actual wall

clock based tests for some kind of audio or video stream, right?

Like you're trying to be like, oh, wall clock.

It has to follow wall clock.

And I have to verify these things happen during that wall clock execution.

They are sequential.

They're all, they're all happening, you know, on a single thread usually.

So trying to paralyze those is very, very improved performance massively.

And I, I've had my own personal experience there that, you know, a questions I would

always be asked in one of my previous jobs was, uh, can we do this?

Can we just have more cores?

Can we just paralyze it more?

And, uh, I was like, no, not yet.

We need to change the way it's built, uh, because so we can actually paralyze the

work.

And, and the, this was such a big headache for me on the Luxwander workflow that I

actually spent like a few days reconstructing the tests so that it could be

paralyzed.

And so it went down from like 26 to 28.

Now it sounds like four.

All right.

Which is much more acceptable.

That is way.

Yeah.

That is a seven X, you know, improvement in our, uh, the execution time.

Yeah.

I, I would take that.

And that's why I'm like straight into rigor before we start building anything, build

that with this in mind.

Yeah.

Obviously it could have been just way faster with maybe Python and like, and the

other languages you mentioned, but since I've been using Java to me that this, this

issue is like really big since it's been slowing me down.

Yeah.

So, I mean, I mean any Java developers, you know, out there here at first year, you

heard it here first rigor has this in mind first, you know, rigor is built with

Java.

So where it can, the tests will be paralyzed.

Absolutely.

So, so that way, you know, you can actually take advantage of those additional

cores, speed up the workflow because I didn't want the PRS

and the deterministic checks to be

a bottleneck.

Oh yeah.

Because another thing is, I think that's going to be a big thing, especially, you

know, like you were saying, when you start adding other people.

Working on the same project.

Yeah.

Yeah.

Right.

It's like, imagine if everyone was had a 30 minute merged.

Hey, I, I was the one who added the 30 minute, like 10 functional tests, like in the

past and none of my teammates enjoyed that.

So I can tell you for a fact, I learned that firsthand.

They're like, oh, huh.

Yeah.

All of a sudden all these, these PRS are taking a lot longer.

Yep.

Yep.

They're like, why are my functional tests?

Like what happened?

It's like distance.

Yes.

I did somebody break something.

I was like, no, this was intentional.

It's like, let's go back and do it.

And I was like, ah, not for, for quality purposes.

We cannot.

So yeah, yeah, no, a hundred percent.

I, I genuinely do think it's one of those things where the developer experience

degrades.

If you don't figure some of these things out and the minute that the developer

experience degrades a velocity, you know, falls through the floor.

I think that's why there's such great value, especially, especially in the AI.

I actually think that it's your AI coding assistant.

Don't use it for anything else.

Use it to improve your developer experience.

Just, just go do that.

And all of a sudden you'll see that all of the things you're putting off for years

and years are going to make your developers so much more motivated.

The engineers are just going to be like, oh my God, this, this used to take, you

know, two hours.

Now it takes 10 minutes.

Yes.

Let's go.

And that's just going to improve productivity in its own way.

And sometimes these little things make a huge difference.

Yeah.

But, but it's funny, I just remembered, um, we were talking about isolation the

other day.

Oh yes.

Okay.

This is another topic where we are.

I will, I will put that verbal cue.

We are changing topics here a little bit related.

It's actually still related to rigor.

Okay.

Related to rigor.

Okay.

Yes.

And so I went once, once you started talking to me about how you do your workflow.

Yes.

I thought about, okay, maybe this is really common.

I see the benefit potentially.

I'm going to build this capability.

And from the get go.

Which part of my workflow Andrew?

So rigor can actually manage in the workflow, multiple repositories

at the same time and sub repositories, there's some modules built in.

So it can orchestrate across those bounds now.

That's that's.

And still, I was basically like, it can still be one project.

So take my money.

I put that in first.

I was like, okay, like.

I see the merit.

I'm going to add this in from the beginning because I thought like, this is a pretty

big architectural decision.

Like this might mess some things up.

Yeah.

I think especially when dealing with spec generation upfront, how do I know which,

where that spec applies?

If I am multi multi-repository, which I think a lot of organizations are and a lot

of individuals I am, I mean, maybe, maybe I'm crazy.

I I'm not the monorepo guy.

There is a whole, there's a whole thing about like monorepos out there.

So there's probably.

Monorepo developers out there who are going to be like, I don't care.

What do you, what do you, why do you, why do you care about that?

You know, get good, you know, or something.

And I'm going to be like, no, no, I am.

I am multi-repo please.

Like my deterministic checks never fail.

Yeah.

And they're super fast.

They're already paralyzed.

We're not checking anything.

It's already perfect.

My intuition.

I, I think, I think, uh, I, I personally feel that way.

There may be other trains of thought.

Um, though I will still say this, even if you're doing monorepo, if you have a

dependency you're pulling from, let's say that you actually needed to make a change

in some kind of crypto cryptography authentication library that you're using, that's

managed by your company or that you want to be a contributor in.

Yeah.

The minute that you start dealing with any of those dependencies, you have to pull

that repo in as well to understand what it's doing.

And then you can actually build a spec sheet on it correctly.

If you assume that you're going to be able to build a single spec sheet to make

changes that are cross, uh, repo, uh, good luck.

Well, we'll see if Ricker can do it.

I, I, I mean, just, just pulling the repos in, I think starting there is important.

Yeah.

But yeah, it, it, it is now aware that that could be a case of it needs to work

with.

Yeah.

I, I, and I'm excited to try it for that reason.

And I, uh, yeah, I am personally, um, I like to manage my things by splitting them

up.

Yeah.

Organized units.

Uh, each module, ideally the way I would build it as each module is its own repo.

If it's big enough.

If there's a logical separation where you do multiple modules in one repo, totally

makes sense.

If it is like they're logically grouped together, if I'm doing like 10 things in

authentication, I'm not spending up 10 authentication repos, but if I'm building 10

different business unit kind of capabilities, like I would put economy on its own, I

think in this example of Luxwander, I would put it because I might even reuse the

economy module in the future.

Let's say for a different iteration.

Yeah.

And maybe phase two, we, we might just refactor it, build it that

way because I think for long-term maintenance, it would benefit greatly without

having, you know, collisions happening everywhere.

Once we change something.

Um, I will also say I, this is a slight form of over-engineering.

There is definitely an aspect of like, you don't need to do this if you're trying to

solve a simple problem.

I don't know.

600,000 lines of code.

Okay.

Phase one.

Yeah.

See, that is not a simple problem.

That is not a simple problem.

I'm beginning to see it.

I was like, okay, because when you explained it to me, like last week, I was like,

okay, if you change something within here, it's not going to affect anything else.

Yeah.