# AI Native Transformation: Strategy, Swarms, and SDLC Shifts

**Podcast:** Product Momentum Podcast
**Published:** 2026-05-13

## Transcript

In the intro, I mentioned that you are driving the company's transformation to become AI native across product, engineering, and operations.
I'm really excited to understand, what does AI native mean to you, both in concept and in practice?
Yeah, the concept piece is probably the easier piece to talk about.
You know, conceptually, it's the same as digital native when...
You know, like the internet was born many years ago.
With any sort of wave of innovation you had, you have the folks that really thought about things from first principles in terms of that, like, innovation.
And like, in the abstract sense, I see AI Native being about, you know, the folks, the companies that are really either just starting in the age of AI, like they were born today, right?
And so everything they do is shaped by the existence of AI and the ability to use AI.
We've all been operating in this kind of like traditional SDLC model for a while, regardless of whether you consider yourself agile or you're in waterfall or you're doing modern agile.
Like your method, your framework doesn't really matter.
We're still operating in something where there's initiation and discovery, right?
And then development and deploy.
And then you close and we want to repeat this process and grow.
How is that?
How is the traditional SDLC changing in an AI native organization?
Oh, man, this is my favorite topics.
So, you know, growing up in the industry, waterfall was always like the evil thing.
We can go much deeper into a problem space without ever like writing a line of code.
Right.
So, you know, I find myself doing a lot more planning with AI to a much deeper level than I would have done without AI.
Obviously, there are some things that AI can't do.
It's probably not very good at predicting how people react to your product.
Every AI will tell you you have amazing BMF.
You're like, this is the best idea ever.
And so the challenges you should be taking on are much more complex than perhaps you would have done two years ago.
That idea of being on a customer success call or hearing their concerns and having to work in a prototype.
at the end of that session is like, that is the future, right?
Yeah.
It's, you know, and it's, I dream of like a workflow where, you know, I have my transcription tool that is like recording the meeting and then it's streaming and it identifies like a product need and it automatically spins up like an agentic workflow that then like builds a thing automatically.
But, you know, yes, like it's a whole new way of working.
And what I would like to do is empower everyone at the company to be able to do that.
Another thing we're hearing a lot about in terms of new ways of working is swarms.
So what are swarms and how are they being used at Slate?
Yeah, I think it's one of those, it's slight marketing speak, but for me, I think of a swarm of a lot of agents working together in a very collaborative way with...
potential like real-time communication between them.
When I am tackling a very challenging problem, I won't just have one agent do it because, you know, there are all sorts of problems with like context window management or context management.
You know, the scope is just too big.
All right, Dan, we just got done with Adam Krieger.
Amazing episode.
But first for our...
listeners or maybe our watchers on YouTube, don't adjust the contrast of your monitor.
I do have a black eye from playing rugby this weekend.
I play twice a year and this happens sometimes.
But our episode was awesome.
It was amazing to have a technical resource on.
We don't normally have people with strong engineering backgrounds on the pod.
So Dan, what did we learn today?
Well, we learned, Sean, that you can't play rugby on the weekends anymore.
That's true.
Fantastic conversation with Adam.
Not often you get to have the CTO of a company like Slate join us.
Learned, well, for one thing, what AI native really, you know, what it means, especially in the day to day.
We learned about swarming AI agents.
I would have a great conversation about how roles are changing with AI.
Spoiler, there's a world or a waterfall might be coming back and it might be a meaningful way to solve problems.
So I'm really excited to get in the conversation.
Let's do it.
Yeah, let's do it.
Today, we are with Adam Krieger.
He is the CTO of Slate, where he leads technology strategy and is driving the company's transformation to become AI native across product, engineering, and operations.
He's worked for a lot of companies you've heard of, and now he's even got his own tool in market for helping you make your ideas come alive called iLoom.
We're going to get into that later.
But first, hi, thanks for being with us today.
Hello, it's great to be here.
Thanks for having me on.
You know, in the intro, I mentioned that you are driving the company's transformation to become AI native across product engineering and operations.
I've been reading this term AI native for a while.
You are one of the first like straight C-suite technical resources that we've had on the pod in a while.
I'm really excited to understand what is, what does AI native mean to you, both in like concept and in practice?
Yeah, the concept piece is probably the easier piece to talk about.
You know, conceptually, like, it's same as, like, digital native when, like, you know, like, the internet was born many years ago.
With any sort of wave of innovation you have, I think you have the folks that really thought about things from first principles in terms of that, like, innovation, and then...
The folks that like kind of sprinkle that innovation on top of what they're doing without any more, without any sort of more significant or fundamental like shifts in strategy.
And like in the abstract sense, I see AI native being about, you know, the folks, the companies that are really either just starting in the age of AI, like they were born today.
Right.
And so everything they do is shaped by the existence of AI and the ability to use AI.
But it also applies to the companies that are realizing the full scale of what AI means for both the product they build, the way they operate, the way people will interact with them, and really imagine things from the ground up.
And in some ways, it's easier to start from scratch as an AI native company because you don't have to really build the car while it's moving per se, but you are starting from scratch, right?
have a sort of a company of product that's out there in the market to make it like ai native you have to essentially like change some of the fundamental aspects of the product of the company but while continuing to serve and delight your existing like customers and like employees even yeah and so you know there's really it's about to me ai native is about allowing ai to So transform every part of the business, every part of the company from the way you operate, what you build, what you sell, the way that customers can interact with your product.
All of those things need to change, not just adding an AI chatbot to the side of your product.
That is the classic non-AI native.
I don't have a word for the opposite of AI native.
AI invasive.
But, you know, like it's a, to be like AI native, it requires this deep exercise in reimagination and just imagination.
And, you know, it's Slate.
We are a creative tooling company for social media professionals and beyond.
And yeah, like we could build a chatbot that like helps you generate AI content.
That would be the most obvious way of sprinkling AI.
on top but it's really important to us that we don't do that i can't go into every single detail because it's still under wraps but like what we are doing it's late is we are really like really examining what our customers want we know our customers very well i think that's one of the things that gives us an unfair advantage in the space like what do folks that the social media professionals really want from ai in the context of creating tool creative tooling we are embedding that throughout the product.
We're embedding it, like we're changing the way that people could even interact with the product.
We are changing the entire way we operate as a company.
You know, now we are embracing like the ability for like non-engineers to ship code, which, you know, is very more common.
But I see like fundamental shifts in the roles of engineers, the roles of like product managers, designers.
even technical support, like people that are very familiar with the product, very familiar with the customer, but up until very recently haven't been able to make meaningful contributions directly to the product.
All that is changing.
And I think in an AI native company, just the day-to-day of the company, who does what, the roles, the owners of things are going to look very different.
Yeah, I'd like to hear more about that, right?
Most of the folks that I work with are not AI native in the standpoint of they're starting new companies born today, right?
And they're trying to react to, you know, where the industry is going.
Really curious to hear, you know, what advice would you have for those companies, you know, coming from your share as a CTO who is going through that transformation in Slate?
Just how do you tackle the changes to the product that you're delivering, but also...
How do you kind of get the people on board?
Yeah, I think the advice I'd give people, like leaders looking to sort of enable that change in their companies is look for the people that are naturally gravitating towards this change.
In every company, even if you're a small company of 20 people, you are going to have a few people that are very excited about this, a few people that are very like, served and fearful, right?
And then like some in between, it's going to be a spectrum.
I would look for those people who are very excited and really interested in pushing the boundaries of what their current role is and even what's possible at the company and forget as much as you can about their current position, right?
So, and whatever kind of like preconceived notions you had about what the person in that role could do.
Because those people are going to break down the boundaries and just almost break down the cells of your company and become the DNA that builds up the company from scratch.
Because that is what is necessary.
And you need to really also be mindful of those folks that aren't quite so aggressively on board.
Some of those people will come around.
It's about understanding what they're afraid of.
You know, I think AI will fundamentally change the kind of jobs we do.
I don't think it will do anything like kill software engineers.
Like, you know, I don't think that's right at all.
You know, it's going to replace software engineers in the same way that, like, email replaced paper.
It didn't.
So, you know, I don't think that we...
Like there's either people have got that, that much to be worried about the thing they have to worry about.
Like we'll say that the cliche is the thing you need to fear is like the fear itself.
Like if you become paralyzed and, and close minded to all this, then that will be a problem.
But in terms of like, like allowing a company to change, like yes, recognizing the people who can lead that change throughout the organization organically, I think is really important.
The other one is to put clear incentives and guardrails in place so people know what they need to be doing.
There is the extreme version of this, which is corporate leaderboards around token spend and token, the more the better, right?
And some people spending billions of tokens a month just to top these leaderboards.
The Hogwarts House Cup of token management.
Yeah, token usage.
That's not the way to do it either, I think.
Just incentivizing smart, like, you know, smart AI usage, measuring that, being very transparent about what you're measuring and why.
And again, allow the people to make their own choices.
We teach something here called, it's an AI fluency scale, it's just a maturity model.
But one of the things that we say is like, one, the bottom of the scale, you find out when we do this training, like, you have some agency.
there are other people with you that are not really super far advanced on their AI journey, right?
We also talk about the top of the scale.
One of your biggest, one of the biggest things, if you reach like the teacher and trailblazer level on the scale is that you actually have a responsibility as a teacher, right?
To make your training accessible or like make yourself accessible to people on the bottom of the scale.
You're not going to be able to move somebody from like a two to a five overnight.
Right.
There's no way.
Right.
There's no way to reliably do that and like make sure that that person is a good foundation of their understanding so they don't just start burning hundreds of thousands of tokens.
Great.
So roles are changing.
We know that there is probably disparity in terms of like our AI fluency across organizations.
We've all been operating in this kind of like traditional.
SDLC model for a while, regardless of whether you're, you know, regardless of whether you consider yourself agile or you're in waterfall or you're doing modern agile, like your method, your framework doesn't work, doesn't really matter.
We're still operating something where there's initiation and discovery, right?
And then development and deploy, and then you close and we want to repeat this process and grow.
How is that?
How is the traditional SDLC changing in an AI native organization?
Oh, man, this is my favorite topics.
Growing up in the industry, waterfall was always like the evil thing.
I remember like, you know, it was very much like agile, whether you called like, you know, I worked at a company that practiced extreme programming, which was like all pairing all the time, like very the opposite of a lot of traditional like STLCs.
I like very, you know, I have seen a big shift in how I want to work.
when it comes to AI.
And I think the thing that I have realized is that agile was really a mitigation of a few things, which was humans are very limited in our abilities.
And it's very difficult for us to reason about things when they're abstract.
So when we thought about a software project and like an app or a system, until it was real, until you really started playing with it.
you didn't really have much of a ability to understand all the problems you'll face.
Right.
And some of those are like, some of those are very solvable by AI and some are not.
Right.
But now with AI, we can go much deeper into a problem space without ever like writing a line of code.
Right.
So, you know, I find myself doing a lot more planning with AI.
to a much deeper level than I would have done without AI.
I don't think that what I could do now with Clawed and a good Clawed level would have been possible without AI in terms of just thinking problems through.
I would have spent a lot more time doing it and done it to a lot lower quality.
So we mitigated that by just building in chunks, choosing how much we wanted to discover at once, design and build and test and then you know and i suddenly realized that like actually like when the world of ai like a waterfall is a much is pot is actually it's achievable you can get really good results because when you go really deep into planning something you get a lot like you just explore the problem space a lot better and you've got this very like smart like co-worker suddenly that is not perfect i will absolutely lie to you and will absolutely mislead you unless you call it out.
But they are still a really good thought partner.
And you could do a lot higher quality planning, a lot higher quality research.
And the end result is much bigger in terms of scope and much more ambitious in terms of scope, but also much more well thought through.
And it resembles more of an accelerated waterfall than an intentional de-scoping exercise that we did on the Agile, where we'd say, no, no.
The purpose of this sprint is very clearly this.
It is not this.
You know, at Agile, you spend a lot of time defining the boundaries of what you are trying to achieve in order to manage the amount of planning and unknowns, essentially.
Whereas with AI sort of assisted coding or agentic coding, you can go really deep and like go create a much bigger scope and deliver it much more quickly.
And it resembles like more of a waterfall mentality.
And I think it's going to be an interesting shift back towards the emphasis on planning that I think will happen once a week.
Because in actual, sure, you planned, but you intentionally limited what you were planning.
Are you saying you think that maybe the time that we took to define the boundaries around MVP, we still need some sort of boundary, but that time is compressed.
And actually, that time that you used to spend on being like, what is out of scope?
It's now going to be spent on like, how do we actually deliver more in this like initial and kind of like, yeah.
And you can just go first deeper, going way deeper.
And it's even on like your first version.
Now, obviously there are some things that AI can't do.
It can't, it's probably not very good at predicting like how people react to your product.
Like every AI will tell you have amazing PMF.
You're like, this is the best idea ever.
Like you should definitely do this.
What a winner.
Right.
And so there's so many reasons.
to limit the scope and ship something that isn't like insanely like detailed or you know like ambitious but you and again ai is a good thought partner to help you come up with that mvb but you certainly wouldn't trust its like definition of its predictions of pmf like i think that's something you have to evaluate for real like just as you would before um and in fact I would still tell people if they're thinking of building a new product, a new service, the first thing to do is to try and emulate it without any tech.
If you could do it with a spreadsheet, do it with a spreadsheet.
Try that.
To be honest with you, I also maintain that the kind of SaaS products that simply wrap a spreadsheet are the ones that will go away.
And so the challenges you should be taking on are much more complex than perhaps you would have done.
two years ago.
And actually, I think we're in this learning phase now of everyone via coding their own products, launching them as SaaS because they would have been SaaS products three years ago.
But now they're not solving big enough problems to be a viable SaaS product on their own.
So I think that it is more important than ever to understand your MVP because it's so easy to build stuff.
But yet it's because it's so easy to build stuff.
You have to solve a problem that's inherently very difficult and is not just some data crud style problem.
It has to be something that takes real experience beyond which an NLM could provide.
All right.
So it sounds like we're not running our businesses through Excel anymore, but maybe Excel with Copilot.
Maybe.
But yeah, you said something that, you know, is interesting, right?
This idea with AI, like maybe the concept of waterfall is kind of coming back because of the way we can go deeper.
Yeah, this goes to something Sean and I have been hearing talk about a lot.
The role of the product manager is in a lot of ways becoming more important.
Yeah, I'd love to hear your thoughts.
And as product people, like, you know, how can we manage, you know, the going deeper on the problem?
with all the other demands on us?
Yeah, I think, well, the good news is, is that you could have other, you could empower other people to go deeper too, right?
You, I think the product manager more than ever has become a role about providing context.
You know, I think that PMs, the most powerful thing they can do in an organization is provide context to other people.
I think a big anti-pattern that has existed for a while is for PMs to make all the decisions.
In the short term, is good, like, you know, fast decision-making.
In the long term, it becomes a bottleneck, right?
Because only if you have one PM working with a team of like 10 to 20 engineers, for example, instead of having 10 to 20 decision-makers, you only have one decision-maker.
And then as the team scales, as the company scales, the knowledge just doesn't proliferate.
That context just doesn't proliferate.
So I think PM is really the role that...
PMs should always be, have been providing is primarily context for shape to engineers, to help them make their own decisions, help them have the information and the techniques with which to do product management at a more tactical level, right?
PMs, I think now PMs should be elevated to a much more strategic role where it's like really understanding the long-term vision of the company or the product and like helping translate that to like, engineers who are working on building out the product and making their own decisions, elevating them to own the business outcomes, not just the code.
Also, PMs should be using AI to communicate ideas much more effectively or even ship initial versions of things.
This isn't just engineers, but you know.
I apply it humorously just to engineers.
But like, if you want an engineer to do something, like if you ask them to do it, sure, they'll get it done, you know, or they'll, you know, but if you do it wrong, they will like fix it so quick.
So, you know, having a PM, and I mean that with love, I'm the same, right?
If someone asked me to do something, I'm like, oh, okay, well, you know, if someone does it and I'm like, no, no, no, it's wrong.
Like, oh, like somehow it activates another part of my brain.
My wife hates this about me.
But, you know, I think like PMs can move things along by shipping their versions of things.
And that's going to like suddenly like again, we've seen this at Slate.
Shipping a first version of something, whether it's an engineer does it or a PM does it or a member of a technical support team does it.
It suddenly creates these conversations that move things forward.
And like that is another tool that PMs have now that have never had before.
So to answer your question.
I don't think it's just on the PMs to go deep on things.
I think it's really about the PMs to just provide all the context that's going to enable other folks to go deep.
Otherwise, you will still be the bottleneck.
And whether that be context comes from your own deep research, a lot of context around the business and what the business needs and the goals of the business, to just communicating your vision in new ways to allow other people to understand what you want.
That, to me, I think is how the PM role is going to change.
Okay.
And it all depends on the type of PMs.
I think a lot of the tactical stuff goes away.
Yeah, I think you're right on there.
Right, a picture's worth a thousand words and a prototype that you can use AI with to communicate what you're thinking is probably worth like 10,000 words.
So I think, yeah.
It's an interesting, it's an excitement direction.
You know, skip the part where you build the thing, have the demo, and then have everyone after hours of work realize that they hate it.
Now we can do that in half a day, right?
Yeah, it's crazy.
And in fact, you know, it's happening right now.
You know, I sort of heard it a, I was in a call with our customer success team and they talked about a common customer pain point that Slate has had for a little while.
And just like it's been, it's one of those things that's been on the backlog.
And I spun up.
In the call, I spun up Illume, which is this agentic coding tool that I built on top of Claw code.
And it just, in the background, worked on implementing version one of this feature.
And it did it.
And with a bit of theater, I actually demoed it at the end of the customer success call.
And that wasn't the final product, right?
It did a lot of the work, but it led to this whole conversation about which UI paradigm should we use for this?
Like, is this what?
what does this mean for our customers if they could do this?
Like, is this the right thing strategically?
And it inspired a designer to come up with their own UI model for this.
So they can, so, and it's great.
And today we reviewed them and we were like talking about the strengths and the, like the weaknesses of both approaches.
And we could just like give them to the team and give them to our own marketing team who are amazing social media marketers just to play with and be like, which one, which one feels like, like right for what you want to do.
But yeah, they're not Figma clickable prototypes.
They're like real versions of the product that I built while already in a meeting, like in the background, and then a designer built themselves, like when they saw mine.
And that's a new way of working.
And that's the kind of, I love it.
Like it's great to be able to get such high value signal so quickly from such a broad group of people.
Yeah, that idea of being on a customer success call, hearing their idea and having a working prototype or hearing their concerns and having a working prototype at the end of that session is like, that is the future, right?
Like that's, yeah.
Yeah.
It's, you know, and it's, I dream of like a workflow where, you know, I have my transcription tool that is like recording the meeting and then it's streaming and it identifies like a product need and it automatically spins up.
like an agentic workflow that then like builds a thing automatically.
Now, if you want to talk about token maxing and burning tokens, that is going to be like, I'd win.
I'd win that.
15 things a day and, and, and like maybe three of them would work.
But, you know, yes, like it's a whole new way of working.
And that might, and what I would like to do is empower everyone at the company to be able to do that.
Not just me and my toolkit.
I want to make sure that we get to this question before the end of the episode, because again, we asked about the term of AI native.
What does that mean?
Another thing that we're hearing a lot about in terms of new ways of working is swarms.
So what are swarms and how are they being used at Slate?
Yeah, I think it's one of those, it's slightly, it's slight marketing speak, but, you know, for me, I think of a swarm of a lot of agents working together in a very collaborative like way with.
potential like real-time communication between them you know i think i also think of swarms of drones and i guess there are some similar heretics but um you know as like the way i use swarms is and i did not use it for this uh in you know the instance i just talked about on that customer suggest call but um when i am tackling a very challenging problem i won't just have one agent do it because you know the the there are all sorts of problems with like context window management or context management.
You know, the scope is just too big for one, like agent instance to really run and maybe some parts of the work you want to do with a different kind of model, a different model rather.
So when I'm working on something really complex, I, you know, there's a feature in Elu, which is like the, it's a plan and epic.
And you describe it, it really goes deeply on the planning.
This is perhaps similar to the brainstorm functionality of like superpowers and the superpowers plugin.
for code code and there's also other equivalents, right?
This isn't not claiming this is like unique and innovative.
It's just a really key part of the process.
But the planning piece really goes down and asks a lot of questions, right?
To my point earlier, it's more like a waterhole process where you really try and think through a lot of the problem space up front rather than just building it and see, right?
You think through the problem space, think through the tech choices, the data model.
You know, if you're working in, it's very good in the Brownfield data, Brownfield co-base, because it'll look at the different repos and what they do and like understand where the best place to make these changes and obviously scope out what those changes are and how to validate them.
At the end of that process, you will have essentially one epic task, like an epic per repo, right?
And each of those epics will have a web of child issues within them.
And that...
Those child issues are essentially a DAG, a directed acyclical graph, which shows you essentially, like it showed as an agent how to execute these tasks, like which tasks depend on what, like a rut ordering, what can be run in parallel, what has to be done in sequence.
And then when you basically kick off each of these epics separately, you can do it at the same time or do them sequentially, it's up to you.
And each of that then spins up a swarm of agents for each epic.
And that swarm will be multiple agents.
And their job is to execute each of these different issues in parallel and run through a really structured workflow, which is absolutely like the best way to tackle feature development with AI, which is each issue, right?
And so each agent, and there's maybe a swarm of 30, each agent runs through a research process where it analyzes the code base.
It runs through planning where it takes that sort of the results of that analysis and it creates a plan to solve the sort of the problem at hand, the task at hand and only that task at hand.
But it then goes into implementation.
It goes into code review.
And then like finally at the end of each wave, there's like a verification step where it makes sure everything works together and everything plugs together.
So like every swarm operates in a wave.
And these agents just chew through this very complex, potentially, like backlog of tasks.
And, you know, I absolutely hit the toward max 20 limits in like one session.
Like my five hour limit was just like destroyed by having 25, 30 agents go through this.
But at the end of that, the result is incredible.
The result is something that, you know.
It's not perfect, right?
I don't think anyone can claim to one-shot something of high complexity, but it is something that is leaps and bounds ahead of where you'd be able to get with just like one or two agents working on something.
And way further ahead than you could possibly get without the assistance of AI.
How much are you involved in designing the workflow that you expect them to go through?
Do you have to define that or?
Is there, is something else driving the definition of the way that you expect them to execute tasks?
You mean the swarm?
Like how I, like, yeah, like this, I mean, it is every, everyone's going to implement this differently inside a loom, which, you know, is, is what my experience of building it.
Like a lot of it is predefined.
Like the, the steps that it goes through this like research plan, implement like code review, like there's a verification set.
That stuff, that's pretty like, that's predefined, but the inputs to that come in a couple of ways.
There's the task definition, right?
So the task itself is the prompt.
Then there's also the workflow configuration.
You could actually configure it to automatically review any of the steps with other models.
So right now for complex tasks, I have Gemini review the plans it comes up with.
And more often than not.
there are meaningful improvements that get made.
I also have Gemini do code reviews.
I found that to be a really good model.
Gemini 3.1 Pro does a really good job of code reviewing.
So you can customize it that way.
And then ultimately under the covers, it's just all clawed code.
So things like the clawed MD or rules or skills, they still get used.
So if you need to customize what happens when you work in a certain part of the code base.
that will still happen as per the Lord MD or the rules files.
So the Loom workflow is fairly fixed, which is intentional.
Like it's not supposed to solve every problem ever.
It's just really helpful to do for each developer.
Awesome.
And this has been super informative.
I would have to hear you mentioned Loom.
What's coming from Slate that we should be excited about?
Yeah, Slate is like we've got...
very exciting things in the world.
So first of all, it's like a really, as I talked about in the beginning, building AI into the fundamentals of the product.
Like I think it's, you know, we are going to see like a major shift in the capabilities of Slate, how it's used.
And we are doing it in a way that is meaningful and beneficial.
I think we are all at Slate very keenly aware of the risk of turning a creative tool into a slot factory.
You know, we do not want people to be churning out AI slop with Slate.
The unique value prop of the product is to create content in line with like brand guidelines, right?
And some brand guidelines can be expressed in very like tangible things like the colors, the fonts, right?
But something that's a lot harder is the quality bar that a brand has and creating a tool that makes it very difficult.
to create AI snop is like, I think going to be a, you know, a valuable proposition to brands that care deeply about what gets produced in their name.
So, you know, we're very keen on that.
We're shipping a lot more, like we are leveraging AI to really empower our engineers just to ship a lot more features across the board.
So, you know, I go on door, go into too many details, but the kind of, work you'll be able to do within Slate is going to grow.
Like right now, we occupy a particular piece of the workflow and we will be growing that position over this year significantly.
We're going to do a lot more with the product, a lot more collaboration, a lot more media management.
And on top of that, we're also hiring more engineers as well.
I do not believe that we should hire like layoff engineers because of ai or even keep headcounting the same i'm a big believer in in doing a lot more with more yeah instead of just trying to do the same with less or more with the same it's like no i want to do like an order of magnitude more with more engineers yeah that's what our belief is too our belief is now is the time for investment not the actual time to not to cut the workforce right uh tell us about ilume and what what this is and how people should use it yeah um it was really built out of a uh a need that I had last year to work on multiple things at once with AI.
I just realized that once I got into this very consistent workflow, it meant I went from talking to pair programming with Claude and saying, hey Claude, do this, now do this.
It was no longer so interactive.
I found myself hands off the keyboard for 10 minutes at a time.
So I was like, wait, what else can I do in those 10 minutes?
I could do other stuff.
I had to work on other AI projects.
And so I was doing like different things at one time.
And then, you know, I did that and it was a lot of fun, but I'd end the day feeling very stressed and overwhelmed because I was context switching between all these things.
And then I was like, what can I do?
And this is the kind of challenge that I love.
What can I do to like really make it much easier for people to context switch between different agents that you have running and different workflows that you have running on different tasks.
And, you know, that came to this insight that like, basically, it's very easy.
It's very hard, rather, to understand what the agent is thinking, but it's very easy to ask the agent what it's thinking.
And so really, like, there's just no good place for it to live.
And so the Illume workflow is all about exposing the agent's insights, the agent's assumptions, the insights, the risks, and the decisions, like, to the user.
right in both real time but also like storing it persisting it and it doesn't persist it in like markdown files that just get like littered and like you know very difficult to manage over time it just stores it on the pull request or on the issue that just driving the sort of the task and so what that means is in real time people can see what's going on you can see it and then over time you can go back and if you look at a PR that was closed three months ago and you're like why the hell did the ai build this thing you can be like oh it actually oh it thought that that was the assumption okay i got it well like oh we explicitly made the decision to do x y and z um and it's the kind of things that i did this for myself right so i could switch easily between these different um workflows but what i realized was that it actually made it a lot easier for teams to use it too so now you know i like teams you people like solo developers can use it it's a lot for solo developer it works for me because i'm kind of like slightly old school i like a lot of like i like myself to be disciplined in that process but it really helps where teams where like you know instead of a developer pushing up a 3 000 line pr that was written by code and it's just like here here's your pr go review it instead the pr actually has a lot of information around the assumptions the assumptions that the ai made and the the sort of what the AI was thinking and the thought process.
So what you find is when you read that, don't need to dig into the code so much.
Because often when you're reviewing code as a domain expert, you're like, okay, did they take into account this situation?
Did they take into account that?
How have they handled that?
And if your PR documentation already has the information, you actually don't need to look so much at the code.
If you want to check this out, they go to...
I-L-O-O-M dot A-I.
So it's Illum dot A-I.
I said Illum because I'm from Western New York and any syllable that's driven by a vowel has to be hit as hard as possible.
Like that's how we know how to talk.
That's why the L is lowercase.
So it doesn't look like it's an iPod.
An iPhone.
Illum is an illuminate.
It's so weirdly.
And also an intelligent loom.
Thank you.
Thank you so much for being with us today.
Yeah.
I got a couple of takeaways that I just want to like recapture.
I think that like when we initially talked about AI native, you referenced that we really need to understand how roles are changing and that how your expectation of a role doesn't need to fit like a specific definition really anymore, right?
So how are people's roles or expectations around the roles changing within your organization with...
the adoption of AI.
I think you even mentioned in our pre-production call, you had somebody who was like in customer support who actually built something and was like, hey, we should, you know, how do we, how could we actually implement this?
I think that customers would find this useful.
Like that's the type of thing that we're going to see.
Yeah, that has happened multiple times now with your AMs, support folks, designers.
Yeah.
So I love that.
But like, that's how you're going to end up re-imagining your workflows.
You also said that we should find people within your organization that are naturally gravitating towards AI-led change.
We kind of reference those people as kind of like someone who is recognized by their peers as a trailblazer.
Those are the people that you want to find in your organization because they're going to eventually get you to organizational growth.
But at the same time, don't leave the people that are maybe earlier on in their AI journey behind.
They still have a lot of useful knowledge, right?
They still know.
the problems that your software needs to solve, right?
And are still important parts of the way that you're going to deliver value in the future.
Just because they're behind the technology doesn't mean that they're less important to the business.
Yeah.
I also, I really liked your idea around like this concept of MVP scope in the future needs to be able to solve a bigger problem.
Right.
Smaller problems like really define things that you can build a nice, tight project around is not necessarily the way that we're going to be executing work in the future.
So think about solving bigger problems.
And then what you are seeing within Slate is that product managers are having more success if they understand that their goals, the goal of their role is to provide context, but also to make decisions.
Right.
So just because they're providing context means that they are aligning people, but they're also making decisions that are.
unblocking work so that's really and ideally it's more like a type perhaps a tiebreaker more than a decision maker like they should you know verify it's like the trust but verified how do i and you know give a lot of context to folks but just like make sure the output still aligns with the vision like it probably means that you miss some context right if if if not um but it it doesn't mean that you could just hand over decisions to other people you're still ultimately And then lastly, swarms are ways to use multiple agents to solve complex problems, but also to quickly burn through your token limits.
Very quickly.
Exceptional.
Very quickly.
All right.
Adam, thank you so much for your perspective today.
We really appreciate having a more technically adept mind on the podcast because it's something that we actually have not done enough of in our last like...
20 or 30 episodes.
So thank you for bringing that to our audience.
And we really appreciated having you here.
It's really great to be here.
Yeah.
Thank you very much.
I'm glad you think of me as technically a deaf dog as a technically inept.