Buyer Support
Seller Support
At this point, agentic development likely plays some role within your engineering team, but you may be seeing uneven adoption, effectiveness, and coverage leading to a chaotic experience for your team. How can digital product companies leverage agentic engineering to move faster without tearing their teams and technology apart?
In this episode of Growth Stage, we interview Chris Bunk, the CPTO of FastSpring. Chris has spent the last two years diving into the deep end of agentic engineering and will share his thoughts on:
- What he thinks is the difference in agentic development vs. engineering.
- Where we’re at and where we’re going with agentic engineering.
- How you can adopt agentic engineering in a way that helps your team do their best work in a healthy way.
If you’re still trying to find success with your adoption and scale with agentic engineering, don’t miss this episode of Growth Stage. Watch or listen now!
Podcast Full Interview: Audio
Podcast Full Interview: Video
Transcript
speaker-0 (00:03)
Hello everyone, welcome to Growth Stage, where we discuss how digital product companies can increase the value of their business. I’m your host, David Vogelpohl I support the digital product community as part of my role at FastSpring, and I love to bring the best of the community to you here on Growth Stage. In today’s episode, we’re going be talking about tips for adopting agentic engineering. No vibe coding here.
And joining us for that conversation is the Chief Product and Technology Officer of FastSpring Chris Bunk. Chris, welcome to Growth Stage.
Chris Bunk (00:38)
Thanks a lot, David. Great to be here.
speaker-0 (00:40)
Awesome. Is this your first episode on Growth Stage? I actually don’t recall.
Chris Bunk (00:44)
It is, as a matter of fact, and ⁓ I’m excited to speak with you today.
speaker-0 (00:48)
Excellent, excellent. I know you’ve done some other podcasts since you’ve joined here. ⁓ but what for those watching and listening, what we’re going to be talking about today are Chris’s thoughts, having spent the last few years diving into the deep end of agentic engineering, and he’ll share his thoughts on the difference of agentic development versus engineering. What is the difference there? ⁓ where we’re at, and where we’re going with agentic engineering. So if you’re wondering,
how you’re gonna scale ⁓ agentic engineering within your own org, or maybe you’re kind of just getting started, or maybe you’re far along. Hopefully, you’ll get some insights today that’ll help you with that journey. So, Chris, the first question I have for you is kind of a twist. I normally ask people what was the first thing they bought online, but I want to ask you a slightly different version of this. What was the first AI product you spent your own money on?
Chris Bunk (01:43)
That would be when Chat GPT first came out, was the first time I actually forked over money to open AI to be able to go get the ⁓ Pro Plan, I think it was called back then. ⁓ to be able to go and essentially get more tokens in the latest models to be able to go build stuff. It ⁓ I had read a bunch of stuff and I had kind of at the time I was a little skeptical that LLMs were gonna be anywhere near to where they are today.
And that was really the unlock moment for me where I was like, my gosh, this is if it could do this, I could see where it’s gonna go, where it’s gonna evolve. And ⁓ and I was I was almost a little obsessed at it when it first came out. I was spending like my wife’s like, What are you doing? Spending your nights and weekends on this, come on. But it was just fascinating to be able to go in and have it have it build code and it was so far worse at it than it is today. It’s almost it’s funny to think back on it, but
⁓ but yeah, that was my first product that I I picked up and well worth the investment.
speaker-0 (02:40)
That’s cool. Yeah, I remember buying the pro plan pretty quickly when ⁓ playing around with GPT and it was so cheap. And I I’m not sure where it is today, but I remember that it was like the twenty dollar plan. Was there a particular roadblock that got you to spend over the free plan? Or was it just, you know, relatively cheap? So like why not get the pro plan?
Chris Bunk (03:01)
The
⁓ both the newer model and the amount of tokens were both like constraining factors that required. I’m pretty sure there was a constraint on tokens even back then ⁓ associated with it. And the other thing too is pretty quickly after Chat GPT I pulled the trigger on paid Cursor ⁓ subscriptions and then Windsurf subscriptions. And these are still the early days when it was j these tools were just hitting and becoming
speaker-0 (03:27)
No, yeah, that makes a lot of sense. I do remember wanting to get access to the newer models as one of the motivators for me personally. And it’s funny you mention this idea of quality improving, and it’s improving so fast too. It feels like in the early days it was making tons and tons and tons of mistakes, and it really wasn’t ready for proper development and engineering teams, but it’s just been so, so fast. And so I think it’s very interesting to think about where we’re at.
And to get a fresh point of view and kind of these touchstones along the way, just so people kind of get a feel for what’s happening and can take advantage of that in their own organizations. So one of the things, ⁓ at least pre-AI, we talk a lot about is what is a developer or an engineer, or in in some worlds we’ve called assemblers, people who kind of piece together technologies to to make products.
in in like this different level of sophistication. And and so now with AI, we have ⁓ abstracted out some of some of that and and it kind of changed, I’ll use a corporate buzzword, but the paradigm, if you will, of what all this means. But I’m kind of curious, ⁓ with where we’re at now, what it how do you view the difference between like agentic development versus engineering?
and are both vibe coding or neither vibe coding? Like how do you think of the ⁓ the language there and the terminology?
Chris Bunk (04:57)
Sure. So first off, I just want to acknowledge that a lot of these terms are fresh, hot off the presses, not like some formal standards body or dictionary company coming in with precise definitions on them. So I’m gonna answer this in terms of how I think about these words, ⁓ and and what they mean, ⁓ as best as I can associated with this, but there’s no like official standard associated with it. So with that disclaimer, ⁓ starting off with
when I hear people say agentic development, it’s pretty cl ⁓ like it’s kind of like the narrower focus on when it actually comes time to write code, ⁓ against, you know, something you need to go build. It’s that narrow portion of the life cycle where you’re like using agents to be able to go build code associated with it. And there’s, you know, like over things have evolved a bit and like kind of almost think of them in terms of levels of maturity of of of approaches to that. But there was like
The early days where you have auto completion, ⁓ you know, with Copilot was like the first one to come out with that kind of stuff. And then you had the the Cursors, the Windsurfs, there’s a bunch of other tools in that class. And they were like where you had your classic IDE set up, but you had a window that could open up on the side, you could talk to it and it would go in and you know, crawl across your code base and like fully change files. But then you could also, depending on what mode it’s in, like tab through the suggestions. So you kind of were still very
looking at every line of code, hands-on, ⁓ you know, building that out accordingly. ⁓ when I think about agentic engineering, you know, as opposed to development, I suppose that would mean a more broader viewpoint. I would say a more comprehensive look at the software development lifecycle. There’s even a term that gets kicked around that I like called the agentic development life cycle. And I think that would that kind of gives a nod to the classic software development lifecycle. You might want to
A different one in parallel for agentic development, or at least it’s evolved and changed quite a bit. But you can use agents and agentic development for everything from, you know, ideation, product discovery, and all the facets of product discovery, you know, of course the actual development, code reviews associated with it, verification and validation, like really the whole life cycle, every single thing that we traditionally do to be able to go build product in a project engineer product engineering team is something that we can go in and think.
Back to first principles, what’s the right way to do this on a with agents, basically associated with it. ⁓ getting to your third word there, vibe coding. It’s funny, I have different feelings on this. And so first off, it’s the original ⁓ Karpathy ⁓ I always mispronounced his name. I hope that’s it, definition of it when he first coined it. And that was ⁓ that it’s basically you have an idea of what you want.
You ask for it. You’re completely black boxing the code. You’re not directing architecture. You know, you’re basically just saying, Hey, go in and give me this feature or make this faster or go in and change this behavior. And you’re just telling it and then you validate with a human in the loop and go, okay, that’s not quite what I wanted, or hey, this has a bug in it. Go fix the bug. You keep iterating and you do it that way. It’s very largely black box. To do vibe coding, you don’t need to have a ⁓ you know.
⁓ in a strong engineering kind of sense to it ⁓ with it. And and vibe coding is also like a thing that I consider on the spectrum of how much vibe coding you do or not do ⁓ associated with it. And so ⁓ you know, we could in this case consider vibe coding to be pretty far end of the pure end of the vibe coding end of the spectrum, but it’s really easy to just introduce additional stuff with vibe coding to mitigate a lot of the downsides associated with it.
I will say that vibe coding is not fit for ⁓ like true enterprise grade products and engineering associated with it. And so ⁓ you know, you really need to be deliberate ⁓ about how you set up your agents, about how you drive architecture and be aware of the architecture, how you drive the kind of product flow and narrative as well too, so that
You know, you truly can understand it as one of the practitioners building that kind of stuff out associated with it.
speaker-0 (09:12)
So if I’m like I’m not a developer or an engineer, but I’m using ⁓ agents basically to create software for my own personal use, like custom Chrome extensions or something like that. And so that’s maybe more vibe coding, where like it’s solving a problem, I’m the human in the loop validating that it’s doing the job to be done, but I’m not an expert. And so I’m not gonna be able to get it really in a state where it’s ready for production and and like mass distribution and things like that.
And so maybe maybe that’s a way. And and it’s funny because you you mentioned human in the loop. And one of the things I’ve been thinking about recently is that really expert in the loop is where you unlock a lot of value because obviously the agents can help you move fast, but without the expertise to validate what’s happening and to direct and orchestrate it, you’re really not producing anything of like super high quality, or at least again, something like production ready. ⁓
able to distribute to many, many people. ⁓ what do you think of that idea? Is that is that maybe the difference between like someone that’s doing agentic engineering, kind of orchestrating and organizing the entire process with agents where they’re an expert versus like me, who’s just like the human in the loop?
Chris Bunk (10:29)
Sure. So first off, vibe coding is extremely useful and the right approach for a variety of things. One is like coming up, basically prototyping, right? Coming up with what you want. There’s no better spec if you’re an engineering team to go build something out rigorously, build something out mature, than to go in and take a ⁓ a prototype and say, hey, this is exactly what I want from a functionality perspective. And so I think it there’s an opening where you don’t need to route everything through.
necessarily a product manager that needs to go do all that stuff for you to have some engineer go prototype it and get really confident. It’s now possible to unlock that far closer to the subject matter expert, the domain expert associated with it. So, you know, what’s worth your FastSpring I highly encourage you if you want something and you want to go vibe coded, vibe coded and it’s like way better than a spec or an ask and you have the comfort of having played with it. Whenever you that’s the whole point of prototyping. And it used to be expensive enough to prototype that you didn’t do it except for kind of like
more important higher leverage kind of activities. Now it’s really cheap. You can do it for anything, even little internal tools. And so and so the other one is vibe coding when you go and apply it to internal tooling or things that you just don’t need that maturity rigor. You don’t need things to have four nines of reliability sometimes. You it’s okay if it breaks or if it has bugs, you know, for internal tooling, especially if you’re the, you know, the builder of it. You’ve you’ve hit a bug, you just go ask it to change it. You hit a
Hit a snag where it’s going down all the time, say, Hey, I need the reliability improved. And you can vibe code your way through, you know, the the egregious ones and you can accept those kind of faults associated with it. Typically, too, if it the it doesn’t have a like a high scale and you don’t have to worry about the scalability, there’s another angle on it that ⁓ you know you can be lax on. So it’s definitely something I feel like everybody, regardless of ⁓ technical capability, should should put in as a tool in their toolbox.
speaker-0 (12:20)
Yeah, the internal tooling has definitely been an eye-opener, like, we could do this or we could do that. And then I like your point on the prototyping. I have a friend who had a kind of tech, you know, ⁓ SAS idea, technology idea, and she was asking me about vibe coding and I was like, use it to make a prototype. And then if you like what you see, well then figure out how you get a developer involved to help you bring it to that next level. but that’s a really good point about engineers also being able to do that as part of the process.
To help them get their head around the problems that they’re solving for faster. So, one of the things that’s really interesting to me is this idea of agent swarms. Help me understand what an agent swarm is and why would I even bother with the swarm? Why not just have one agent that has the various skills I need to use?
Chris Bunk (13:12)
Sure. So a number of things. For one, it’s as if hey, is it better to just have one engineer to work on it or a lot of engineers to work on it? Typically, more engineers will work on it, but as we know from the mythical man month, you know, you can’t have ten engineers have a baby in one month. ⁓ and so the ⁓ basically ⁓ coming up with a way to at least have some parallelism there if smartly done is really important. So that’s like
kind of the first and obvious area, but it’s maybe not even the most impactful. One of the things you could do when you have multiple agents is you could basically you have a generally you have a parent agent, like a master agent like that comes in there and it knows the initial ask and intent. And then it goes and breaks down a bunch of subtasks that need to get done in that master agent. And then it’ll go hand off those subtasks to specific specialty agents, right? You could have it be a generic agent, but it’s better if you have a specialty agent. What a specialty agent does is it takes
What gets passed to it in all the context that’s built up there. And it adds some additional context that includes how to do that role very specifically. So you could have a security agent that goes in and anything that gets planned, make sure it gets planned to be really secure according to these standards and looking out for these things. You can build up what you consider that great security agent. You’d also have a security audit agent that on anything that gets pushed, you know, gets reviewed accordingly there. And that has specific instructions on how to.
validate and test those kind of aspects associated with it. So I in my stack, I have ⁓ I mean I guess it depends on the number of projects, but generally I have anywhere I I often have at least fifty different subagent definitions, which really should be thought of as different competencies that exist in there. And I have a master agent that can go in and funnel to it. And the reason that’s real important is it keeps the context window cleaner. One of the
The biggest things that really matters or separates out successful and less than successful agentic engineering, in my opinion, is being really smart about your context window. And just to recap for those listeners that may not be asked the question, what’s a context window? It’s basically all the additional content you bring to the table when you go in and talk to your LLM. So if you think about it like a Chat GPT experience, which everybody I think at this point has had, ⁓
You know, it not only has the start and ongoing conversation that gets brought into every other response that it gives you that you build up over time, but it also has memory where it goes in and pulls that stuff in it. When you’re talking about like an advanced agentic engineering stack and setup, what you’re doing is you have source code that you’re searching and pulling in and bringing that into the context window. You have, you know, specs that you’re bringing in, you have policies and practices and domain.
models and all this kind of stuff. And the really good stacks are really efficient at bringing that in. And what’s nice about subagents and doing swarms is you can isolate which pieces get which chunks of context, which keeps the context window lower, which means higher quality results is ⁓ as well too. So the parallelization and overall higher specialization and quality results are the big answer or reasons why.
speaker-0 (16:20)
So churning on these jobs in parallel helps you get the overall project done faster, but also having smaller context windows helps with higher quality products. So like good guardrails basically to keep it in there. And hearing you talk about these swarms kind of invokes in me principles around like CI/CD where you have like a suite of regression tests, where you have lenting, where you have
all these different kind of quality control mechanisms along the way that are kind of all doing their own job in a automated and standardized way. It feels like agent swarms are a bit of an extension of that. Is that a fair observation?
Chris Bunk (16:59)
They’re a tool, ⁓ they’re both tools that essentially play hand in hand associated with it. I don’t know if I think of it as an extension. Let me say this. The when you really want to cruise with agentic engineering and go to the really fast speeds that are possible, you need to rethink where you validate ⁓ in your overall agentic development lifecycle. And so one of the biggest validation
mechanisms that exist in traditional development is basically the PR review, the the pull request review. And so you have other engineers go in, actually read the code that gets written and get a change. Additionally, even in building, you’re going in and reading your code, you’re writing your code in traditional development. ⁓ that goes in there. And so you’re building that. And so very quickly, if you start going fast, you find that’s the limiting factor is actually reading and understanding that code and that kind of stuff with it. To be able to go get to a higher level
while still keeping enterprise grade ⁓ rigor involved, what you need to do is be able to have really robust guardrail setup. And that’s where CI/CD comes in. You know, that’s it’s more of like that’s more of like a tactical tooling kind of solve for it. But at a high level, what you need to be able to do is you need to have incredibly good test coverage. ⁓ and so I’m talking like, you know, why not have over a hundred percent, which means like every line of code’s checked plus some checked multiple times with different
Flows and scenarios that go there. So really, really strong test coverage, unit tests, functional tests, integration tests, data tests, fixtures, et cetera. fuzzing tests, like literally every kind of testing that exists, you probably want to at least consider putting in there and have it be super robust. Another important guardrail is observability. Going in there and being able to actually see the different actions flowing on your system, the conversion rates of all the different funnel steps.
You know, golden signals with like error rates, saturation, traffic patterns, et cetera, with really good alerting setup around it. So that really good observability and alerting stack becomes way more important. And then the third piece, which is where product ⁓ management evolves quite a bit in this new model, as I’m seeing, is the specification, is what at least what I’m calling it right now. What we’re talking about is extremely articulate ⁓ specification.
Of exactly what the behavior of the system is, both in happy path and edge cases and stuff that exist, along with like user profiles and all that kind of stuff. There’s a lot of rich data that we create and often have in our heads, but sometimes write down ⁓ as part of product management during product discovery. That’s gotta get to like a level that’s never be s been seen before. So there’s like spec driven developments getting really popular around that kind of stuff, but it really means just really clear definitions around what’s done there. If you have that trifecta of guardrails.
That’s when you start getting comfortable that your validation level is at or better than it traditionally is. And you’re able to stop having to need to validate it with reading every single line of code. You still want understand the architecture, drive the architecture, you still want understand the the product strategy and the flows and the directions and stuff like that, but you don’t need to literally read every line of code associated with it.
speaker-0 (20:03)
So the guardrails are important, of course. And you kinda talked about how having ex re super extensive testing coverage is like you said more important than ever. It is the and I’m assuming it’s easier to get better test coverage as well.
Chris Bunk (20:18)
It
would insane to invest using traditional approaches to come up with this rigor of test coverage that exists normally, or at least a lot of companies it would be tough to swallow. We kind of be more pragmatic traditionally of you know, you know, forty, sixty, maybe seventy, eighty percent test coverage, cover the happy paths and some of the the obvious bad paths, particularly if they introduced issues in production to have them as regression tests. But ⁓ the ⁓ once
all that kind of stuff is in place, ⁓ that’s where you can really start to have confidence that the system’s gonna stay on the rails and and and fulfill what it needs.
speaker-0 (20:56)
So of course we always want like super extensive test coverage, but it sounds like in this case with agentic engineering, because so much of it is abstracted away, is that one of the reasons why it’s more important than ever? Is because you’re of trusting what it’s creating in some regards. So therefore you want to make sure you have like super hardcore test coverage.
Chris Bunk (21:17)
Yeah, enterprise grade agentic development or engineering, I should say. ⁓ to use your words, it really requires having as much or even more confidence that the code behaves exactly how you want to. And so that’s why I think those those three guardrails, it’s almost like the ⁓ you know, ⁓ the you know, the triangle to success agentic engineering, if you will, but they all fe like interact with each other in ways. Really strong specs.
Becomes really easy to turn stuff into really strong test coverage. Really strong specs, really good to create the observability. The observability is a real-time ground truth of what’s happening at any given moment in the system, you know, where the test coverage is, you know, making sure that the fundamental behaviors of the system don’t regress or, you know, go astray and what’s what’s needed overall with it. And if you see cases where the observability or the ⁓ test coverage fail, that’s where like the spec needs to be better articulated and tightened.
typically to make sure that that behavior is encompassed within it
speaker-0 (22:20)
So for agent swarms or agentic engineering in general, how does it work across teams? Like you set up your swarm, but like how do you make that work across a larger organ ⁓ engineering organization?
Chris Bunk (22:33)
For sure. A lot of engineering organizations that I talk to and see, they kind of like, hey, let’s hook everybody up with Claude Code or similar kind of tool or tools. And they say you can do your normal job, just use agents in it. And the reality is to get a high performance stack up, you got to go in and create those subagent definitions tuned to your stack, tuned to your practices and policies that knows about all this kind of fundamental knowledge that you have, like that might be in a wiki or whatever, like your spec type knowledge ⁓ associated with it. It’s not all in source code.
And so setting all that up individually by individual individu people on the team or different teams, they’re going to have essentially some ⁓ you know, one, you gotta repeat that effort off with everybody or at least whatever level they go in and build it, which is why it’s way better to have a deliberate shared way to be able to go in and empower people to work at these higher levels of agentic engineering, which requires deliberate planning ⁓ and thought put towards it. Like one example.
Having a vector store, ⁓ which is like a data store that allows you to look for similar content based on what you’re looking for. and it’ll search large, it could index and search across large ⁓ bodies of of knowledge. Could be your code base, but most tools do that out of the box. But you wanna like incorporate in your wiki if it’s got all your product documentation ⁓ and other potential data sources, and it indexes it. It makes it real easy to find it. So a really good stack can go pull that into the context window, the right.
data that’s needed overall. ⁓ and so that’s that’s what I would say is like the key part of that.
speaker-0 (24:10)
Okay, so that makes sense. And obviously you don’t want a bunch of snowflake configurations out there where people are like doing their own thing. ⁓ so like all this, of course, is happening really, really fast. And I feel like even within the last year, we’ve kind of gone from like people maybe even being a little embarrassed they’re using agentic development to like now it’s just a requirement and like if people are getting left behind if they’re not adopting it. But to kind of get it more to like the human level here.
⁓ how do you what what are like key things to pay attention to to get your team to adopt engineering, agentic engineering in a in a way that allows them to do their their best work in a healthy way? Like how do you address the human side of adoption with your engineering team?
Chris Bunk (24:57)
For sure. So ⁓ There’s a bunch of things I think that are that I’ve learned or ⁓ validated or even some have invalidated. But one is you have to still keep the responsibility with the human being that the code being pushed out as to the standards that the company expects. Claude ate my homework is not a valid excuse, right? Like at the end of the day, I don’t care if Claude wrote your code that you have to be in there. And that in turn is a forcing function, right? Because
You know, it takes time for people to learn the tools and the new workflows. And so if they’re responsible, if a bug goes into production, if you know something were to bad to happen, like they’ve over the years, traditional development, we’ve we’re used to this. The PR review, you have the initial author and the PR reviewer kind of have a degree of responsibility over what goes into production. And so until a team member has enough confidence with the tools and what they could do and that they have they shift their normal verification validation, you know, anchor.
that they have into a higher level, they’re not going to be able to go in there and ⁓ you know, be able to have confidence with it. That I think’s one of the longer tail things is people kind of go in their agentic engineering journey that you can’t rush that fast. There’s no just trust me or just go with it type of thing with it. You know, you need them to understand what’s happening, what the tools can do, and to have enough confidence in that ⁓ security layer that exists overall in it.
There’s a lot of reactions people have when they get into this. particularly if they maybe did stuff early and kind of said, it’s not ready for prime time or whatnot, and then woke up, say, after November when the newer anthropic models that were particularly a leap in my mind in terms of efficacy. That’s where you started to see really good engineers go, wow. Right. Like I had I had one engineer once say to me, like,
Man, I’m glad I’m towards the end of my career. I don’t know how much is gonna last. So sometimes you go into like the doomer kind of mindset. I don’t actually subscribe to that. Everybody’s gonna be a force multiplier, ⁓ that or have a force multiplier that they didn’t before. And I think it’s gonna be measured in hundreds of percent or X factors. It’s not just like 20, 40% improvements that companies just dabbling in and see right now. And when you have that higher level ⁓ impact that you could do with it.
Yeah, like we’re not a cost center generally in software. We’re often a value creator. And I’ve never been somewhere where we didn’t want to build way more than we could. Even when I was pretty well at companies that had a lot of funding. So I’m I’m a believe believer that ⁓ I always pronounce this one wrong too. Devon’s paradox Devon’s paradox or j j Jevon’s paradox. What those? Anyways. Yeah. So it it’s where basically the
cheaper something gets, the more demand there becomes for it. Right. And so you might have back in the day when electricity came into the scene going, I got enough for my six light bulbs in my house. This is going to be the end. The market, it’s going to be hyped, you know, we don’t need more electricity. But quickly people found more uses as electricity got cheaper for, hey, you know, I got a dishwasher now. Woohoo. So ⁓ you know, there’s all this ⁓ you know, buildup associated with it. I suspect software engineering is going to be largely like that.
Unless it’s actually an organization that does treat software or their software stack as a cost center. Like if there’s just a fixed stuff set of stuff they gotta do, sure, maybe they don’t need to do way more stuff. But even then I would challenge them to rethink from first principles of what’s possible with going way faster and way cheaper.
speaker-0 (28:33)
So making them making sure they understand they’re responsible for the output. So no Claude ate my homework, reinforcing the need for the expert in the loop. We we we need your expertise to make this good. And then it’s interesting, and I I guess like a a D V is a maybe it’s the D V paradox, is there’s I what I always say is there’s more ideas than time.
Yes. So as we become more efficient, all those ideas that are filling up everybody’s backlogs and and the even bigger ideas that we don’t have time for, we’re now gonna have more time to be able to address those things. And so maybe we run out of ideas at some point, but ⁓ at least we’re we’re we we don’t see line of sight to that probably today. ⁓ even in the efficiencies we’re seeing, and at least for a good long time, we’re gonna need that expert in the loop. So like
some non technical exec like myself can’t roll in and like make the next production feature for our platform. that that’s not gonna happen. We’re we’re always gonna need that engineering expert in the loop.
Chris Bunk (29:39)
Prototype
the next killer idea, by the way.
speaker-0 (29:42)
Sure, sure, sure. Yeah, but not ship it to production, right? Yeah. That’s cool. ⁓ so we’re where so we talk about the future a little bit here, but where do you think all this is going? Like obviously we’re abstracting out a lot of like the kind of grind work in in the engineering world. What where do you think this is all going?
Chris Bunk (30:04)
I think you’re gonna start to see You’re starting to see it in the very earliest of companies, but as companies journey and get to the spot where they can create product value per headcount at like a five X, 10X really big factor, we’re gonna start to see certain companies take off. We’re gonna start to see I mean it’s gonna be great for ⁓ user experiences, right? Like they like they’re gonna get way more functionality, things are gonna get far more robust.
far more healthier, right? That’s the whole cost of it going down associated with it. And ideas that didn’t make any sense before because of their effort that would be taken and the risks associated with it. You gotta keep going back to first principles. But there’s gonna be the surge of value creation that’s going to happen across the space. Some companies are going to be quicker to adopt it, some are going to be slower. The ones that are going to be quick are probably going to eat the slower companies lunch. And there’d be new companies that come out of the ⁓ the the wildfire ashes, so to speak, that are going to emerge that that
wouldn’t make sense before were the same companies that previously went into the startup graveyard because of the costs or complexities of trying out those concepts. Those are all now gonna be viable and on the table. And some stuff we’ve never even thought of.
speaker-0 (31:16)
Unlocking big ideas. I like that that view of the future. ⁓ so ⁓ that’s that’s fair advice or fair observation. All right. Well, we covered a bunch of topics here today. So my last question would be if people only remembered one thing you said today, what do you think that should be?
Chris Bunk (31:37)
I think that
Going on and thinking of your agentic journey that your product engineering team or company might undertake to be able to unlock those value levers, it is focus on the actual value that you could realize on it and understanding it’s a journey and that it can’t be done overnight. Like even if you know all the things and know how to go in and operate at a very high level of agentic maturity, it takes time to get a whole team of humans to come along with you and to learn those skills, get comfortable enough, learn the strengths and weaknesses of these new tools.
and get adjusted to them to be able to go in and start introducing the value. So treat it as a journey with various stops along the way with various goals in the way.
speaker-0 (32:18)
I like that observation. Treat it as a journey. And I love how you also focused that last point on the people element of it and kind of bringing all that together to help drive value. Well, this was awesome. Thanks so much for joining us today, Chris.
Chris Bunk (32:32)
Well, thanks for having me on. Always fun to talk with you.
speaker-0 (32:35)
Absolutely. If you’d like to learn more about Chris’s up to, you can check out fastspring.com. Thanks everyone for joining Growth Stage. Again, I’m your host, David Vogelpohl. I support the digital product community as part of my role here at FastSpring. And I love to bring the best of the community to you here on Growth Stage. Bye, everybody.
Chris Bunk (32:59)
Take care.
