Michael Dominick

Just like you would with like a super, like an intern, right.

Or a junior, like a super junior developer.

Yeah.

and it's is spec kit kind of doing that because it sounds like it is it sounds like you write the constitution and if let's say claude or whatever comes back with well i'm going to do it like this spec it would actually before even talking to you it seems like like no that violates this rule of you must pass you know whatever this.net validator is or you must use libraries only

I'm assuming you could say all kinds of things, right?

Like I only want to use NuGet packages published by Microsoft, theoretically, if you had, right?

Is it doing that proactively or is that still something you have to intervene?

How about where applicable, always use the ORM, right?

Yeah, exactly.

It doesn't matter which ORM.

Okay, so just to really hammer down on this point, it's not that it's a middleman.

It's that it's actually seeding the context, and when necessary, when the context has to be cleared, it's re-updating the context,

to the current state with the current rules based on your initial creation of the spec per feature.

I know that sounded very persnickety, but is that right?

Right.

That's pretty good.

So what are the limitations?

I mean, I'm assuming context windows can get a little challenging as the projects get bigger.

Right.

But is, or is that offset by the, uh, the on-disk file?