If coding is "solved," is software engineering? Ajay Medury (software engineer) and Andrew Sierota (systems engineer) pick up where Episode 1 left off and get into the part that isn't solved: judgment. They trade notes on why weekly usage limits have quietly become the real project budget, what it's like to build a sharded Minecraft world solo as both product manager and principal engineer, what Amazon's New World got wrong about scale, running decorrelated multi-model code reviews, and what an AI "skill" actually is. It might all just be an act of intelligence.

In this episode:

• Why "coding is solved" but software engineering isn't, and why judgment is the expensive part
• The new bottleneck: weekly subscription usage limits as a hard budget
• Breaking a big build into modules and submodules, and shrinking scope to actually ship
• Wearing every hat at once: product manager and principal engineer
• New World and the problem of scale at launch
• Large codebases, heavy test coverage, and review rounds that exposed process gaps
• Pre-flight checks, linters, and spec-tracing that cut review loops down
• Decorrelated reviews: several different models reviewing blind, then taking the union of findings
• What an AI "skill" is: system prompts, user prompts, and guardrails for long workflows
• Severity tiers for findings: blockers, warnings, defers, suggestions, and nits
• Why systems admins, as generalists by trade, may be an ideal audience for these tools

Chapters:

• (00:00:00) - Real intelligence, or just an act?
• (00:01:02) - Coding is solved; software engineering isn't
• (00:02:02) - Keeping up with the release pace
• (00:05:27) - Vibe coding vs. a repeatable process
• (00:06:40) - Usage limits are the new budget
• (00:08:40) - Breaking the build into modules
• (00:12:18) - A sharded world, every hat on one builder
• (00:17:12) - New World and the problem of scale
• (00:25:04) - 200k lines and a 90-round review
• (00:27:20) - Pre-flight checks that cut 90 rounds to 5
• (00:30:49) - The podcast's own local-GPU pipeline
• (00:33:27) - Learning by asking "what do you mean?"
• (00:35:35) - When a large agent run burned through the budget
• (00:38:05) - What is a skill, really?
• (00:48:05) - Skills as guardrails for long workflows
• (00:51:09) - Severity tiers: blockers to nits
• (00:54:34) - Why sysadmins are ideal builders
• (00:56:29) - A long-running Minecraft community, the real driver
• (01:00:56) - Closing: an act of intelligence

Hello, my name is Ajay Medury, and I'm a software engineer, and today I'm

joined by...

My name is Andrew Sierota, and I'm a systems admin.

Awesome, and today we are here to talk about various topics

in the AI ML space for a podcast that we have coined

Active Intelligence, because we're trying to figure out if it's real intelligence or

is it just acting?

And this podcast is for all aspiring creators, creatives, and

builders.

Or those who have already been doing it for a while and just are looking for new

tools and maybe ways to improve their workflows.

I'm curious if, you know, one of the things we talked about last time was

particularly like, you know, software engineering, writing code might be a solved

problem, but is software engineering the solved problem?

And I think, yeah, I was curious.

Yeah, yeah, picking up where we left off on the last episode there, I remember us

saying that coding could be solved, right, but software engineering definitely

isn't, and I think I was touching on this while we were chatting just before the

show, you know, coding is basically, you know,

Claude can write code all day long, faster than anyone can

humanly.

Mm-hmm.

It'll figure it out if you give it enough time, enough tokens.

Oh, yeah.

But judgment isn't free.

Yes.

And that's where humans are still very valuable, is judgment.

And that can be really expensive.

It could be a really expensive mistake if you have poor judgment on the usage of

your code.

And talking about that in particular, here's like bad judgment in terms of

accidentally putting a vulnerability out there that could now all of a sudden be

discovered by models much more easily.

The cost of that is pretty intense.

Yeah, yeah.

And I don't remember what the, that, there was the project that Anthropic did with

like the 30 big companies.

Yes.

To like the pre-release of Mythos.

Yeah.

And they were supposed to like patch everything, supposedly, before they released

Fable.

Yes.

Right.

That's funny, 4.8, Opus 4.8 was only released like two weeks ago.

That's.

And then less than two weeks later, we have Fable now.

Three days later, we don't have Fable.

Which is really interesting to me because traditional software engineering took a

lot more time, had a lot more rituals potentially.

And, you know, again, we kind of broached the subject last time is, were those

rituals still meaningful?

Like, do those still make sense to do today?

Like, because I can't even imagine a time like four or five years ago where you'd be

able to release a, you know, pretty significant version and then release the next

major version within weeks later.

I think you'd be waiting months between these kind of releases.

So.

Yeah.

Kind of, kind of hard to keep up with, to be honest.

You know, there's, there's so much changing so quickly.

By the time this is released, you know, who knows what would have changed.

Yeah.

Yeah.

I think that a lot of what we're doing now, and I guess

something that I've done, like, obviously the world's changing every day.

There's new tools, you know.

It's hard to, you know, want to use the latest and greatest all the time.

Yes.

And, but also keep adding new requirements.

To your project, right?

Yes.

Because, like, there was a point in time where in the, my Minecraft project right

now, I was just adding so much stuff because I was like, oh, yeah, I like this thing

can code everything for me.

Oh, yeah.

That's no longer a limit, but then once I started to get to, well, is it going to

work, right, there's just too many things to check.

Yeah.

And, and I think I remember last episode, I said, I think, you know, testing would

be 10 times as much as the production.

Yeah.

I'm actually thinking it's going to be 100 times more than the development now.

Yeah.

The realization is now dawning.

It's like, oh, no, this, there's a lot more.

I gave it the ability to build all this stuff.

The time it will take for me to now validate that, yeah, it just feels.

It's going to be a lot.

Yeah.

Yeah.

And I think that's the interesting part is because back when, back when I was in my

previous company, we were a cloud company.

And so we were trying to launch systems for others to use.

The expectations there were always like.

Let's maybe be a little more restricted because if we can restrict the size of the

system that we're like actually shipping out there, we can maybe do a better job of

building it and reduce things like risk, which is I'm imagining a question that

Anthropic is asking right now is what is the risk of actually releasing this model?

So it becomes a similar question.

I think we had, we had those kinds of conversations all the time where it's like,

all right, do we actually do less intentionally?

And the answer at times was yes.

Yeah.

We should do less intentionally.

I don't also think that always applies towards other kinds of systems like our

projects, right?

I do feel like we were briefly talking about this before the podcast about like, oh,

what is, you know, like, what does software engineering look like versus vibe

coding?

And there is definitely a good number of things I can bring up when I start talking

about it.

Though I do want to say like one distinction we kind of were, maybe we liked the

idea of it is software engineering.

Like in the big tech companies, like a well-oiled process, it's a repeatable thing

that they keep repeating to keep, you know, churning out new features, new products

and so on and so forth.

However, I do think that the vibe coding and more like, you know, building

locally, building a system today, like a lot of engineers who do it outside of the

big tech, I feel like it's more like a project where the project is something you

kind of figure out how to execute the project as you go along.

There isn't just an answer for every single thing.

Like you don't get told like, oh, this is where you, you know, release the code,

this is where you talk to next.

You know, you don't go step one, step two, step three with the actual like new world

of building systems, building like projects.

I do feel like there's a lot more variance.

And Andrew, it sounds like, sounds like you're kind of experiencing some of that,

right?

If I'm getting, if I'm getting it right.

Well, absolutely.

And it's funny, like, like in enterprise, you have budgets, you have deadlines, you

have a boss who's breathing down your neck.

Yeah.

Yeah.

But, but when, when you have your own project, all of a sudden, the bigger

limits is, especially when you're not paying for API, you're paying for a

subscription like ClaudeMax, CodexMax.

The biggest, the next big limit is your usage every week, your usage in every five

hour window.

And that's actually the budget now that I'm working with.

Like, like I have to calculate, like I got a 20 X max subscription for Codex and

Claude.

I can use that up a weekly limit in two days.

And I have two subscriptions.

So I can code for four days a week.

That's your budget.

Yeah.

That's my budget.

And, and then I have to think, well, that's just testing, reviewing the code.

And I haven't even really reached the stage where I'm doing practical tests.

Yeah.

Yeah.

Real, real world.

Yeah.

Yeah.

And so that's why I said, I'm like, wow, even with this process, I'm going to be

able to do it.

But as I'm practically fully automated now, it's still going to take a lot of time

because budgets aren't infinite for most projects.

Yes.

Yes.

And I think that's the idea of like within this budget for this project, how can I

actually figure out to execute the thing that I care about?

And I think that's the process of like, oh, wow.

I'm saying process project over and over again.

Maybe I'll say like, there is a self-reflection that needs to happen in projects to

feel like, Hey, what is, what is done?

done.

Like when do I actually, as you said, like earlier in your project, you're actually

like do more.

And eventually you started to realize like, okay, this might be a little too much

because then the amount of stuff that I can validate and actually make sure the

quality is good might be growing so quickly.

Then you have to take a judgment call, which actually lets you decide, or then you

have to, the AI won't do this for you.

So as a builder, you need to take a judgment call, say that, no, we're going to stop

here.

We're going to actually now figure out the validation.

We're going to start figuring out if everything's working.

At least I think that's the way I'm thinking about it.

I don't know if you feel a similar, like, do you feel like that's the process?

Yeah.

Yeah.

I, to go along with that for me, how I've kind of thought about it is, you know, I

broke the project down into phases, right?

And I was like, okay, we need, what can we start out with?

You know, an MVP, right?

Like what can we start out with?

Even that is pretty big in scale.

But at least that once that's done, there's a foundation for the later updates.

Right.

Um, and so right now I think that's why this first phase, even though I've already

reduced the scope, like I have like 16 planned modules, I'm only coding like, you

know, eight of them.

And one of them is a really big commons module.

Yeah.

But the thing is that they're being coded, but a lot of them are just skeletons for

the next phases.

I mean, I think, uh, I may say eight modules, eight modules.

Yeah.

I actually feel like that's a good thing.

Usually being able to break it down into smaller pieces.

So you actually then go and if something breaks, you want to ideally be able to

focus on one module.

Oh, absolutely.

Absolutely.

And do you feel like that's kind of the, it has worked pretty effectively?

So, so one of the modules that I have, um, has been broken down into like five sub

modules.

All right.

Okay.

Cause, cause there were, there were big enough elements individually

that I thought, you know, we need to break this down a little bit more, but for the

sake of the project planning, those modules are now instead of oh four, oh four, a,

b, c.

I don't want to go ahead and change all the other module numbers to squeeze those

in.

Yes.

Yes.

You don't want to renumber everything.

You just want to let it be a submodule of the existing.

Exactly.

So those are just submodules now.

Um, at the end of the day, um, it's all about, can we maintain it?

Um, yeah.

And I think interestingly, what you're experiencing is a, there, there's a little

bit of a mirror.

There's like the other side of the coin.

If you look at software engineering, traditionally, I think we were saying there's

processes that once one follows, uh, and the interesting thing is like what I've

experienced is when you're trying to actually build something, build something new,

usually you're getting requirements from somebody.

You're actually getting requirements from a product manager or from leadership

saying that, Hey, we've identified, uh, this opportunity in the market.

Can you go scope it out?

Can we actually go figure out the process actually entails that, right?

Like the process says, uh, leadership identified an opportunity product manager.

Now it goes and figures out what that opportunity is like, how big is it?

How much scope is it?

How many things need to be built out to capture that opportunity?

And then the software engineering folks get pulled in the senior, you know,

principal folks get pulled in, uh, where they're like, okay, what modules do we need

to actually make this?

Oh, do we need new products?

Do we need eight modules?

Do we need three?

Like, is it one good enough?

Uh, and interestingly, uh, you know, there's a lot of

things we can do with confused systems.

There's a lot of things we can do with skilled systems.

And even with, uh, you know, like the, uh,

the, the, the, the, the applications that we, that we wanted to very, very much, we

didn't want to, we wanted to shift that to the, to the, uh,

you know, the, and the, the second one, we were, we were really thinking

about how we can start working with new things.

All of these things are very different than what it would take traditionally the big

tech companies to do, right?

Because they need individuals to write the code in the past.

Maybe not anymore.

Yeah, yeah.

Hmm.

I think, you know, as I've been letting Claude code it, planning the

project out, having the spec sheets and everything like that, I begin to realize

that I kind of wish I actually shrunk it even more.

Shrunk it even more?

Like a lot more, actually.

A lot more.

Because right now I have, like, if we, I'm not sure we talked about, like, the

architecture of it all, but there's going to be, it's going to be a sharded system.

We're going to have nine separate worlds.

They're each going to be very smoothly transitions for players to go between them.

But that requires a lot of extra networking code on top of Minecraft already.

And I was thinking, I could have actually just done just one server.

Single host, yeah.

Single host.

Exactly.

Ignored all the extra networking stuff.

And, you know, I'd probably already be in game testing right now.

Mm-hmm.

Because I think that that extra layer, on top of all the other things that I wanted,

Yes.

is actually, that's the complicated part that Claude is spending a lot of time on.

Yeah.

There's a lot of gotchas that, on the first pass, it's not going to catch.

Yes.

And I thought about it.

I was like, maybe I should.

But, you know, I've already spent so much.

So you are the product manager and the principal engineer, like, dealing with this

at the same time.

Yes, and I'm like, okay, well, it's going to be worth it when it works, but I will

get back to you on when it works.

And this is where I do feel like the traditional software engineering and big tech

would have been like, oh, no, we failed.

Because the process should have already caught this at some point.

So I feel like that's the interesting differentiation I see right now.

Which is not always to say it was a good thing.

Because I do feel like going through this process of, like, or the project approach

of, like, let's go start, let's just see what we can build, and, you know, let's

make it unrestricted, right?

We're going to learn a lot more.

And I think that means we're actually going to figure out things more individually.

And I'm curious if you feel like doing the project in the way that you have done it

so far has actually taught you a lot more of what you would avoid next time.

And because you are mentioning that maybe you should have started smaller and, like,

started more restrictive.

And I'm curious if you feel like doing the project in the way that you have done it

so far has actually taught you a lot more of what you would avoid next time.

There's, like, history in software engineering that kind of points us to some of

this stuff, right?

And even then, a lot of software engineers don't actually follow it.

A lot of companies don't actually follow it.

There's no guarantee it's going to actually be repeatable and working.

So individual builders now have the same similar power.

And I'm curious, are you, like, do you feel like this is one of those moments where

you're like, all right, I'm going to go ahead and let this run as it does.

But next time, I'm actually going to do single host or try and figure out what

single host looks like.

Yeah, I have a couple ideas of new projects, I suppose.

And I thought about it a little bit.

I do think that the stuff I'm doing now is informing future

projects.

I definitely would have done it a lot differently.

And another part of it is I constantly do change what I do

all the time.

Like, half of the time.

Half of my time is spent actually optimizing the workflow, thinking about where can

we cut costs?

Where can I cut usage?

For example, I have directed Opus to actually use

Sonnet to implement fixes now.

Yes.

Because, I mean, Opus will write the, you know, the plan and then Sonnet's pretty,

pretty good at implementing it.

And at the end of the day, Opus will still review the changes.

So I'm still gaining it behind the front-tier model.

And it's not just Opus, right?

If I'm not mistaken.

Yeah.

Right.

And it's not just Opus.

Yes.

There's other reviewers.

I have GPT 5.5 as well.

DeepSeq.

It's very cheap.

It's very cheap.

It's very cheap.

You're welcome, China.

But, yeah, I think the decorrelated reviews have saved a lot of money,

actually, because I'm having three different models review the code at the same

time.

And there's a lot of use.

There's a lot of unions in their findings, and there's a lot of findings that they

individually would not have picked up.

They're all trained on different data, and that gives you three different

perspectives.

Perspectives, yeah, yeah, I love that.

And I think that's really important when you're trying to build a system that's

robust, and that's actually what I'm trying to do with Minecraft.

Like, the technology behind what's going on here is intentional to be robust,

because there is a lot of different communities that have done similar things.

But not to this scale, and not, like, even

normal MMOs have failed at doing this.

Actually being able to scale out.

Yeah, actually being able to scale and to, like, allow, like, seamless gameplay.

It remains to be seen if I can accomplish this myself, because I get a little

concerned, thinking, like, why hasn't, you know...

I was going to say, for our listeners, can you maybe, like, do you have a specific

thing that you can talk about where the scale was required?

Yes, yes, what was that game?

Amazon Game Studios, we played it a little bit.

Oh, yes, yes, New World, New World.

New World, and see, that was the game that I thought was, I thought Amazon was going

to solve this problem.

And when you say the solve this problem, which problem, if I may say, the problem in

particular.

The problem of scale.

The problem of when your game releases, you have millions of players that arrive,

and all of a sudden you have a 30,000 player queue.

Yes, yes, yes, yes, okay, yeah, yeah.

And not only that, it's not one big world.

There's hundreds of worlds that have lines.

Yes.

They're crashing left and right.

And I was like, come on, AWS, Amazon, had to have had the resources and know-how

to do this.

But yet, they made the same mistake as every other predecessor before them.

And I think that's the really interesting part, is, like, I'm also curious, like, if

I were to go back and ask them that question, what part broke, right?

Like, what was it the fact that now you would have to...

Just have n number of players on the map at the same time?

Was it that they're trying to communicate with each other over voice or something?

And that was essentially what was causing the breakage?

I'm curious of, like, what was their bottleneck?

Because, sorry, yeah, you had something in mind?

I do have something in mind.

Like, I played a lot of different MMOs.

A sharded system is really common, right?

The issue, I think, that Amazon...

That Amazon had with New World was they built the game like it was any other MMO.

They did not take advantage of their expertise.

From the get-go.

Yeah, they built their own game engine, but they didn't do anything unique.

Yeah.

They didn't structure it in a way where they could scale it automatically.

Yes.

Right.

And maybe they did, but it didn't work.

The process failed.

It didn't work.

The risk was not assessed properly.

Yes.

I mean, there were...

We played launch.

We literally could not play for a few days.

Yeah.

Yeah.

We actually gave up on the weekends.

Yeah.

Yeah.

Yeah.

We had to wait a few days.

And to me, that's millions of dollars being lost.

Yeah.

I mean, I think New World would be a completely different game.

If it was built with that scale from the get-go.

If it was built properly from the get-go.

Yeah.

And I think that's the interesting, like, trade-off there as well.

Like, this is...

My understanding is also, like, traditional software engineering would also ask you

that question is, do you know if you need that scale?

Like, do you know if the marketing has been effective enough?

And do you know if the product...

Does the product manager actually...

Have they talked to the marketing department and seen an insane amount of, like,

interest?

And have they been able to calculate the amount of interest to then inform the scale

decision?

Because it is very common for software engineering teams during this process of

building the product to ask this question of, like, hey, do we want to be scalable

to, like, two million players on day one?

Or do we want to be scalable, you know, like, one world will be scalable to, like,

100,000 users at a time, that kind of thing.

And they make these decisions so that they can, you know, like, punt some of the

very complicated, very difficult things, in this case being, like, instead of

splitting this module into six different sub-modules, module three into six

different sub-modules, I'm just going to make module three into two sub-modules for

today.

And that'll satisfy my needs for now.

In this case, it feels like that process was a failure because somewhere, somehow

they didn't understand that the demand was so high and one of the core values as

gamers, as, like, people who enjoy playing games, waiting to get in to play your

game is a game-breaking experience.

Especially when you're super excited and you pre-ordered the game.

Yeah, and you paid extra.

Yeah, you paid extra.

And it's such a shame because I actually did, like, once we finally did play.

Yeah, it was fun.

It was fun.

But the game quickly died off

because, I mean, you had millions of players who could not play.

Yes.

Day one.

And then sometimes your friends would end up on the other server or the other world.

Yeah.

And they couldn't come and join you.

So all of a sudden, one of the main reasons I play games is a social, like, it's a

social thing for me.

I want to play with other people.

I want to play with my friends.

And if I can't play with my friends, I'm going to find a much more difficult return.

Absolutely.

So I do genuinely, like, question.

That's the traditional software engineering method.

So, like, waits for such a long span because the cost of solving these problems tend

to be, again, you're making commitments to your boss.

Yeah.

You're answering to leadership.

You're saying that, all right, leadership is saying that, OK, you have a budget of

these many people for these many weeks.

And if you can get the game released in those weeks, great.

Otherwise, we're going to maybe, like, go a few, you know, not give you a promotion,

whatever it is, right?

The value proposition is so different versus I have seen indie games that have been

so successful and they haven't.

But I also do understand that they don't have that same pressure of, like, you know,

corporate top down of, like, you need to release this soon, they will release it

when they want.

So I'm actually also curious.

Do you feel like do you feel pressure to release your project?

So thankfully, I actually have not released public information on this yet.

Oh, so so if someone finds this podcast, they will recognize my voice.

Then then they're going to start asking questions immediately.

There there are some people who know that it's coming.

I haven't given any hard timelines myself because this is,

you know, a project that I'm figuring out as I'm going along.

Absolutely.

But there is pressure because I think I set up a lot of my own

deadlines in my head.

Right.

There's I have a lot of expectations of where I should be by a certain time.

And that's part of the workflow.

And I'm like, OK, I'm going to trim this.

I'm going to you know, I'm going to accept that, you know, a lot of these things

aren't exactly as I want them, but I'm going to leave it and we're going to move on

and just try to get this working right now.

And I actually think I'm trying to get to in game testing as fast as possible,

because like you were saying, like before the podcast, the practical testing can

serve way it's way more efficient than just, you know, traditional

tests.

Yeah.

Yeah.

And I think that's a really interesting topic.

Actually, we talked about we will jump into that a little more after.

I do want to ask.

But you don't feel at this point you don't feel like you would compromise on certain

aspects, though, despite the time pressure, there are certain things that you are

very much like this is a critical thing based on your experience.

Yes.

Yeah.

Based on my experience, there's a lot of things at this point that I'm I'm holding

on to, which is really interesting to me, because when you talk about big

corporations and Amazon releasing it, the distance between the person who actually

understands the experience and the person building the experience is actually non

-trivial.

So I do feel like in big tech or in generally like big software organizations, that

is something that is I I'm really excited about the, you know, like coding tools and

all of these things becoming much more democratized, because the person who actually

understands the most about the experience now can actually ask direct questions

about, like, which parts of the experience are actually going to be implemented

versus not.

And I feel like I made the joke by you being the PM and the, you know, sometimes

that's I do feel like that that's a good thing, because I actually feel like you're

able to not only understand, but ask questions and actually also get into focus in

the right way.

Absolutely.

Though the testing part is still like an all huge, you know, open box.

And I guess I'm curious.

So, like, we were talking about certain number of lines of test versus code.

And do you want to share?

Yeah.

Yes.

I think

Project now has approximately two hundred thousand lines of code.

And it's about it's not exactly fifty fifty, but it's a little bit.

It's about fifty fifty.

It's going to be by the end of it.

I also meant the two hundred thousand lines is non-trivial.

Yeah, that that is a lot.

And I'm clearly not, you know, hand reviewing any of this.

But there is plenty of standards and conventions that we talked about last time that

are being taken into consideration during the iterative review rounds.

And actually to speak on that, give a little bit more since I've actually interfaced

with the project since then, quite a bit.

One module took 90 review rounds to converge into

what I at a certain point I actually had started to strip away requirements for the

testing.

Is that the module that you broke up or is that the module?

That's the module that I wrote.

OK, OK.

That explains all.

That does explain all.

Yeah.

It did finally convert.

Into where it was mostly like comments and code were just not consistent with

previous changes and at a certain point, I'm like, OK, we're going to keep finding

things forever.

Yeah.

And so I'm like, I think this is a good place to stop.

Yes.

And actually, since I actually went through a review review process

with the review cycle.

Yeah.

With Claude.

And I said, OK, let's take a look.

I had it log all 90 rounds.

You reflected on the review process of like this 90 iterations.

OK, well, OK, yeah.

Tell us more.

I had it.

I had it, you know, from the get go log all 90 rounds.

It logged everything from all the different the three models that I used to review

things.

Really good space to do a reflection on 90 rounds is a lot.

I was like, I was like, I burned a lot.

Like

and so it came back and looked through everything and it gave me.

So I was like, what?

I asked it.

You know, simple English.

Yeah.

What can we do to lower the amount of rounds?

Give me the executive review.

Yeah.

And it came back with a lot.

I'm not exactly familiar with maybe all the terminology specifically.

But there were things like I remember it saying, like, it will add it'll do like a

pre-flight check.

It will, like, trace all the methods and classes ahead of time against the specs.

It will, you know, it will have an index of what it needs to look for.

It added a few linters.

OK, yeah.

Yeah.

That's good.

It did.

So those are improvements.

Yeah, yeah.

Yeah.

And it's actually interesting.

The next model on the next module that it reviewed only took five rounds.

That 90 to five.

That's that's pretty.

That's pretty.

OK, I must also play devil's advocate and ask how big was the other one?

The it's I would say that they were similar, similar, similar.

But but here's the thing.

Here's the thing.

There's another reason why.

Yeah, because of the a lot of the rounds were

finding things that it should have picked up the first time.

OK, OK.

Right.

And that's where those things like tracing all the tracing the comments back.

Yeah, the linters, all of these things really did reduce a lot of the

noise.

So interestingly, I recently read this as well as like I was going through Claude's

has updated documentation online.

They actually I think a while ago put this user guide and I think it's pretty

buried.

Unfortunately, I do feel like it's a little buried.

One of their strong recommendations is plan first always.

But even before planning, you should actually ask it to understand research what

this module is doing or what this code looks like.

How does it actually trace down a particular feature?

So it's like, OK, how does your authentication flow work?

Like would be a good question.

Right.

And that actually does pre-work.

It says that, all right, capture all the information about the authentication flow,

because then I know exactly where I need to make the updates.

Sounds like that's you've experienced that firsthand now.

Yes, yes.

And like I was like last show,

there's a lot of things I'm finding out by brute force, like I'm developing the

process that, you know, a software engineer would have known.

Yeah.

Or would have been would have been instructed to do more than even know, like when

told, turn your brain off.

Just follow the process.

Yeah.

Which is I do feel like that's that's actually a very interesting distinction I want

to get back into later is

you're learning the reason why the judgment exists or the process exists.

You're using your judgment and then getting Claude to give you the right information

so that you can take the correct judgments that, you know, like probably engineering

teams have been doing ad nauseum across time.

And that ends up becoming either tribal knowledge or becomes very strict process.

It's what it feels like to me.

Like, that's that's what I'm hearing almost.

I'm curious how many more like do you feel like we also talked about using existing

tools, we also talked about like some project or so get you done as a repository

that I keep I keep talking, yes, yes, we'll we'll we'll see if that gets flagged in

some.

That is probably what got flagged on the podcast.

OK, that is probably all right.

So we were trying to syndicate our podcasts across things and the tool's name has

now become a problem.

So I'm sorry.

Andrew, you're going to have to find it.

You're going to have to get OK.

We're going to get flagged again.

Oh, it's an official.

I'll ask Claude to beep it out.

Yeah, yeah.

If it can do it, that would be fantastic.

That would be interesting.

And would also at some point love to learn more about the whole process.

We should be talking about that at some point, too.

Yes, yes, absolutely.

There's a whole process that I've used to normalize the audio to transcribe

per speaker.

That's yes, that's pretty amazing.

The podcast.

I did.

I did read the transcript, at least blurbs here and there.

I was like, OK, it's pretty good.

It was impressive.

And it was done with local compute as well.

Yeah, on GPF.

That's another that's a successful project right there.

Yes.

Anyway, sorry, coming back into this.

Do you feel like there are you're learning a lot of things based on your individual

judgment as well and you're learning a lot about the tool life is what I feel like

is most likely happening.

So maybe I should ask you that question.

You're right here.

Do you feel like.

You're learning a lot more about the tool and the process that you would follow and

building now with the modern AI tooling?

Definitely.

I guess, too, I think that was a really broad question.

It was very broad, I'm sorry.

So I was like, oh, where do I start with this?

I guess you have a little bit more specific to help me nail something down.

Yeah, yeah, definitely.

Definitely.

And without spending too much.

So like we talked about reviews, we talked about basically analyzing the codebase

ahead of time, basically doing research, pre-research ahead of time, then planning

and then executing.

Do you feel like there are more examples where you're like, OK, this is taking way

longer, this was too big, and I think maybe more like it

didn't understand me here clearly and it did all these things as well.

One of the things I think you mentioned to me earlier was you did tell Claude to

exercise his own judgment.

And that is something you're still working on figuring out if that was effective or

not.

Right.

Yes.

So so I guess, yeah, I remember talking about this last show.

Like, there's a lot of things that Claude will just fill in the blanks, fill in the

gaps, especially if you're not specific or intentful with your instructions.

If you say code this, well, it's going to code it.

But is it going to be the way you wanted it?

Is it going to be, you know, is it going to work more than once?

You know, you know, and will you be will you be able to follow its thought process

as well?

Exactly.

Yes.

I think before the podcast, we were talking a little bit about like how you've also

maybe you're using a particular workflow here to actually also learn new things

because it may tell you things and then you're just like, what do you mean?

Yes.

Yes.

And I'll speak to that.

Yeah, there's a lot of times where Claude will present an issue to me that popped up

for review.

And I'll read over it and I'll be like, what?

What are you saying?

Yeah.

And so I will literally just ask, like, what do you mean?

Like, could you expand on this a little bit more?

And then after it starts talking, I was like, OK, I'm starting to get the picture.

I ask more specific questions.

Right.

And I keep going and I keep going.

And eventually I have the entire picture and then I'll make a decision.

Yes.

And sometimes by the time I get to there, I'll say, well, we don't need.

We don't need any of this.

Yes.

OK.

And I think that is so this is this is great because this is actually what I wanted

to ask you is how much time did you end up spending doing that?

Because that is a huge value add, right?

Like that is all of a sudden you're like not only learning about the system, you're

also able to then detect it's like this was not a valuable portion of the system,

let's just get rid of it.

That's actually a really good thing.

Honestly, like sometimes you know the tool can do so much.

It does a lot.

And then you all of a sudden you can be like, oh, no, we can simplify.

We should simplify it.

And that is something that takes software engineering teams years potentially before

they realize that the systems they built, there are some portions which are not

useful and not needed and we can get rid of them and then also reduce the amount of

time we take or we spend maintaining them.

And that's cost.

That's again leadership cost.

I'm like curious, like how long now it took you to be able to learn some things

based on like just asking Claude.

Was it days?

Was it hours?

Oh, it's usually minutes.

It's usually all right.

Well, it's usually minutes.

I mean, it when something's costing me time, I

think it's going to be an easy lesson.

That's that's because you are definitely being able to see the, you know, your limit

getting exhausted.

Yeah, that's it.

I don't wait to see the percent change on weekly.

I hit refresh after two, three minutes and well, there's another percent gone.

And you're like, oh, that's that's a heavy.

Yeah.

Yeah.

It was when I had access to Fable for the three days there

was I actually was not specific on something that Fable

was researching for me.

And it presented me with a couple of options.

And I said, expand on this option.

It launched a hundred agent workflow

to research this and came back with the most worthless response

I've had, probably from Claude.

But it was successful in burning 20 percent of my weekly limit in 30 minutes.

Oh, that's 20x too.

Yeah, on 20x.

Yeah, that was about three point three million tokens for that response.

Oh, wow.

Yeah.

Yeah.

And that would have been what that would have been if it was all output.

That would have been like one hundred and fifty bucks an API.

Wow.

Yeah.

Yeah.

Yeah.

That's that's a lot.

That's an.

And that is also something that happens often.

But no, that's that's really interesting.

So it moves so fast that it essentially did so much work.

That was not really worth much at the end.

It told you something you mostly probably already knew.

Yeah.

And I was really simple.

I just expand on option two versus like go do a million.

You know, I didn't I didn't say do like a deep deep research report.

I don't know a PhD on this.

Yeah.

I just I just wanted a simple explanation.

And the thing was, I'm running multiple workflows.

I all tabbed came back.

I'm like, word, what happened here?

All right.

OK, so I do want to ask this question now is like in your mind, like, do you feel

like with events like this in general, like you now need to

really incorporate more rituals, more processes, make your project more of a

process if you want to make this into a.

Real life project or sorry, into a real life product or a real life.

Like, do you feel like now when you start running into things like this, your

confidence level has dropped enough that you now need to add things like guardrails

to increase your confidence, because one thing you already said was you did change

the process to do pre-work and that pre-work saved you from 90 to five iterations,

so like nine iterations on a single module to five, which is massive.

Do you feel like now you'd be more interested in looking at opportunities?

To add more guardrails, to slow it down intentionally?

So so that's a great thing to ask, because I actually that's my next kind of

process improvement part of the workflow is that I realized that I'm creating

a lot of workflows for it to follow.

It doesn't always follow them correctly.

Right.

Even if it's literally reading a script.

And then I realized I probably should be using skills and I haven't.

And so

my next step actually is to implement all the workflows that I have been using over

and over and implement them as formal like Claude or Kodak skills.

Yes.

Nice.

I said, OK, I am a little I may have some biased thoughts over there because I've

been using skills for a while.

But before we get into that, could I would you like to explain for audiences in case

like what is a skill versus like what is other prompting in traditional software or

prompting?

So, you know, maybe I you might be able to talk more to this, but

but I'll give you my interpretation of it first, because, again, I haven't actually

made a skill with Claude yet.

So that that was the next thing I'm going to do.

There's a really useful tool from Anthropic to do it.

But this is the skill tree.

The skill creator is so, so creative.

From my understanding.

It

essentially

is like a set of instructions that points Claude to where it needs to find the

information to replicate something

over and over, like a workflow.

Right.

Yes.

There is for me, it's like I don't know exactly how it was that different than

me telling you to read a file.

See, so that that's the question, because that's what I had already.

Like, all I have to do is tell Claude will convert this runbook into a skill.

That's all I'm going to say.

OK.

And then let's see if it works.

Right.

I'm hoping it will because it's it's all right.

All the instructions already there.

That's yes.

I think I think generally you've got the right gist of it.

It is a workflow for Claude to execute.

And in a sense of like instructions that it should know how to like methodically

say, do one, two, three, and you'll get the result that is intended as part of this

skill.

Like, for example, a skill could be like a tax preparation skill could be like, OK,

you know, put together the person's W2 and then put together all the right fields,

fill up the 1099 form or whatever the form is and then submit it.

Right.

Those would be the skill.

The thing I can add that I what I understand why it tends to behave differently than

traditionally, like just saying a prompt and then telling it to go read a file is

there is something the concept of system prompts versus user prompts.

Yeah.

So system prompts are what the AI model is essentially used to give themselves

context or like separate the role from like, oh, this is supposed to be me doing

some work versus this is what the person who's talking to me is asking.

So that person talking to me from a model perspective with the user prompt, whereas

the system prompt is essentially the actual model's own identity in a sense.

Like, what is its role?

What is its job?

What context is it?

Am I working for Anthropic?

What is my language supposed to be like?

Am I supposed to avoid saying things like, you know, like avoid profanity, avoid

doing like suggesting things that are not real, always base my things in reality.

So the there are two prompts that every AI system or every chatbot system basically

usually uses.

It is a system.

It is a user prompt because you could have n number of user prompts that get built

up over time.

But there's only one system prompt for that system to build over time, which was a

problem in the past, because if there was some very specific instructions like tax

reparation, that is very repeatable, that's very standard.

The system prompt might not be able to hold every single set of

like tax preparation

and, you know, like a writing expert and let's say, you know, a software engineer.

Right.

You can't put all of those into the system prompt.

It just gets too big.

So what they actually the innovation here with the skill was that the system prompt

would have a stub and then you could replace that stub with a user provided set of

instructions, which was a skill.

So you have within the system prompt, a specific section that's like add skill text

here.

And even the skill is supposed to follow a particular format that works well with

that model, which is supposed to give information like, all right, give me the

circumstances under which the skill needs to be invoked.

Give me, you know, like the actual step by step instruction first.

Give me some examples like how this works.

Give me like some starting text and what the eventual response should look like,

because then all of those things can go into that system prompt.

And then it's like the.

The AI model has a more specific role and is now executing a particular skill like

tax preparation and instead of the user prompt defining all of those things, which

ends up sometimes also being isolated and separated because you're also doing things

like when a user asks you for something, the AI model may or may not do everything

because a user may ask you to do bad things as well, like, you know, maybe a prompt

injection trying to do something negative is also a possibility.

So that same isolation that occurs on the user input or the sanitization

that occurs on user input does not apply to the skill and the system prompt.

Therefore, the skill is intended to be more focused with the instructions and follow

a particular format.

That's that's maybe the overly detailed explanation of it.

But yes, the intention is supposed to be that you can repeatable workflows end up in

skills.

They actually get honored more effectively.

So they actually get treated more like the model's gospel, like things that it'll

follow religiously versus not.

So, yes.

But exactly as you said, it is a workflow.

It is actually intended to be focused on a specific area and solve that repeatedly.

Yes, we just went into a five minute conversation about what a skill is.

But anyway, Andrew, come back.

Sorry.

Yeah, skills.

So you want to try skills next?

Yes.

Yes.

I want to try to create my own skills through the workflows I already have

outstanding and hopefully I will get more consistency.

That's my goal.

Like the workflows work, but there's so many instructions and so many

things that need to be followed.

Yes.

The models are just forgetting, conveniently forgetting certain steps along the way.

I'll be like, why aren't you doing this?

And then it'll be like, oh, it was because I interpreted,

you know, something I said earlier differently.

Like I sometimes it will say, for example,

sometimes I'll say continue autonomously.

Yes.

And it's very simple, straightforward.

Very straightforward.

It understands that.

Right.

But sometimes it will still,

you know, a blocker will come up even though I have the protocol for that.

It will show the decision menu and it would pause the whole workflow.

I'm not looking at it 24-7.

I come back, it's been sitting there for five hours waiting for me to say something.

Yeah.

And you're like, well, you know, you should have just continued autonomously.

You had the information.

Yeah.

And and then I I would ask it, so so why did you stop?

Yep.

And it was funny.

It literally said I didn't have a good reason to stop.

Oh, my gosh.

OK.

It needed your direction, Andrew.

Yeah, yeah, yeah.

And yeah, it was it's it can lose, I guess.

It was a simple thing to remember, but it still got drowned out

over time.

Yeah, I mean, and I definitely.

I think that is a challenge when context windows get long.

Yeah.

Models have been known to bias towards remembering the last thing you told them or

the first thing you told them.

And everything in between kind of just gets muddled.

Modern techniques and modern, you know, like the latest versions of Claude may be

like are better at this in certain

circumstances that are not so that they are still susceptible to them.

So there's still a possibility that will occur.

Something in the middle just gets lost.

When you said I imagine when you said continue autonomously, it's probably like

continue what?

And then it just was like, well, it was a bit better than that.

Well, yeah, I understand.

I totally agree.

Yeah.

So this does feel like there's some aspect of it where it got lost in the sauce

somewhere at some point.

And that is where something like a skill, which is like, OK, regardless of what the

person is asking me, this is what I'm supposed to be able to do is like a kind of

like it's it's kind of like a grounding.

Truth for it.

It's like this is the ground truth for me to follow or the grounding instructions

for me to follow.

So it won't ever like it always consider that, OK, regardless of what this person

said, what is the how does that work into the grounding truth of these instructions

that I'm supposed to follow and then it'll ask for clarification ahead of time and

it won't just arbitrarily just wait so that that is maybe the way to put it as well

as like you can if you have a skill for a researcher, the researcher will be like,

oh, I can't start until they give me all this information.

But once you give me that information, I can do this thing on its own.

And the similar thing is like when you hand it off from a researcher to, let's say,

a actual planning agent, then that planning agent also, if it has the right skill,

can also be like, let me clarify what I need ahead of time and then I can basically

move on.

So that's also like some of the skill benefits are also like giving a very solid

understanding of what's required to start.

And then because now you have a very clear understanding of what's required to

start, the model can also ask questions to make sure that it has enough information.

So you can ask clarifying questions and do all that stuff ahead of time.

So, yeah, sorry.

But yeah, I can keep going.

I think the important part for me

is that just like you were saying, as we started this like little tangent here,

was I like losing confidence in it, you know, performing things that I have

already established.

I have done what the models just did.

But yes, sorry, sorry.

And I'm hoping, like you implied, that the skills

will be a guardrail, that it will protect this workflow.

It's like I feel like the workflow is at a point where it's near perfection.

It's never going to be perfect, but it's near perfection enough that I really want

it to follow it.

And it needs to be able to follow it over multiple hours.

Yes.

Yes.

And I think that's a really important part is over time.

Yeah.

Yeah.

Because there's times where I see it, you know, midstream, there's regression.

It's like, oh, it's no longer like I'll try to give some concrete examples.

Like I would ask it to like it's part of a workflow and which is in a runbook.

So it has a file to check what it needs to do every time.

This is obviously not a skill.

I would say please print out the findings per model.

The severity.

Right.

A little brief description of what it was.

Yes.

Right.

And so that way, when I come over to check the logs later.

Yes.

Yeah, I can see.

OK, Deepsea found this.

OK, Codex found that.

All right.

And I also have some requirements for it to keep track of Deepsea usage since I'm

actually paying API spend on that.

Yes.

There's a lot of notes that I can go over and review later with Claude to optimize

things more, determine whether these models are worth keeping around.

Yeah, right.

And that's great.

I was actually curious.

So do you use these output contracts as the union mechanism as well?

Like, how do you you mentioned that there was all unions between the findings?

Yeah.

You rely on the contracts to essentially.

Yes.

Yes.

Because they're supposed to wait.

The orchestrator is supposed to wait for every single one to finish first.

They're all running blind.

Nice.

All of them have optimized prompts per like like angle for that for that

model.

Yeah.

Yeah.

For for that specific module, what I'm looking for.

Oh, nice.

Yes.

Yeah.

And it's preloaded again with all the trace patterns that it already knows it needs.

Nice.

And so as the reviews go along, it's only deltas.

And to be one question, just to clarify as well, like I said, contracts.

I didn't clarify.

It's a structure, right?

It's basically like a schema.

It's like, yes.

Yeah.

OK, so sorry, just quick clarification, but continue the workflow of the workflow

here.

Yeah, yeah, yeah.

So so how another part of refining the reviews that I remembered was instead

of reviewing the whole module every single time,

it would start to nail down on its own where the problems, where the seams are

really obvious is maybe a good way to put it.

And at a certain point, the majority of the reviews are only deltas.

What did we change?

What what needs more attention?

Did the fix implement correctly?

Did the test work right?

Yes.

And at a certain point it converges.

There's no more like I stage it like you had priority one, two or three.

Yes.

I have blockers, warnings,

defers, suggestions.

Yeah.

And nits.

Well, yeah, those those are that is actually also very common software engineering

methodology terminology.

Yes, I mean, Claude gave it to me.

Yeah, I mean, I asked it like, well, how would we set this up?

How would we define the different levels?

And that is what it chose for me.

And it made sense.

And I was like, oh, I'll go with it.

It makes sense.

It's pretty, pretty.

It's a good one.

Yeah.

OK, I think the one thing I will definitely say here is that sounds like

we're kind of, in a sense, also like converging onto a particular process,

because a lot of what I'm hearing is actually like very common with like a lot of

the capabilities are the way that, you know, we operate as a software company and

also like the way that my previous companies operated, like treating software

development more as a process.

And I'm even more curious now that as you have if you feel like you're transitioning

from more of a vibe coding to a more of a process driven approach or do you feel

like, oh, no, I don't actually want to get too much in the process, because that's

another big thing I've seen still, like I don't know how prevalent the term still

is.

I still think it's very prevalent.

Vibe coding is I hear it all the time.

So I want to get your take on do you feel like going away from vibe coding and more

engineering is a good thing or do you feel like I don't necessarily want to go in

engineering because there's also a traditional if you talk to people in the

industry, they're like software engineering is so slow is what it be like.

It's a very common thing to hear it as well, because, yes, there are processes and

rituals that make it slower.

So do you feel like you want to avoid becoming software engineering or what's your

take on that?

I'm curious.

Oh, I think.

I think I think this kind of puts everything we've talked about a little bit more.

No, I think it like all comes together here.

I was complaining earlier about New World and the feeling at launch.

Right.

Not being able to scale when clearly there it was Amazon who made the game, they own

AWS.

They have all the skills for this.

What happened?

It didn't make any sense to me, but uh,

they like take everything together.

One of the biggest focuses on this is I would like to do it right.

Yeah.

And and to do it right will require some standardization of processes.

So I guess to answer your question directly, I do think that this is becoming more

process driven than purely vibe coding.

Now, I guess maybe day one it was vibe coding because I didn't really have a

structure to anything yet.

Right.

It was a blank slate for me.

This is the first time I've, I've like, you know, I've written code manually before

in classes and stuff like that, but not two hundred thousand lines of anything.

Oh, yeah.

Oh, yeah.

And one thing I will throw out there is I think, Andrew, we were also talking a

little bit about your profession and since admin is still very there is a lot of

systems that you need to put together.

Right.

Right.

There's a lot of connections.

There's a level of architecture that also you need to consider is like, what is what

are these things actually do and understand them enough enough depth that you can

put them together.

And I feel like, you know, like we talked about the perspective that you're bringing

here, we also talked about this admins in particular, maybe being a really good

audience for this kind of tooling because, you know, software engineering

can be is a very wide term and a software engineer does a lot of things.

You can have like specialized roles.

You can also have generalists.

I feel like this admins, you have to be a generalist up to a large extent because

you're working directly with people and your scope is always huge.

So a lot of what we can do.

Right.

We do try to automate as much as possible.

Right.

That's how we have many more hands.

Solve it once.

Yeah.

Get it fixed one time.

Yep.

We do thankfully have other teams that can take different things like help desk and

stuff like that.

So we're not necessarily doing like all of the front line stuff all the time.

But when it comes to like, like campus infrastructure, networking issues, look at

the websites down or, you know, like, like something like that, that would

definitely fall into take for granted.

Yeah.

And into our wheelhouse.

I guess I think I got away from your question, though.

Could you could you repeat it?

The main aspect being a risk perspective is I do feel like you're building

something in your personal time that you also realize there is only so much time, so

much token budget that you have and a combination of that.

And also wanting to deliver something for you during your personal like for your

personal project.

And do you feel like at this point is risk of token

expenditure, maybe something that drives your decision towards going more into like

a process oriented approach?

Absolutely.

Or do you think it's maybe also a combination of like the experience you've had of

like orchestrating these systems for your professional life?

Or maybe it's a combination of both.

That's interesting.

I think specifically for Minecraft, it's more informed by my previous experiences

running LuxWander.

Ah, yeah.

OK.

Actually.

And actually, I just realized that as a keyword.

I just dropped right in there.

We're going to have to bleep that out later.

No, no, no, it's OK, it's OK.

I think it's more inspired by that.

There's a lot of ways where I could maybe like tweak it to parallel to some things

that work, but I think it's more so a lot of the development and what drives a lot

of the development.

And I think it's a lot of the decisions, it goes comes directly from experience that

I had running LuxWander before, like, and I think like I

guess is like a little fun story when when LuxWander first released in 2010,

it was, you know, Minecraft pre-alpha.

That was, I don't like to say it, 16 years ago.

Yeah, it was 16 years ago.

Oh, yeah.

And don't remind me.

And

you know, I released like some advertisements online, like on like Minecraftforms

.net, right?

Like I had like a thread, you know, and there was rudimentary,

you know, multiplayer Minecraft.

It crashed all the time.

You know, parts of the map corrupted all the time.

Updates were coming every day, you know.

So it almost feels like your original, that predated all of your professional

experience.

So yes, yes.

But your love for actually building this community and this actual like version of

Minecraft that everybody could enjoy in the way that you wanted it to actually was a

more of a driver, essentially, even today continues to be more of a driver to

building something really awesome, not to say that your professional experience

doesn't help a little bit here and there, but maybe it's a combination of like

wanting to build something and having the, you know, like a wish to build something,

but also like a little bit of the learnings that you've had over time, you know,

professionally and personally in your previous experience.

My reasoning for this is like some of the move from a project driven

approach of let's just like vibe coded and hope it works and hope it works like we

can deploy it versus a, oh, I actually have built something that people have used

and I want to build something again that people have will use and will really love

is a very strong driver for saying that I'm not just playing around.

I'm building something from like a place of wanting it to be successful.

And that is maybe also part of like and the risk of like my risk is I actually want

to build something as bad either, and that is like a personal feeling about it as

well.

But it's driving you to now make decisions that are resulting in like more definable

processes and actually improving the quality as well as reducing the cost so you can

actually finish and get it out the door.

And I mean, I said a lot of things.

Let me let me maybe finish it up and ask a question is, do you feel like

these tools essentially have really actually enabled you or do you feel like

these tools are just giving you more of a mirage of like getting the AI tools,

Claude in particular so far?

Was it so far?

So that is a really interesting question because I cannot say definitively

yet until I start testing it right now.

So.

So so I think ask me in a few weeks again.

Yeah, because because right now it's like undefined.

I don't have any proof yet besides the development.

And so I would like to answer that confidently.

But I guess I can answer the kind of like the idea before that.

I do think it's quite empowered me to actually create something that I've always

wanted to do.

Right.

There is there is a lot of things, a lot of like a big wish list of stuff that I had

that last time I ran Lux Wanderer,

but I just didn't really have the manpower.

I didn't have like the skills, you know, that's funny.

Yeah.

You still don't know.

You will.

You will.

You will.

Skills creator.

I will soon.

And

it has closed the gap, though, that I think like you said, it's democratizing,

you know, I guess, intelligence.

Yeah.

Yeah.

And then, you know, it might all just be an act.

And I think that is something that we will have to see if it's if it is a

act of intelligence.

That's all right.

And at that point, I think we got to end the show.

Thank you.

Thank you.

We'll have to come back and see if it is.

Yes.

Yes.

Cut the cut.