# Intent-Driven Development: Strategic Context Engineering for AI

**Podcast:** Engineering with AI
**Published:** 2026-05-19

## Transcript

For me, the plan mode is tactical context engineering, right?
Spec-driven, strategic context engineering.
That's how I think of it.
Because you are thinking long-term.
Because if I'm going to be writing code, I'm going to live with AI written code for six months, one year, two years.
And I need teammates involved.
I need a collaboration pattern there.
So that's where I need durable context for that.
Harikushan's long career in software development spans enterprise, consulting, and startups, including three where he was a founder or co-founder.
Today, he's the founder and CEO of Polarizer Technologies, which he promises the name has nothing to do with politics.
It's about physics.
Polarizer helps enterprises adopt AI augmented development practices at scale.
He has over two decades of experience spanning platform engineering, building product startups, enterprise transformation projects, and technical advisor.
His recent work at intent-driven development has been fun reading for me, and I've been working on getting him on the show.
Harry is also our guest today on the Engineering with AI podcast.
All right.
Thank you so much for coming on the show today.
I really appreciate your time.
Hello, Carl.
Nice to meet you.
And again, thank you for having me on the show.
Very glad to be here.
I'm glad to meet you.
We never got to work together, though we have some colleagues and friends in common.
So that's always nice.
So like I mentioned in your bio, I mean, what you've been writing about on intent-driven development is some really great reading.
I'm considering you sort of a go-to source for people thinking a lot about spectrum development, for instance.
which I'll be honest, I haven't done a ton of this.
I do tend to write a fair amount for Claude or Gastown Mayor or whoever it is I'm talking to.
But I don't tend to spend a whole lot of time thinking about things as specifications.
I think of a more shined context or talking about the domain or something like that.
But I know that there is a lot of people, a whole ecosystem around it.
So can you talk a little bit about your article at InfoQ and how you see this space?
Awesome.
That's a great question to get started with.
In fact, my...
Introduction to spectrum development was early last year when Amazon launched Kero and it really picked my interest and I was trying to take a look at what's going on here.
So that's when I realized there is this whole point about context engineering, which is going on.
Essentially, when we have wipe coding, like, you know, using Cloud Code or Codex CLI for that matter, we largely have just a conversation to deal with.
Like I ask for something and it gets built, right?
But there's no durable sense to that conversation, which I have with the AI.
And I'm not really conversing with the AI.
I'm treating the AI as a tool on the task rather than a person at the table, right?
Like as AI has gotten more capable.
That's what I think is a key difference to treat the AI as a partner in thinking, to build through as to what we want to build.
Eventually, we did have plan mode and cloud code, which kicked off quite a lot.
And I used it extensively.
But then that was perishable too, because after that conversation, plans disappear.
Now they have some, you know, capability to do that.
But in the long run, the details that we came up with, yeah, it's not spec, it's not durable.
So what I was looking for essentially is some place to store my decisions that we arrived at as durable context so that in future I don't start from scratch.
Because otherwise, all I'm left with is the code base as the only thing to look at and start from.
And being the probabilistic engine that coding agents and their models are, every single time the interpretation could be different.
I don't want to again teach the same concepts back to it, right?
If I were to bring the analogy of training a young engineer, I would like to give him or her the, give them the full help that they need to begin with.
But on a day-to-day basis, I don't want to start them from day one, right?
I don't want it to be Groundhog Day for me.
I want them to retain that knowledge, the long-term memory bit.
And that's when I stumbled upon spec-driven development and that's where it's been going.
So what is spec?
So obviously that is a very, the term spec itself is fairly semantically diffused as Martin Foller would call it in the article that they put together.
But to me, largely it's about durable decisions and context, way to effectively engineer context.
And that's one of the reasons I call it intent-driven development rather than spec, because spec is anything, right?
But rather what I'm trying to communicate to the coding agent is my intention.
I'm trying to articulate it.
as to what it is rather than saying, hey, build me a nice little website for signing up for my newsletter.
I could dream of something, but I want to get into the details.
That's where I would start it off with.
And that's in my head's background development.
Yeah, I like to focus on intent.
And one of the things I keep saying is, talk to it about the domain.
Don't tell it why.
That old agile user story format as of this, I would like to that.
So that reason.
I think the so that is really important.
The more you tell it about like what's going on, the smarter it seems to get, you know.
To your point, I spend a fair amount of time trying to think about what my intent is when I'm talking with Claude usually or Gaston Mayer or whatever it is and trying to get that across.
So how does how do these systems formalize that or how does maybe you have a specific system, but let's let's think of it generally first.
How do how does this formalize that process of reifying an intention or saving an intention?
How do we do that?
Right.
So maybe if I can do a little screen share, that might just help to visually orient what we're trying to do.
Before I get into how spectrum and development itself puts a system around the context and durable decisions, wipe coding interaction looks something like this, right?
Like we have the humans, which is us, and then we're talking to a general purpose agent or something like cloud code and there's code in between.
And that's both the context as well as the final outcome.
as we would call it, right?
And at the bottom, I have something called an intent to implementation deviation.
I'm trying to map it out.
So initially, it's all great.
Like, you know, we start with a little bit of, we don't understand each other.
And then as we iterate and give it feedback on the code that is generated, I review, I give feedback.
It starts to align with me.
But then as I go along, eventually I have like a weird point at which it...
takes off on its own and has a mind of its own and I have a meltdown and the AI agent has a brain freeze.
And the fundamental reason is the context window.
We've got to keep that in mind, right?
Which is, this is popular paper, Lost in the Middle.
I'll share a link later for this.
But the whole point is the context window, however big it is, the more you start using it, you start getting it into the...
so-called infamous dumb zone of the model and we start losing important decisions.
So the way spec-driven development addresses this is largely through a way of formalizing that discussion which we're having with the AI.
So you still have the humans and the general purpose agent in between but what you importantly have is you're trying to engineer context here so that becomes a separate lane here and you have four phases not getting into any particular tool.
But my observation of the ecosystem is that every tool largely has like a discovery phase, which is where we're trying to address what are we trying to build from a business point of view.
Then we have a design phase, which is the how, like what is the technology implementation for this thing?
And then eventually.
a tasking like you know let's break this down like this is story kickoff for example right and get that task list reviewed fully and only then do you get into coding so if you notice in the swim line diagram the context is what you're building all the way through and it's only towards the end that you ever get to the implementation so through this exercise you're going from low alignment all the way to high levels of intent intent alignment and only then you let the coding agent build So which means you could have it build more complicated stuff rather than simple web pages, so to speak.
Got it.
Got it.
Okay.
So if I think about how, especially when I'm trying to do sort of a new thing, this is kind of what I'm doing in a way.
Like I even went into like my Cloud MD and said like, hey, let's brainstorm before you get into line mode.
Because I find that once it gets into plan mode, it's really dog it.
It's like, is my plan right now?
It's like, no, you still don't understand.
So brainstorm before plan to me has been really helpful.
This kind of feels like that, where it doesn't like really start until we've gone through a lot of phases of alignment, as you say.
But maybe I'm sort of doing it informally and these tools are more formal in that approach.
Or yeah, help me understand.
Yeah, I think that's a great question.
What's so different about it?
So the first difference is plans for some, I mean, if you want them to be, they are perishable.
technically speaking, right?
If you want to, you can retain it in the new cloud code.
Again, you can say which directory you want to retain the plan in and you can read them back.
And that's a brilliant feature that I think they introduced.
But that said, for the longest of time, these artifacts, the context artifacts were perishable.
When I mentioned about the division, like, you know, between discovery, design, and tasking.
Those are independent conversations which we're trying to have.
There's a framing to it.
So for example, in the discovery phase, we could be doing user stories and acceptance criteria for a feature, which is a very well-tested conversation mechanism to elicit intent.
And eventually when you get into technology, now you discuss the technology pieces with that particular business domain in mind.
Then putting these two things together.
you can task and this creates a unique advantage which I have observed in my experience which is each of these conversations are independent so I could do them with different models so to speak this could be a high reasoning model like I like GPT for putting my stories together I like Claude to do my architecture I like Gemini to probably task it and then eventually build it with something else right so I have that ability to split it up and use the models.
And I could even use an adversarial mechanism, like, you know, have this reviewed by another model, et cetera.
Yeah.
So that's one of those things.
Even asking Claude to review Claude is sometimes very useful.
I can only imagine having Gemini review Claude.
Yes.
Okay.
Okay.
That's cool.
And I think another thing you're hinting at that I maybe didn't get in my initial question is what I described, I'm just dumping all that in context.
And I mean, it's nice that, you know, Opus 4.6, 4.7 have million token context windows.
But it has to start all over again tomorrow or even an hour from now when we start the next thing.
And I have some mechanisms that are kind of get me what I want in Nadal's session start where like this session will be saved, you know, and it'll summarize what we learned and summarize what we did and what files we changed.
And some of the intention, you know, gets saved in those summaries.
Claude's own plans, I find, don't do what I want.
They do something, but they're not good enough.
But even the sessions that I'm saving right now are a little bit ad hoc.
I have to remember, oh yeah, it's this session where we did that.
And I just sort of have to tell Claude, go read this session.
This is the one that's going to be helpful.
If I forget, it's useless.
And sometimes they're not perfect.
So maybe that's what this is adding, is instead of dumping all this great context into, you know, our million tokens of context, this is more like what?
They're getting saved along the way?
Are there steps here?
They're getting saved along the way.
Cool.
In fact, if you don't mind looking at some code, so that's my actual...
like, you know, production, so to speak, for my website, the intent-driven depth itself.
And these are all my features that I've built over the period of time.
And this is durable context.
So all that conversations which we saw there, they're getting captured as Markdown files and they're being saved here.
And that's archive, which I'm showing you.
But eventually I have like a first class.
way of representing my whole feature set.
So, which means it doesn't start from the code.
It doesn't have to, which means I could throw away the code for all I care.
So, this gets into that Phoenix architecture conversation then.
Right, right.
Exactly.
Like how Chad was talking about it.
Yeah.
Yeah, yeah, yeah, yeah.
Okay.
Ooh, interesting.
Okay.
Okay.
This, okay.
Now I'm getting it.
This is different then.
All right.
Cool.
In fact, that's a great point you made.
And the way I call that is the difference between what is plan mode versus spec driven.
For me, the plan mode is tactical context engineering, right?
And spec driven is strategic context engineering.
That's how I think of it.
Because you are thinking long term, because if I'm going to be writing code, I'm going to live with AI written code for six months, one year, two years.
And I need teammates involved.
I need a collaboration pattern there.
So that's where I need durable context for that.
Right.
Plans will have some value in a few days, maybe a few weeks.
And maybe even if we're doing a deep dive, maybe they'll have value in a few months.
But you can't just stitch them all together and have a specification for the system.
That's not what they do.
That's not what they do.
Okay, so the goal for this is closer to that.
Cool.
Correct.
Okay, well, what's the landscape like?
As I understand it, you're the maintainer for one of the tools in this space, OpenSpec.
Correct.
So what does the ecosystem look like?
You said you started with Kiro.
Oh, yeah.
We had a previous guest that talked about Kiro, so that's cool.
But tell us about the other ones and how OpenSpec compares.
Oh, yeah, absolutely.
So, in fact, I personally like Kiro a lot.
They were the ones who initially popularized the term spectrum development in that context, right?
They also used the EARS format, which is, I think it stands for easy acceptance, whatever that is, right?
Which is closer to user stories format.
And I really loved that.
And you could quickly switch to user stories if you wanted.
The only problem or rather while I loved using it, it was a sort of IDE and the setup put together, right?
It's one keyro download that you do.
And it's not like a CLI tool, so to speak, right?
The experience is brilliant.
But that said, it's an experience you're buying into and you're getting into.
No qualms at all.
But then I had my own setup.
Like I'm a VI user and I'm probably living mostly in my shell.
And I like CLI tools.
And that's when I got into SpecKit.
So GitHub SpecKit became very popular again around the time frame mid last year.
SpecKit also introduced the same sort of idea.
You could use it with any model.
It's model independent.
technically speaking so that was like a big draw to me at the beginning even Kiro allows you to switch models if you want to but then CLI was my big draw so I could go into my VI setup and start using it and then I started looking at OpenSpec because SpecKit sometimes felt a little too of a heavy hitter for small little things like you know I'm trying to do something small and I don't want to be caught up specifying for the entire day you want to get get going with my job.
So that's when I started doing OpenSpec.
And eventually, that's when this article came out on Martin Fowler about the three types of tools.
And I think Birgitta did a brilliant job of conceptualizing what is three types of spec-driven development.
One being spec first, which is you author the spec from the point of helping you think through the problem statement.
But the spec itself is not really a permanent artifact, so to speak, right?
Maybe you use the spec first.
From there, you develop the code and then you also modify the code by hand, technically speaking, without going through the spec.
So which means the spec and the code need not be in line with each other.
It's just a way for you to get started, right?
It's a soft start, but the reality is in due course, the spec is not representative of the actual code.
So that's one way of doing it.
And I felt both Kiro and SpecKit were falling into that category.
But I wanted something more.
I wanted a spec to be the primary driving surface.
I didn't want to modify code directly because my mental model is inside the spec.
So then this term comes in, which is spec anchored.
That is very brilliant in the sense that spec anchored is at all given points in time.
Even if you're modifying the code, technically speaking, there is some mechanisms put in place to say the spec and the code are always.
in lockstep, which means could technically verify what's breaking.
And if a new feature addition inadvertently breaks a older feature, etc.
So I wanted a spec anchored sort of tool.
And that's when I realized OpenSpec is having that kind of interesting twist about it, where it has a top level spec, which is representative of the overall application state.
So that's one.
And then finally, she's, Birgitta talks about a spec as source.
which is eventually where I want to get to, which is there's no touching the code.
Any changes will always happen through the spec.
And that's the kind of tools that TESL, etc.
are, for example, at least what they were trying to do.
I haven't used TESL in quite some time now, but that's the kind of way of looking at it.
So visually, if I were to show you what this looks like, I'll just take one more moment to my screen.
I'm glad you mentioned Brigitte.
I'm working on getting around the shop.
Oh, okay.
Brilliant.
That's good.
So this would be a good teacher.
I think she's done a brilliant job with, you know, the kind of structuring that she's come up with there.
So this is how we looked at initially, right?
Like we looked at the tooling ecosystem.
We had strategic and tactical and tactical is the plan mode place.
And that's where you have anti-gravity, cloud code and all of these tools sitting around.
Now when you come to this guy, this is where the interesting pieces are.
I mentioned about spec-driven development and the levels of spec-driven development, right?
So that's where OpenSpec arrives at the spec anchored.
you know, range of things and the rest of it, the SpecKit and, you know, Kero is more about spec first.
I haven't seen a tool which I would say is truly Specasource, but that could be just my lack of knowledge around the entire ecosystem.
But at least in what I've explored, I haven't seen a tool which is like a proper Specasource, so to speak.
Well, if I may, we had a past guest on, Jeff Langer.
And Jeff, it's not so much a tool as like a syntax approach, but he's been working on this thing, AATV, which I'm going to get it wrong, but like development assisted, AI assisted development with verification.
That's what it is.
AI driven development with verification.
And basically what he's writing is these, I think of them as looking like lambdas because they have little fat arrows, but like he'll sort of give a name to something and then fat arrow, and then he'll give a description of what that thing is supposed to do.
And it's just sort of a syntax for that.
And he feeds that into, like I say, ChatGPT and says like, go write me code.
So sort of the combination of this and an MD file that explains the kind of code that he's looking for.
I don't think Jeff is claiming that this is true like Phoenix architecture, like you could start from the spec, but I think he thinks it's a very good way to be sort of test first, at least.
So, yeah, it's possible that something like what he's doing there could be seen as spec as sort.
It'll be interesting to find out.
Yeah.
Yeah.
that kind of leads into what is the specification format which you rightly put in there, right?
Like, you know, does the format lend itself for verifiability?
Like if it's just plain English, then obviously there is a lot left to interpretation.
If there is some sort of syntax to it, if there is some sort of deterministic way of verifying it, that's the name of the game.
Eventually, even Anthropics' own best practices says the best way you can use a coding agent is to give it verifiable intent.
The last word on it.
So, and to your point, you, you, intent driven development, right?
Like that's like what you're all about.
Does OpenSpec take that forward?
Like how, how, what do you say intent looks like?
Oh yeah.
So the way OpenSpec does it is quite interesting.
Hope that's visible.
Okay.
So this, I'm sure we can recall the swim lane diagram from a little earlier about spec driven development, how we had the design discover and all of those phases, right?
Now spec driven development with OpenSpec.
follows a three-phase approach.
It's got largely three commands.
You propose a change, you apply that change, and then you archive that change, right?
So proposal is where you go through creating the various artifacts like user stories, acceptance criteria, if you will.
And from there, you create the tasks and whatnot.
And then eventually you review those artifacts.
Like that's the first step what's happening here.
And then once you're good to go, you're happy with the intent that has been articulated in this artifacts, then you apply the change.
which is where the tasks are executed by the agent, which ends up creating the implementation, which is your code itself.
That's apply.
Once you build this out, then eventually what you do is this most interesting phase of this tool, which is when you archive it, it goes into two places.
This spec, which is a chain spec, initially starts out as a delta.
What I mean by a delta is every spec says the feature which is being added as part of this change is modifying such and such from an existing code base.
It's deleting such and such from existing code.
and it's adding this etc so because it's a delta format i can sort of treat it like a ledger right i can start attaching this delta on top of each other and create a source of truth so what happens is when i archive it bundles this up and creates a top level source of truth specification right and that source of truth specification is representative of my current state of the application and It archives the rest, of course, that you saw earlier, which I was just showing you.
This is very unique to OpenSpec when compared to, let's say, SpecKit or Kero, because they have a ledger, not really a ledger, they have a record of what all happened.
You still have independent folders for each feature, but then there is no worldview or top-level view of what's going on.
And the natural problem with that sort of stacking things is when I create feature number 10, it's possible that I knocked off feature two as part of feature 10.
So if I actually take the entirety of the spec and say, is this valid today?
Even at a conceptual level, that's not true because I don't have a worldview of what's going on.
This source of truth spec is the unique piece of open spec, which kind of lends itself to Birgitta's spec anchored, so to speak.
Again, that's my interpretation of how I'm looking at it.
Right.
But you're not claiming spec a source.
What's the limit?
there.
You're saying the code is still important.
For me, the gold standard should be it's 100% verifiable, right?
I should be able to, let's say, go do some mischief in the code and unintentionally modify.
Let's say I'm a new engineer on the project.
You've been using SDD tools for some time.
I do not go through that route of using Specker source.
I actually modify the code for it.
whatever reason.
And the system should stop me from doing that, right?
Like it should say, hey, you're broken spec.
That I haven't been able to fully get.
I have a duct tape solution for it, but I won't say I have a fully functioning solution yet.
And that's one part which is pending.
Okay, so you're not saying that you couldn't use OpenSpec.
to work in a spec as source way.
You're saying you don't have any guardrails in place in OpenSpec to force a spec as source approach.
Do I have that right?
That is correct.
I don't think we have today.
How do I put it?
It depends on the specification format and what you're using, right?
So the, like, OpenSpec itself does not limit you from making it spec as source.
It gives you all the basic fundamentals, right?
But then if the specification format you choose or the amount of detail you choose to put into it.
is weak, then the verifiability of intent is also weak, which means it's like having a test case with weak assert statements, right?
Then it's obviously going to have like loopholes to, you know, game the system.
Well, and that's another question I had when you said earlier that, oh, implement tasks and that's the code.
I thought to myself, well, yeah, I'm also the test suite.
Does OpenSpec have an opinion on how tests are generated?
Is that hidden in this diagram and it's always just zero in one of these boxes or is it outside of this flow?
So whether we use how we generate tests and what all of that, right?
Most of the spectrum development tools, some of them are very opinionated about it.
OpenSpec doesn't really say you have to write it in a certain way, right?
But you could choose to do whatever makes meaningful sense.
For example, I use Gherkin syntax to define my acceptance criteria and I directly translate Gherkin into my acceptance test.
So that way I can do ATDD.
on my application to build out the application.
Peckkit simply says in the constitution that if you follow TDD, right?
But that doesn't necessarily mean that like what sort of tests are you writing?
Are you writing an outside-in test or an inside-out sort of test?
All of that is very nebulous.
A sort of it depends answer to your question is that these tools, they give you the wherewithal to do what you need to, but then the software engineering surface is something that we need to apply on top of it.
Yeah.
Okay.
Okay.
So we should define some terms.
We're going fast.
Gherkin, when people say that, I think of the...
It was associated with behavior-driven development or design given when then, given someone has clicked on this button, when their account balance is below 50, then, you know, something, something, something.
It's a way to be very specific and not just sort of as a user, I'd like to be able to add money, but more like, no, no, when this happens, this is exactly what should follow.
Am I remembering right?
And how does that compare to, you also used the phrase ATDD, which I think is acceptance test.
So can you get into that for a minute?
Absolutely.
So let me just break down one of the features that I was showing you earlier.
So let's say I'm trying to fix the SEO on my website here.
And this is how my spec looks.
Here's the given when then, which you actually called out.
So my markdown file, I'm not really getting into a feature file here.
Technically speaking, Gherkin would mean dot feature.
That also I do at times.
I have like clear given when then, which means this translates well into a test case, right?
These are acceptance criteria, which is defined from the point of view of what does the business want?
Like in this case, what I want from the website.
And now this acceptance criteria can be directly translated into an acceptance test, which means that defines the done criteria for the feature itself.
Once Cloud Code or Codex CLI has built it.
What I mean by that is this usually translates into a playwright.
sort of test case.
Maybe I don't even have to write the test these days because it's a CLI, right?
So I'm able to invoke it using an agentic way of doing it, just a tool call and execute and test it out.
So once the code is built, literally I have one more agent, which is a quality agent, which goes through this acceptance criteria and starts checking it off.
Like, hey, is this acceptance criteria done?
Is it done?
Is it done?
Is it done?
So it's kind of doing that testing.
And that's what I mean by saying one is this drives whether the design itself like how it's done and then post facto once the code is built this is also the way for me to verify whether it is actually done done so to speak so that's how I'm driving it so one yes ATDD is driving the overall direction for the code and then there is test driven development happening at the unit level like functions and stuff the whatever react code that is being written that is again going through a TDD process but that's an independent engineering surface but this Engineering surface is for me to keep the implementation in line with my intent.
So we're not opinionated.
We allow for flexibility there.
Okay.
Ari, this is cool.
Thank you for walking us through this a little bit.
You're opening my eyes and you're showing me stuff that I'm interested to try.
Maybe I'll have to do an article about that at some point where we get into it.
We have some time remaining.
We've spent a fair amount on this, which is good.
But yeah, let's get into some of the questions that we ask all of our guests.
You've talked a little bit about the tools you're building.
You've talked a little bit about the tools you're using.
You mentioned Vim.
You mentioned all the different models.
What's your go-to right now?
I'm going to assume Vim, but like what's your go-to approach?
Are you literally going back and forth between different models all day, every day?
Or is that just a feature you strive for?
How are you using these tools?
For me, the go-to tools are CloudCode, OpenCode, and Codex CLI.
These are my coding agents, essential bread and butter sort of tools.
Within these, I obviously wire up all the different models because I like one model to opine on another model's work.
So that way I get more reasonable outcomes, so to speak.
It's more anecdotal and based on experience because I find GPT high reasoning sometimes and Claude being the best programmers.
So these are things which I use.
And obviously my tooling landscape also involves a ton of LSP servers for all independent languages.
have reduced my usage of MCP because again being context window sensitive because MCP servers are fairly annoying.
So I use a lot of CLI tools like I use Repomix a lot to reduce the context window because it can pack your code into meaningful bite-sized chunks.
So yeah, my go-to tools every day are largely the coding agents I mentioned and all the models I do whip through all of them and in some of the cases the clients that I work with.
They cannot afford to have an external model.
They have a local LLM which they have to run because for technical and also for security reasons.
Costs.
Yeah, the costs.
And so for that reason, like, you know, having the flexibility to switch models is always an important aspect of the daily workflow for me.
And sandboxes are a big part of my workflow because I don't want to constantly give permissions, but I also am paranoid of giving commissions to all these agents.
So I do have sandboxes for everything.
So I can sort of have that compartmentalization of, you know, I can have this run dangerously without permissions within that sandbox, of course.
Yeah, I noticed a vendor, a cloud vendor that I actually do use the other day.
It was saying, we'll give you ephemeral environments that you can let it, you know, have all the permissions on so it doesn't have to be your actual computer.
And I thought, oh, yeah, that's, I can definitely see the value in that.
Of course, it would be nicer if you're not even paying for it by the minute.
Okay, interesting.
We talked about some guardrails already.
You talked about sandboxes.
I think you mentioned something called Repomix.
And I think you said that it's like a context window helper.
It makes your code smaller, I think.
Can you talk more about that?
Yeah.
Or other guardrails.
Yeah.
Yeah.
I mean, Repomix simplifying what it does, at least the rub.
bunch of tools like repomix basically there is a bunch of context that gets used up in navigating your code base and uh like you know getting all of that and then reading it using file tools and whatnot yeah so a simple way of doing that is you pack all your code into a single file so to speak and then you ship it if you want to uh to the context window so it doesn't have to go back and forth back and forth and waste a ton of tokens again uh mileage you get out of such tools varies from coding agent to agent some agents are there intrinsically more optimized not to waste tokens for navigation, but others are not so much.
So I kind of invariably end up using tools like this to say, hey, pack all the files within this particular folder and ship it for me.
So it just puts it into a simple XML file and without having to go into the directory structure of it.
And again, these are some of the things which I use sparingly, where I am dealing with like brownfield largely because it's existing code.
I do not want to say like, you know, go read my three million lines of code and then tell me what to do.
That wouldn't be a wise place to do it.
So, yeah.
So that's where the tools come into picture.
I see.
I see.
So on the face of it, then it's not so much that they're reducing the number.
They're not like literally taking up a wordy Python approach and slimming it down through sort of compression techniques, one liner tricks and party tricks like that.
There are tools which do that.
Again, I don't know or haven't really pushed them to the limit there.
I'm sure there are more intelligent mechanisms and I'm thinking even Repomix actually does a lot more than what I'm giving it credit for.
But that's where like at least at its simplest form.
Yeah.
And what the thing you're looking for.
So it may not be saving context tokens in terms of like the literal tokens in the code, but it's more the navigation because it's all in one file.
It doesn't have to remember how to get from here to there.
Okay.
Got it.
Nice.
Cool.
Any superpowers that these tools have that you were surprised by?
Oh, yeah.
Okay.
So I think the most...
recent ones which I'm really really happy about is the especially the front-end design capabilities that I got with Cloud Code has been really like I'm good at saying what looks aesthetically good what is bad right but I'm really bad at translating that into actual look and feel and I have the difficulty even with having a designer like my designers always give me grief because I'm not good at articulating that.
Using the design plugin in Cloud Code has been a boon.
And then I think even the more recent capabilities that have come into, let's say, Figma or even Cloud Design, where you can chat your design.
Again, it's not the most optimal, I would say.
There is still like component.
libraries and other things, they still need to be taken care of.
It's not a solid problem, but it has certainly gotten me from, let's say, 10, 20% to about 60, 70%.
So that's a big, big win for me, at least personally.
I'm still surprised by how good it is at that, creating really nice, consistent UI if I can define what my design system is.
once and then i can have artifacts you know even flyers and like you know slide decks and everything created from one design system that's been brilliant yeah i love it my designers also like it because they don't have to deal with me now this is a better way of doing it awesome awesome love it okay cool um so what about teams that you observe?
We talked earlier about your role as CEO at Polarizer, helping enterprises adopt AI augmented development practices and so on.
Are there markers for a team that's doing well versus markers for a team that's struggling?
What sorts of processes are you seeing there?
That's a brilliant question.
I think...
That's kind of the crux of my article, which we initially started off with, right?
I think the biggest marker is not about technical capability or even to that matter, their AI chops, so to speak, right?
The biggest marker I see is, do they recognize how big of a shift it is?
And do they recognize the cultural aspect of it, right?
One is using an AI coding agent is not about inculcating a developer tool into your daily practice.
That's not at all it because that would mean independent developer productivity is boosted and you get some certain percentage of it, right?
This is a complete SDLC shift, like how the current system is a human-centric workflow for building software systems, right?
It is wired around our speed of development.
It is wired around our speed of verification.
It's not built for the compressed timelines that we're dealing with with an AI encoding agent, right?
If the team is recognizing the shift and they realize that it's more about intent articulation, it's not about preserving the existing structure.
I have a dev, I have QA teams, I have this, and this is the sequence in which it will always work.
We want to locally deploy AI-agentic workflows there.
Sure, you will get tactical advantages.
I'm not denying that.
And I'm seeing teams getting it.
But you really want to push the envelope.
You've got to think about it as a cultural shift.
You are hiring people onto the team is how you should think about it when you're getting a coding agent into that equation.
Because it takes your attention.
It takes your, you know, your effort.
So how much thought we put into hiring someone and have them come up to speed and build stuff for us.
That's exactly the kind of thought process that goes in.
So yeah, that's the biggest marker for me.
Interesting.
It's not even like, you know, whether they know how to use all the interesting features in Cloud Code, agent teams, all that.
But it's just your thought process of, can I get my intent across as an individual and as a group to this system?
I love what you're saying.
And what's coming up for me when you say that, I think for those of us, and maybe still me right now, that are using this as an amplifier for individual productivity, we sort of hit a bit of a wall at like the PR level.
pretty often, you know, it's like, okay, it can go really fast.
Isn't that cool?
But now what, you know?
And I think some teams are sort of trying to say like, oh, well, you know, we have a really good test suite.
And so like maybe the PR side isn't as important somehow.
And that seems like maybe it'll work.
It seems like with OpenSpec and some of the stuff that you're doing, there's maybe a second possibility that if you have this really good system of intent tracking, this really good system of understanding what the system should be.
Well, then maybe you can trust it to give PRs.
Like right now, if you ask an agent to give you a pull request review on almost any code, it can write you pages about what's wrong.
And maybe some of it's kind of important.
And maybe there's a gem in there that's really important.
But some of it's just, I don't know, like it just talking.
It's like that doesn't really matter.
But with the intent-driven tools that you're talking about, like maybe that gets us a little bit further or am I, I don't know, maybe I'm being aggrandizing there.
What do you think?
No, I think you're absolutely on point there in terms of the concept you're going towards, if I'm not wrong, is actually very close to this thing which has recently become popular called software dark factories.
Like, you know, your agents don't sleep at night.
They're available to you 24-7.
So why have them, like, you know, why do we have to stay glued to the screen when they can build the code?
So what we are trying to do is put a system in place which can then have this agent go and build tools off of.
Now, the important piece here to understand is that if I see a bug, the temptation is to go fix that bug in the code, right?
But the bug is a symptom of something missing in the specification or it's probably a symptom of something missing in the internal declaration phase.
Yeah.
So that's what we want to get into, right?
If I may, again.
take one moment to share my screen.
It is quite a read, this article.
I apologize if it's quite long.
But yeah, so I think what I'm trying to get to is this setup, right?
Like if there is a gap in the overall implementation, it could signal an issue in the implementation itself.
And that's an easy fix, which is where the tests and stuff come in.
Like, you know, they catch an issue, they fix it.
And yeah, you go back to a better implementation.
But it could also mean that there is something lacking in your specification, which is you have not been articulate enough in your communication of intent.
So it could be an issue here.
And why is that?
Potentially because the conversations we had with the AI or with each other did not elicit that intent very well.
Maybe it needs like, you know, we need to talk about accessibility more explicitly rather than like, you know, we forgot about it, right?
So the next time we go through the process of creating a user story, it has to pop up that question to say, have you thought about accessibility?
And that's where the hardness feedback comes into picture.
And the entire SDD workflow itself could be modified.
That could be the feedback to that.
So essentially what you're looking at is if you have a system in place that can generate software and progressively you can keep on improving it over a period of time, you will get to that state which you're calling out Kyle, which is eventually the software factory where our jobs is largely to ideate and articulate intent.
And it's the job of the agents to execute on the stuff that we have put out.
So that's how I'm looking at it.
Okay, I think I get this.
What's instinctive to me about what I'm looking at is you're talking about like, you know, there's feedback for the process.
There's feedback for the specification.
Like instead of fixing the code, like how do you fix the system so that the code is correct next time?
I'm with you on all of that.
When you get into Dark Factory, to me, it brings up, there's a little bit of a debate right now.
Is this more like a waterfall style approach?
How does this look then?
Like the humans are just spending our time writing these specs and having these conversations that get these intents to be recorded.
And then like what we push a button and, you know, overnight they go and make the thing.
Okay.
Sometimes, sometimes in software development, we do have just sort of a big pile of work that either can be well understood or already is well understood.
And it just needs to be.
written down, you know, and then that writing needs to be self-checked for internal cohesion and consistency.
And then, you know, we can actually have fairly high confidence that if the robots build this overnight, it will be a good thing.
There's work like that, right?
And there's some question even there that like, are you really sure that the spec was right?
If you're not there with the dark factory while it's building, you might still miss things.
But let's set that aside.
Not every problem is so knowable, right?
I'm sometimes surprised by when I actually need discovery and when I don't.
Sometimes I think when I'm sitting down with Claude, like, oh, I know what I need.
I just need to describe it to him.
And then I see it online later and I'm like, oh, that's not what I meant.
Or that's what I said, but I'm wrong, right?
And so discovery and learning for us, the writers of the intent, I think is an important part of the creative process.
And sometimes, you know.
How many times have you worked with a designer or an experienced designer and you implemented the way they ask and then they look at it and they're like, I don't know.
Right.
This is actually going to be better this way.
Yeah.
Right.
Interactions can change meaning, can change context.
So when I think about these dark factories, you know, there's this whole debate around is Spectreven actually good or are we going back to Waterfall?
But to me, what's more interesting is this like, aren't we losing something?
Just like when you outsource, we used to talk about like a business outsource is a really critical function in a way where they lose access to what's happening.
as part of the process of doing that function, the business itself becomes sort of poorer for it and less understanding.
If you outsource in a way that you retain that knowledge, you're in a better shape.
So these dark factories, I don't know, are they the right approach?
Like, what do you think?
See, I think the dark factory as a concept, I kind of look at it as something to aspire to in terms of what is the...
possibility, right?
Whether I want to get there is a different question.
But if I can reach for the moon, then like, you know, say like 80% of it is probably still very practical and pragmatic point of view.
That is one, like from the point of view of whether how much hype there is versus what is reality.
I still think it's a very good goal to aim towards, but how far you want to get along that as a personal choice and independent setup.
The second point which you actually hit is very important is, isn't this waterfall?
Isn't it like we are having to force ourselves to think ahead of time every single detail so that this thing can build at night?
Otherwise, I'm going to be waking up in the morning to something that is not what I wanted.
Yeah.
So the reality of spectrum development, honestly, is I think it doesn't have to be looked at as once I write the spec, there's no way back for me.
That's not really true.
Just like how we write, like I think even Ken Beck had recently posted on LinkedIn.
In TDD, the whole...
joy of the process is I write a test, I build the implementation, in the process I learn something, I go back and fix the test, and I go back and write the code again.
So there's test feeding into the code and the code feeding back into the test.
There's a learning going on here.
And I look at it exactly like that with spec-driven development.
More often than not, I get the spec wrong.
And it's not like I'm getting it right in the very first shot.
And my features are not like I'm specifying the entire application all at once.
So like I showed you earlier, I'm building small little features, I'm lining it up.
Maybe the first time, not even sure if I've articulated enough very well.
So I'll actually build it out, right, to see how it looks.
And then if it's not what I want, I'll throw away the code.
I'll go back to the spec.
I'll fix it.
I'll go back and forth a little bit.
I can afford to do this a lot because what am I losing?
My build time is hardly five minutes to 10 minutes.
So I've gained so much time during the build that I don't need to be stingy with how I plan, right?
So I can try multiple things.
I can even have like the same feature built two, three different ways and then learn from it before I actually say, okay, now I'm happy with the spec.
Let's build it, go into regression testing and whatnot and verify it.
Well, and I think part of what excited me about OpenSpec when you were showing it just now is that I could imagine it being iterative.
I can imagine being, you know, you start out today and I think your acceptance criteria was some, you know, basically SEO, you know, when they're looking at the services page and the web crawler comes.
I can imagine it being like, okay, tomorrow we realize, ah, I kind of want something different.
And that there's a process for like taking that new different thing and going and applying that concept to like the past, right?
So there's still a process for iteration there and maybe even simplifying that iteration.
So I think that's part of what I was attracted to about what I was seeing.
Yeah.
Because it is that iteration.
That's the important bit.
I'm not sure I need to iterate on every for loop.
Well, for loops are iterative.
But getting the parenthesis right, I don't think I care about iterating over that.
But iterating over the spec, I care a lot about.
So, yeah, to me, dark factory sounds like you're losing some of that.
And maybe it's just a phrase.
I don't know.
So I think a dark factory is like this, right?
If you really want to go down the factory analogy, even, you know, industrial production goes through prototypes.
and then actually use a product.
I'm not going to ship, you know, my prototype car model to a person, right?
I have multiple iterations of that.
I have multiple iterations of my assembly line itself.
But what I'm shipping is something that I'm really sure of.
And all our software essentially is a mix of different types of features.
Some are more...
dull and boring and rinse and repeat sort of features versus others are a little bit more requires a thought process.
And like you rightly put it, we cannot afford to outsource thinking.
We cannot afford to outsource execution.
And the concept of factory for me is to keep thinking to ourselves so that we can think through some of the more complex features, keep the joy of building more challenging features to us.
And while there is run-of-the-mill features which we have to keep doing, and that's where we could take help from the agent to get that job done for us.
So it's a platter, right?
It's not like one size fits all for all features.
Yeah, yeah.
Okay, cool.
Cool.
We've touched a little bit on how all this changes product management quite a lot about how this approach and your, not just your approach, but your implementation of that approach, your OpenSpec, on how it's opinionated about product management and story breakdown.
We've talked a little bit about architecture and planning.
We talked about software development itself, about testing, integration.
When you think about how generative AI tooling is changing deployment, what are you seeing out there, right?
That's a great point.
And in fact, that harks back to what we discussed in the beginning, right?
And spec-driven development or more structured dialogue.
You're separating the business from the technology and then you're building it out.
So which means when you separate the business, the what is a separate document and then there are various engineering services you're applying to it.
is technically architecture, which kind of defines your repository structure, what is the tech stack and whatnot.
Second is your deployment.
Now I can say that, hey, I am going to deploy my applications in such and such a way, which means that is what decides my health charts, my Kubernetes structure and where this application needs to go.
There could be one more layer, which is a security aspect of it.
So that applies, that brings in the layer of, you know, what is the compliance that I'm looking at?
What sort of, you know, sbomb that i'm supposed to be compliant with so those are all things which start feeding into layer by layer detailing and then all of this put together goes into that task list eventually and the task list is the execution surface right and the execution surface then is able to generate artifacts not just of the code itself but it's also generating like deployment artifacts it's generating security adjustments and so on so what it's doing is all the roles that we have we can then generate skills or agents out of it, which can then opine on the feature that's being built and eventually contribute to the long list of things that need to be done by the agent.
And that's the control surface for me.
Great.
Okay, cool.
And in there, you ended up touching on not just deployment, but infrastructure.
And you talked about dependency management, SBOM, your software build materials, I guess that's where you're thinking about what libraries you're allowed to use and not.
Correct.
That is correct.
Yeah, yeah.
Okay.
But so here's a question that I've personally been wrestling with a little bit.
What do you think happens to pair programming?
What do you think happens to log programming with all of this stuff?
So pair programming was largely about framing and then solving between two of us.
And we could exercise different muzzles and we could go on for some time, right?
These days, my pair programmer, so to speak, is the coding agent.
And that's how I look at it.
I'm overall framing for it and it is solving for me.
The one part I miss about it is, The other partner should ideally frame the problem for me and me solving it so I can keep going back and forth.
I don't see that happening.
So right now I'm more of frame, frame, frame.
And then the coding agent does solve, solve, solve.
As a team, if you're looking at it, I also use a ton of sub-agents and agent teams, etc.
So it's not just one agent I'm talking to.
So I'm submitting work to a team of agents, right?
So what I do is just for fun, sometimes I...
And actually for good benefit is I create a pair of engineers.
So like one is the adversarial of the other and they kind of fight between each other.
Again, in good spirit to get the right content out for me, right?
Agents try to please us as much as possible.
So for one agent, if my goal is write the code, the other one is try and find a way to break this code, right?
So then I can have both of them sort of do that duel and come back to me with.
code that I would be happy with.
So yeah, that's the current version of pair programming I'm doing with.
Right.
Yeah.
No, it makes sense.
Holy cow.
What cultural shift do you think is required for AI native software development lifecycle?
Yeah.
So for me, the big shift is the fact that conversations are more important, right?
I think thought that, okay, there's new models coming out every day.
There's opus and there's mythos and everyone's like, okay, we just want more.
intelligent models and the models will sort of magically do better and they do i'm not denying that models are definitely getting better at figuring out code and whatnot but the bigger point here is am i trying to hire more smarter engineers and then just hope that they'll read my mind that's not necessarily true right i want to be able to have a conversation have a system in place for collaborating properly So that irrespective of models that I'm using, I should be able to get consistent output.
And that I feel is really important as a cultural shift to focus on the conversation with AI rather than looking at it as an instruction, right?
It's a collaborative context building.
Why that is critical is almost like that takes you out of lock-in.
You know, analogy-wise, do I want to lock-in myself with smarter models?
And I cannot deal with like maybe the $2 model or the $20 model.
I only need a $200.
Right.
I feel the collaborative context building sort of wins hands down when it, when compared to like saying, you know, I'll just depend on the model itself.
So that's my big cultural shift that is necessary to think about individually as well as teams.
This kind of goes.
Yeah, yeah, yeah, for sure.
Well, and I think you've touched on how you hire, staff, train, mentor.
And I think you're right.
The culture.
It is definitely more and more this job is going to have to be about understanding the business domain and talking about the business domain and talking about the intent, talking about the problem you're trying to solve.
So I think that's 100% right.
Are you seeing anything change around like role ratios, right?
Like there was a time when you could almost have a little bit of a magic framework of like, ah, if you've got five developers, you're going to need one business analyst and maybe a QA, depending on how you're doing QA.
And these ratios kind of stood for a long time.
Obviously, they would need adjustment.
But you could kind of stamp them out a little bit.
Is that changing?
Like some people say like, oh, we're clearly going to need more testers.
And some people say, oh, we're going to need more SMEs.
And some people say, well, we're all product people now.
But yeah, what are you seeing in terms of the impact of role ratios and how many developers QA to BA and all of this?
I think the wave is yet to hit a lot more companies than we would like to see right now.
Right now, at least this is my experience, right?
And my clients, we're trying to move to help the existing teams get where they want to with the current structure.
And within those roles, I am seeing no problem at all when people move from, let's say, everyone universally needs to get more product document, so to speak, right?
They need to understand the product or the business that they're trying to deal with because they're elevating themselves from the day-to-day grant of actually executing.
So that is a given.
In terms of ratios in the team, I don't see a reason why to change right now, because at least the fact that everyone had their position, so to speak, from a human centric workflow point of view, and there were a certain ratio required to satisfy that.
But if you take the same ratio and apply it to putting the system together, like of agents, you right now, let's take example of QA, right?
I like that example a lot because I feel like.
unnecessarily we say that oh we don't need QAs or we need more QAs.
What we really need is what does the QA do now?
The point is the QA has to now ensure the quality of the harness or the quality of the system that is putting the context together to build the application so that the bugs don't get created in the first place, right?
There's still a lot of work, still a lot of software engineering that needs to be done in the system building and if you have as many developers, if you have as many QAs, as long as you're able to push them on to like system building part of it, it still works, that ratio.
But honestly, I don't want to say like, you know, this ratio will continue to work forever.
We don't know.
In due course, I think the biggest thing that's going to happen is for all of us to become more business centric and actually user centric.
Because as we push these things out, we need to be able to look at it as better systems thinkers rather than individual roles.
We could still be SMEs, but we are largely an uncollective mind trying to stage work for.
The agent.
Wow, that's nice.
Cool.
One collective mind indeed.
Okay.
So you've been very generous with your time, but we're sort of rolling towards a close.
There's three questions I ask everybody at the end of this.
And you can definitely answer these like about your career, about AI, whatever, but it can also just sort of be anything in your life, right?
The first one, almost everyone answers the same way.
So if you fall into that trap, I will point it out.
But so the first question.
What is something you've had to change your mind on?
Something that you thought you were right about for a long time and realized, oh, wait, no, that's not true.
What comes up for you when I ask that?
They've been proven wrong more than once, right?
And this has been the recent time that this has been, again, a deja vu moment.
I always thought of technology for the sake of technology, right?
But practically, technology is a way to address the human aspect of it.
It's a way to address the political aspect, dynamic of it.
teams or companies and whatnot.
So for me, architecture was the first time when I was trying to do digital transformation sort of work.
I realized that architecture was a vehicle for me to enable good dynamics in the team.
And how you technically put systems together is how you get people to positively collaborate with each other.
So that's number one.
Eventually, I did.
So I think that, you know, dynamics still plays an important role and whatnot.
And now with AI, I again see the collaboration aspect of it.
What I feel humbled about is you got to give people more credit than what we do, at least for me, usually.
The people dynamics is most important.
Technology comes later.
So if I put people first, that's how I stumbled upon intent-driven development as an idea and developed on it.
It kind of goes well for me.
And I'm really happy I'm standing corrected in terms of.
not overly focusing on AI and saying, hey, I don't really need a team.
I badly need a team now than like ever.
And this is one yet another proof that I've had to change my mind.
Like, you know, it's just knowing people always is more important than knowing tech.
Yeah, yeah, yeah, yeah, yeah.
A hundred percent.
What's something you're most proud of?
In recent times, I think what I'm most proud of is like being able to enable people who...
They're really smart, much better than I am at, you know, critical thinking and whatnot.
But probably their articulation capability, language and other things were what was stopping them from achieving what they wanted.
But now using like, you know, this coding tools and coding agents and interacting with them with some of the groups that I've been working with, even people are able to use like, you know, our vernacular language to build software.
And I'm able to get a few.
young chaps to build software from purely like local languages like Kannada or Tamil and that's very big win for me I'm still in the early stages of it and I love that part right like you know to say I don't need this individual to know English or converse that stuff like I'm still in the early phases of that but if there's anything I'd be proud of I'd be proud of that small bit oh that's amazing yeah yeah yeah it's funny we we talk about like you know these languages come from C with the curly braces and the semicolons and These languages come from basic and it's like, no, they all come from English in the end.
So I love what you're doing.
That's awesome.
Cool.
What's something that's giving you joy right now?
So I, I think I've rediscovered sort of being closer to program and code.
There's a lot more code I see compared to like, again, being a consultant, a large part of my time, I imagine you can realize it goes towards like people interactions, setting up dynamics and systems and stuff like that.
Building things is something that I've been.
yearning to do a lot more of and now I'm really addicted to like building stuff like an idea I have I can take it to implementation very quickly see it take my shape very quickly right that's that's in a way I don't know it's a good thing or yeah it is a good thing like it's addictive it's very nice to see I can I don't have to be limited by my time it's the agent can multiply the ability to execute is what's giving me joy right now amazing amazing Hare Krishna Thank you so much for spending some time with us today.
We really appreciate you coming on the podcast.
Thank you, Kyle.
I think it's wonderful having a conversation with you.
And thank you for having me.