WEBVTT
00:00:00.000 --> 00:00:05.724
AI is changing the way we all work and technology professionals are no exception.
00:00:05.724 --> 00:00:14.711
The availability of GitHub Copilot, Claude Code, is changing the way we work with the machines as we're coding.
00:00:14.711 --> 00:00:23.387
And so very pleased to discuss the future of software engineering with Manjunath Bhat, uh distinguished VP analyst at Gartner.
00:00:23.387 --> 00:00:24.257
Welcome, Manju.
00:00:24.257 --> 00:00:24.875
Thank you, Jon.
00:00:24.875 --> 00:00:25.893
Thanks for having me.
00:00:25.893 --> 00:00:29.077
It's a pleasure to talk to you, Manju, always.
00:00:29.077 --> 00:00:38.345
You've been a keynote speaker at API Days Singapore the last couple of years and also recently at API Days Australia.
00:00:38.345 --> 00:00:48.444
And I know that you've done a lot of research about software engineering and you're tracking very closely the changes in the way we do software engineering.
00:00:48.444 --> 00:00:56.954
Can you sort of give us a picture of what of what's been the most dramatic change that you've seen in last year or so.
00:00:56.954 --> 00:01:09.352
Yeah, I think that that's a good place to start and I will call out, I think for the purpose of listeners to this podcast and who may not be familiar with what I do or what our team does.
00:01:09.352 --> 00:01:13.635
So as you said, I'm part of Gartner, part of Gartner's software engineering practice.
00:01:13.635 --> 00:01:26.373
And one of the many analysts who focus on the impact of AI on software engineering plus also the other side, which is how you're starting to see uh a new software development lifecycle emerge for AI.
00:01:26.373 --> 00:01:29.647
So literally this is, we're seeing this play out in two ways.
00:01:29.647 --> 00:01:35.102
What we're calling AI native software engineering, which is impact of AI on the traditional SDLC.
00:01:35.102 --> 00:01:43.760
And then the rise of what we can think of as the agent development lifecycle or the ADLC, which is the SDLC for AI.
00:01:43.760 --> 00:02:02.612
I think with that background, one of the big shifts, if you ask me, Jon, I call out, think this big shift in the last few years has been where software engineering has moved primarily from being something that is human driven, but AI augmented to being now agent driven and human augmented.
00:02:02.612 --> 00:02:07.975
So I think that is at the core of many of the subsequent shifts we are starting to see.
00:02:07.975 --> 00:02:20.683
And when I say like, you know, AI augmented versus something that's driven, think of this as like when this entire wave started, it almost felt like, well, we'll continue to work within our IDE, right?
00:02:20.683 --> 00:02:24.786
So, and you'd have these developers actually tabbing through functions.
00:02:24.786 --> 00:02:27.426
So function was the unit of change.
00:02:27.426 --> 00:02:38.054
And so we, think as we started moving from just like these tools, like suggesting functions to now implementing entire functionality, right?
00:02:38.054 --> 00:02:45.908
So that at its heart is the shift from AI moving from being an assistant to being a long-running agent, right?
00:02:45.908 --> 00:02:51.205
So, I mean, metaphorically, people have said, oh, well, agents have become coworkers.
00:02:51.205 --> 00:02:59.979
So we are sort of less inclined to use that term because on one hand, it denigrates uh the real meaning of what is a coworker, right?
00:02:59.979 --> 00:03:12.556
So even we've tried to stay away from the term peer programmer because if you think of those actual human terms, you would assume that uh humans actually, we improve learning from our peers.
00:03:12.556 --> 00:03:19.682
So there's a very healthy learning loop, but these agents, at least until now, they don't demonstrate online continuous learning.
00:03:19.682 --> 00:03:23.014
So which is why we still prefer to call them like long running agents.
00:03:23.014 --> 00:03:39.377
So I think if you ask me the big shifts, like I discussed, like human driven to being agent driven, I think the other thing is also what this has meant is that it's also, I think on the positive front, You can think of humans are now like as in we are able to, you know this paper, right?
00:03:39.377 --> 00:03:44.099
Backing up attention is all you need was this transformative paper on transformers.
00:03:44.099 --> 00:03:52.979
Well, what that also means is human attention is not only important and it's human attention is actually a scarcer commodity, right?
00:03:52.979 --> 00:03:55.024
Attention in that paper refer to something else.
00:03:55.024 --> 00:04:05.872
But if we now look at the impact it has had on the way we work, it's not just knowledge that's uh important, but where we drive our attention, right?
00:04:05.872 --> 00:04:30.829
where we, and I think with this long running agents, what it has enabled we as humans to do is it's enabled us to direct our attention in areas that matter most, whether it is in terms of business impact, if we are in the corporate world, or uh if we're working on a hobby project, we can just get to some desired outcome as soon as possible, just completely eliminating friction in the process.
00:04:30.829 --> 00:04:47.043
I think from what I've seen, every programming course I've ever tried before in the last 30, 40 years, every programming course has always started with a Hello World application.
00:04:47.043 --> 00:04:58.430
And it sounds silly to only put up Hello World on the screen, but in the past, it's been very difficult to get to Hello World because you have to set up an entire environment.
00:04:58.430 --> 00:05:00.062
You have to understand the syntax.
00:05:00.062 --> 00:05:01.973
have to get their syntax right.
00:05:01.973 --> 00:05:08.065
And the early compilers, interpreters would punish you quite severely for not getting it right.
00:05:08.065 --> 00:05:11.379
And you just get syntax error or no response at all.
00:05:11.379 --> 00:05:17.994
But you can get to Hello World now with one of these AI coding assistants almost instantly.
00:05:17.994 --> 00:05:33.261
And I'm interested in your comment about pair programming because pair programming is about a dialogue between people, peers who exchange ideas and the whole is greater than the sum of the parts.
00:05:33.261 --> 00:05:46.935
You can get a conversation out of an AI coding assistant, but I think your point is that it's more like an assistant or a, I've heard some people describe it as an enthusiastic intern.
00:05:46.935 --> 00:05:48.528
They won't always get it right.
00:05:48.528 --> 00:05:54.721
they can come up with some exciting things that are always interested in creating something, but it won't necessarily be the right thing.
00:05:54.721 --> 00:06:00.274
And you have to adjust and make it go back and backtrack a few things.
00:06:00.274 --> 00:06:12.377
I guess use your own expert knowledge of what good looks like in order to iterate with the coding assistant to get to where you want to go.
00:06:12.377 --> 00:06:22.507
are following the best practices that, know, is that a, is that where you see things are now and more of that, or where do you see this heading?
00:06:23.023 --> 00:06:29.329
I think if we think about it, like you said, AI has made it very easy to uh build a prototype.
00:06:29.329 --> 00:06:37.136
I think the real gap is from taking a prototype to production, which is where we still see a lot of friction.
00:06:37.136 --> 00:06:44.091
So I completely agree that if you just want to build a Hello World program, it's become a no-brainer.
00:06:44.091 --> 00:06:48.048
In fact, it has lowered the barriers, which is why it's a good sign for the industry.
00:06:48.048 --> 00:06:53.442
because you can have so many, even people from outside the traditional tech sector, right?
00:06:53.442 --> 00:07:03.663
So, and people who would have thought, this programming is something that's an arcane kind of technology, and probably outside of my realm, now it feels within reach.
00:07:03.663 --> 00:07:12.502
And even within the tech sector, you find that product owners who might have stayed away from development thinking, I, all I can do is build a wireframe, but...
00:07:12.502 --> 00:07:18.406
with these kind of tools, now they can go beyond a wireframe and see something actually working.
00:07:18.406 --> 00:07:23.187
So in many ways, it has bridged this gap between different roles.
00:07:23.187 --> 00:07:35.576
So between product owners and engineers, plus also for engineers, I think the biggest benefit, I think this is an important one to call out, is that it's dramatically improved the pace at which you can experiment.
00:07:35.576 --> 00:07:40.173
And so the cost of experimentation is almost like hitting zero.
00:07:40.173 --> 00:07:47.166
you can try out n number of experiments with almost zero cost and then decide, okay, this is the path I'm going to go to.
00:07:47.166 --> 00:07:51.672
And taking that prototype to production is where all of the friction lies.
00:07:51.672 --> 00:07:54.473
So that's maybe one way to think about this.
00:07:54.473 --> 00:08:06.915
And the other comment about pair programming is still, if you look at, for instance, where pair programming really becomes valuable is, it's one human judgment versus another human judgment, right?
00:08:06.915 --> 00:08:17.747
So I think this is the essence of the difference where what you'll start to see is increasingly with these agentic workflows, it's making coding a very execution focused activity.
00:08:17.747 --> 00:08:23.341
So the value is no longer just in the art and science of producing that code.
00:08:23.341 --> 00:08:28.916
the value of implementing something is becoming lesser and lesser.
00:08:28.916 --> 00:08:33.770
where there's huge value is like in the, what we call, you know, executive function.
00:08:33.770 --> 00:08:39.033
So think of this as humans being valued not as much for execution, but for executive function.
00:08:39.033 --> 00:08:51.559
Now that executive function can manifest itself in good decision-making, you good judgment, your ability to sense whether this is the right thing to build, building like customer trust, user trust.
00:08:51.559 --> 00:08:57.376
And if we look at bad programmers, this was really two humans exercising this kind of human judgment.
00:08:57.376 --> 00:09:00.038
with the agentic workflows so far, right?
00:09:00.038 --> 00:09:06.985
It's still like, you don't get the same feeling that you are looking at another person's like human judgment.
00:09:06.985 --> 00:09:09.458
So which is why I sort of hesitate.
00:09:09.458 --> 00:09:15.885
And in fact, that one of the big downsides, if you look at in recent times, there's been this huge trend about vibe coding, right?
00:09:15.885 --> 00:09:19.240
One of the downsides of vibe coding is also for the developer.
00:09:19.240 --> 00:09:22.360
there's no quick iterative learning mechanism in place.
00:09:22.360 --> 00:09:29.157
So you don't, because with vibe coding, almost, you assume that you don't care about the code, which is why it's really good for building prototypes.
00:09:29.157 --> 00:09:36.460
But for production grade software, you do want the human developer, the person using these tools to also improve, right?
00:09:36.460 --> 00:09:43.173
And not only that, you also expect that the tools will improve, which is, I think, a twofold downside to this process.
00:09:43.173 --> 00:09:45.667
It's a limitation right now that the...
00:09:45.667 --> 00:09:52.500
by completely offloading work to an AI, we are not learning in the process unless we consciously choose to.
00:09:52.500 --> 00:10:00.465
And the other limitation with these LLM models or AI or agentic coding tools is it's not learning continuously either, right?
00:10:00.465 --> 00:10:06.190
So that is where most of the new like infusion of innovations is happening, Jon.
00:10:06.190 --> 00:10:09.692
So if you look at, maybe if you ask me, where's the...
00:10:09.692 --> 00:10:12.442
broader surface area of innovation, I'd say context, right?
00:10:12.442 --> 00:10:15.504
And which is why like context engineering is important.
00:10:15.504 --> 00:10:30.631
And so in many ways, we started with these tools like essentially become innovating at the experience layer, but fast forward now and in future, you'll find that if they have to continuously improve, they got to innovate at the context layer, right?
00:10:30.631 --> 00:10:33.634
So context layer becomes the new innovation surface.
00:10:33.634 --> 00:10:43.445
So I find it's certainly a productivity improvement and I'm not a great fan of hand coding, HTML, CSS.
00:10:43.445 --> 00:10:53.554
So the coding assistant certainly takes away a lot of that legwork to set up a page or or a set of functions.
00:10:53.554 --> 00:10:59.820
I guess to your point is the context really has to come from me as the coder.
00:10:59.820 --> 00:11:06.745
I have to say not only do I want a page that has these characteristics, but it has a particular purpose.
00:11:06.745 --> 00:11:22.347
And then I found it does accelerate the cycle ah because even if you're hand coding everything, you would start with a small a small program and then start to add functions on top of that because you need to be able to test as you go.
00:11:22.347 --> 00:11:25.631
No point writing 10,000 lines of code and then start testing.
00:11:25.631 --> 00:11:26.802
It's not going to work.
00:11:26.802 --> 00:11:28.982
You have to test a little bit.
00:11:28.982 --> 00:11:34.287
there is still a cycle that you should go through, a build, test, learn cycle.
00:11:34.287 --> 00:11:44.715
But I think to your point is that it's up to the human to tell the assistant, you need to start heading in this direction.
00:11:44.715 --> 00:11:49.591
And I haven't found when I've said, well, actually that file's getting too big.
00:11:49.591 --> 00:11:54.556
Can you break it out into two or three files by function?
00:11:54.556 --> 00:11:57.008
Or there are some hard coded variables there.
00:11:57.008 --> 00:12:00.162
uh Can't you create a configuration file?
00:12:00.162 --> 00:12:04.336
That configuration file is not protected anywhere.
00:12:04.336 --> 00:12:07.467
It's exposed in the repository.
00:12:07.467 --> 00:12:08.299
Can you put that?
00:12:08.299 --> 00:12:23.160
So having to constantly remind or ask the assistant to build out something that's going to be more secure, more scalable, more production ready is still on the expert.
00:12:23.160 --> 00:12:26.825
So where do you see our expertise?
00:12:26.825 --> 00:12:47.331
going into though you talked about executive function but the executive function is sort of thinking a little bit about the context but it's also having an understanding of what is what is compliant what is secure what is what is what is scalable what's cost-effective also for the for the company Yeah, 100%.
00:12:47.331 --> 00:12:51.734
So I think oh a few thoughts responding to that.
00:12:51.734 --> 00:13:01.496
One, if you look at uh recent trends that have surfaced to mitigate those kind of issues that you mentioned, one primarily is spectrum in development.
00:13:01.496 --> 00:13:16.342
So I think that has emerged as one of the ways where you can overcome the limitation of traditional vibe coding, where it was primarily meant as a stateless interaction mode between the developer and the assistant.
00:13:16.342 --> 00:13:20.784
And as soon as the developer exits the session, all context is lost.
00:13:20.784 --> 00:13:23.086
So that was a huge limitation.
00:13:23.086 --> 00:13:29.318
So you're not essentially uh giving sufficient context to the agent.
00:13:29.318 --> 00:13:38.083
So with specs, we can think of specs as a mechanism to steer the agent to do what we expect it to do.
00:13:38.083 --> 00:13:52.035
Now, it's not necessarily uh meaning that specs It's spec-driven development and not necessarily that the agent, because it's non-deterministic fundamentally, you can't expect it to be a spec-fulfilling agent.
00:13:52.035 --> 00:14:01.860
So I think we got to maybe set that expectation that just merely by creating a specification, we can't guarantee that the agent adheres and complies with that specification.
00:14:01.860 --> 00:14:05.413
So it's just a way for us to ensure standardization.
00:14:05.413 --> 00:14:07.754
It's a way to ensure consistency, right?
00:14:07.754 --> 00:14:10.355
So governance uh rules are in place.
00:14:10.355 --> 00:14:14.798
I mean, I am starting to look at specs in a two-fold manner.
00:14:14.798 --> 00:14:23.832
One is, if you are, let's say, a platform engineering team, if you are part of the security and risk team, you want your governance policies codified.
00:14:23.832 --> 00:14:28.794
And what's the best way to codify and institutionalize those policies?
00:14:28.794 --> 00:14:30.455
Well, that would be specs.
00:14:30.455 --> 00:14:32.032
I see you mentioned cloud code.
00:14:32.032 --> 00:14:36.544
So you might put that in a .md file for Claude and all of the markdown files.
00:14:36.544 --> 00:14:45.774
So that becomes uh a vehicle to, in fact, serve this twofold purpose of improving developer productivity plus also meeting governance needs.
00:14:45.774 --> 00:14:48.466
So I think that's one huge benefit.
00:14:48.466 --> 00:14:56.650
The other thing that also becomes important is, know how, like think going back 20 years ago, one of my favorite books was Martin Fowler's Refactoring.
00:14:56.650 --> 00:14:59.193
He's one of his very popular books as well.
00:14:59.193 --> 00:15:02.907
And I almost thought that, well, has refactoring gone out of fashion?
00:15:02.907 --> 00:15:10.423
But in fact, you can think with AI augmented or AI native coding, refactoring might actually see a resurgence.
00:15:10.423 --> 00:15:23.258
So it's probably, refactoring has never been as important because as AI keeps generating more and more code, we've got to compensate for all of the newly generated code to make sure it's also continuously refactored.
00:15:23.258 --> 00:15:25.870
So I think that is extremely important.
00:15:25.870 --> 00:15:26.981
Who does the refactoring?
00:15:26.981 --> 00:15:34.066
Probably is a moot point that you can still direct the agent to refactor code, but refactoring is important.
00:15:34.066 --> 00:15:39.571
The other thing that also becomes important is verification and validation harnesses.
00:15:39.571 --> 00:15:47.496
when you have such a huge amount, such a huge volume of new code being generated, it's just implausible, right?
00:15:47.496 --> 00:15:59.217
So I mean, it's unthinkable that you can just have humans verify every line of code that is being generated or like, you you just can have human in the loop and human oversight.
00:15:59.217 --> 00:16:03.592
It's good in theory, but you would very soon find humans as the new bottleneck.
00:16:03.592 --> 00:16:19.278
And so if we got to overcome that, what might need to happen is our, like the success with these agentic coding tools is directly proportional to the degree to which we have a very high degree of verification and validation maturity.
00:16:19.278 --> 00:16:25.576
So which means a uh fast inner loop will also require a faster outer loop.
00:16:25.576 --> 00:16:28.279
So I think that is how I'm thinking about it.
00:16:28.279 --> 00:16:55.791
So you touched on some things and I guess we started talking about individual programmer productivity and now you're talking about what it means to the enterprise because the enterprise needs to enforce some standards that should encourage certain patterns to be used, if only for the sake of readability by other developers, but also to your point about validation.
00:16:55.791 --> 00:17:19.017
And in a sense, before generative AI, we were automating testing, we were setting style guides for an organization, architects would create patterns and even anti patterns don't do this to an organization, but it would have to be enforced manually because manual code reviews are very, very time consuming, and no organization really gets to do it.
00:17:19.017 --> 00:17:20.929
100 % of the time.
00:17:20.929 --> 00:17:35.670
And the linters that have been used to verify compliance with a style guide, are often, then it still requires a judgment because there's a tension between standardization and innovation.
00:17:35.670 --> 00:17:47.318
Standardization is very valuable because you can validate things, you can verify that things are not going to go out of control, but you'll only ever get the same as what you had before.
00:17:47.318 --> 00:17:50.029
You won't get new things unless you innovate.
00:17:50.029 --> 00:18:10.018
So the linters that were put in place, they may come up with a, identify a violation of a style guide and then someone, some senior engineer would have a conversation with the less senior engineer about why they should uh or should they really conform with a pattern.
00:18:10.018 --> 00:18:18.606
But for organizations to manage that, I guess what it means is that it's not enough just to automate a simple rules-based system.
00:18:18.606 --> 00:18:24.089
you have to get another agent to look for what can go wrong with this.
00:18:24.089 --> 00:18:26.674
Where do you see that evolution occurring?
00:18:26.674 --> 00:18:32.780
Is that going to be built into the tools or do we need an external set of tools that are going to...
00:18:32.780 --> 00:18:52.394
think a couple of ways this will start to unravel is that even now when we're looking at our uh IDEs, and by the way, my favorite like acronym, like think of this as mutating an acronym is, I say IDEs are not just integrated development environments, they're now intelligent development environments, right?
00:18:52.394 --> 00:18:55.662
So that's the new IDE, if you will.
00:18:55.662 --> 00:18:59.853
In these intelligent development environments, it's no longer just assistance.
00:18:59.853 --> 00:19:03.663
We've gone from assistance within the IDE to single agents.
00:19:03.663 --> 00:19:08.256
But to your point, Jon, coming to what you're describing is these are multiple agents.
00:19:08.256 --> 00:19:15.357
So if you look at tools like whether it's Amazon Kiro and Cursor and few others, they've started using the term sub-agents, right?
00:19:15.357 --> 00:19:24.651
So it's actually an orchestrator agent that spins off and works with orchestrates, a bunch of sub-agents.
00:19:24.651 --> 00:19:31.651
So you can sort of imagine that there are subagents who will keep a watch on what the other agent has produced.
00:19:31.651 --> 00:19:36.904
So in a sense, one subagent is going to verify the code of another subagent.
00:19:36.904 --> 00:19:48.058
if we are worried about agents grading their own homework kind of a problem, I think what this is also coming out to be is that, you will not just have like one model.
00:19:48.058 --> 00:20:00.866
So maybe you use the developer or the coder subagents to use one model, maybe a GPT 5.2, 5.3, and then the verification subagent could be a Claude model, a Claude Opus and so on.
00:20:00.866 --> 00:20:10.195
So in that sense, you're still taking advantage of agentic verification without just maybe like just overly relying on one model doing it all.
00:20:10.195 --> 00:20:11.576
So that's one thought.
00:20:11.576 --> 00:20:29.963
the other one is, I think on the positive side, I'm starting to see how a lot of the knowledge used to be considered tribal knowledge, everything that exists maybe in a senior engineer's head, we resorted to maybe using Confluence and a few other tools to institutionalize that knowledge.
00:20:29.963 --> 00:20:42.299
But it generally became a very passive source of knowledge for the organization because there was no good way to uh weave that knowledge residing in those sources of truth or systems of record like Confluence, right?
00:20:42.299 --> 00:20:43.200
And weave that in.
00:20:43.200 --> 00:20:49.403
So which means you can think of agents as a um mechanism to institutionalize tribal knowledge.
00:20:49.403 --> 00:20:50.983
So which is huge, right?
00:20:50.983 --> 00:21:04.262
And so I have actually had calls on this topic where people are starting to think where as soon as this, you know, maybe as people start to retire as senior engineers, senior architects, there is a risk of them retiring from the workforce.
00:21:04.262 --> 00:21:05.056
How might...
00:21:05.056 --> 00:21:14.366
you think of retaining all of their decades worth of expertise that one, they have gleaned and they're yet to contribute.
00:21:14.366 --> 00:21:19.366
So in many ways, you can create like a digital twin of Jon Scheele, right?
00:21:19.366 --> 00:21:22.738
With your decades of experience, have an agentic version of yourself.
00:21:22.738 --> 00:21:26.489
So even after you've retired, junior engineers can tap into your expertise, right?
00:21:26.489 --> 00:21:29.079
So I think that that's a huge bonus point.
00:21:29.079 --> 00:21:42.218
The last one actually that comes to mind in that, in the enterprise is I was also thinking where we, when DevOps came along and it became DevSecOps, it was more about like how you wanted to bridge silos, right?
00:21:42.218 --> 00:21:44.579
And that was more of an operating model shift.
00:21:44.579 --> 00:21:53.353
But if you start looking at agents, now agents can actually start to bridge these silos between teams that otherwise might not have communicated.
00:21:53.353 --> 00:22:00.067
So I look at maybe, there's a DevOps agent that's uh having visibility into production issues.
00:22:00.067 --> 00:22:08.584
and it's passing on all of the insights to the development team saying, hey, this is a problem with the architecture that you currently have.
00:22:08.584 --> 00:22:13.627
These are the kind of issues I'm seeing every day and I'm probably fixing it on your behalf.
00:22:13.627 --> 00:22:18.431
So you better do this at the architect, take care of this at the architecture layer.
00:22:18.431 --> 00:22:21.334
Or maybe security teams have a use case.
00:22:21.334 --> 00:22:33.542
You might essentially say, if you look at vulnerabilities being fixed and determined, you can have those agents actually pass on that feedback to the security team who should have participated in threat modeling.
00:22:33.542 --> 00:22:49.064
So in effect, you will start to see the agent as a uh common, it's a common war room that is a virtual war room where it's bringing folks from architecture, development, security and ops together who might have otherwise not communicated.
00:22:49.064 --> 00:23:00.115
I think that brings to mind practices that people have promoted, but not so easy to put into practice.
00:23:00.115 --> 00:23:07.773
publishing a standard or a style guide or a pattern or an anti-pattern, documenting things, that...
00:23:07.773 --> 00:23:11.689
that only served a purpose if people would read those things.
00:23:11.689 --> 00:23:19.695
And in an organization, it was often very hard to get people to read and understand and follow all of those things.
00:23:19.695 --> 00:23:23.058
And then finding the right pattern to match up.
00:23:23.058 --> 00:23:29.553
the practicality of that is improved by having agents who can help you to locate it.
00:23:29.584 --> 00:23:31.506
in a more conversational way.
00:23:31.506 --> 00:23:37.641
Tell me what the pattern is when I'm trying to connect these two types of systems together.
00:23:37.641 --> 00:23:50.885
And we talked about platform engineering in the past and the idea that a platform is set up by the operations team to help guide the development team.
00:23:50.885 --> 00:23:58.064
to produce good code in the first place, but that is always a challenge to push that feedback loop back through.
00:23:58.064 --> 00:24:03.909
And I guess what you're describing is agents being able to facilitate that.
00:24:03.909 --> 00:24:08.773
So what do you see as a good platform engineering practice now?
00:24:08.773 --> 00:24:14.267
Yeah, so in effect, I think this is probably the best time to build a platform.
00:24:14.267 --> 00:24:18.549
So in effect, basically twofold impact on platform engineering teams.
00:24:18.549 --> 00:24:27.814
One, I think my other mutation of the acronym is IaaS, so where it's no longer just infrastructure as a service, it's intelligence as a service.
00:24:27.814 --> 00:24:31.035
So I think that internally is starting to play out.
00:24:31.035 --> 00:24:33.237
We did a case study with Verizon.
00:24:33.237 --> 00:24:38.077
We have also done another one with a healthcare services provider called Vizient.
00:24:38.077 --> 00:24:48.481
So in most of these large enterprises, you're starting to see platform teams actually step up, one, to make it easier to embed AI as part of the SDLC.
00:24:48.481 --> 00:24:49.362
That's one part.
00:24:49.362 --> 00:24:52.463
But also like we discussed, SDLC for AI.
00:24:52.463 --> 00:24:54.443
So that's, think, the second part of it.
00:24:54.443 --> 00:24:58.439
Now, the way platform engineering teams can use this is it's...
00:24:58.439 --> 00:25:12.816
In many ways, think using guardrails, platform engineers typically found it very difficult to enforce these governance policies, but they resorted, I think the best tools they had at their disposal was templates.
00:25:12.816 --> 00:25:19.394
So if you look at the likes of Backstage, which is famously used for just allowing templatized workflows.
00:25:19.394 --> 00:25:24.778
So if you want to build maybe a new Node.js service and new microservice use this template.
00:25:24.778 --> 00:25:29.644
And you can spin up like a Hello World service very quickly if you use templates.
00:25:29.644 --> 00:25:38.832
And the benefit of templates is that on one hand, it complies with what the platform engineering team needs, but on the other hand, it also like just improves developer experience.
00:25:38.832 --> 00:25:44.917
I think these kind of templatized workflows was the only tool that the platform team said.
00:25:44.917 --> 00:26:00.144
But now if you look at agentic tools, Yes, you'll start to see, well, of course they will have to permit the use of agents, but what you'll start to also, I think the big responsibility on the platform team is governance of those agents.
00:26:00.144 --> 00:26:09.361
And I think, when I say governance, I mean, it's not just from a security perspective, also looking at, for instance, how much is it costing the organization, right?
00:26:09.361 --> 00:26:21.195
So I forget the actual source, somebody said that, you're not doing enough, you're not utilizing AI to its fullest potential unless you spend$1,000 per engineer, right?
00:26:21.195 --> 00:26:26.192
So I think now people are, it's costing a lot as well when you use these tools.
00:26:26.192 --> 00:26:31.576
And with every new release, by the way, of Anthropic Claude the cost just tends to go up, right?
00:26:31.576 --> 00:26:32.426
It's not coming down.
00:26:32.426 --> 00:26:36.561
So the better the model is, the greater the reasoning capabilities, those all come at a cost.
00:26:36.561 --> 00:27:01.647
I think in short, there's a huge need for platform engineering teams to establish one guardrails, but also put in place governance around costs, governance around expected reliability, scalability, and essentially all of the non-functional requirements that a service should meet before it gets to production.
00:27:01.647 --> 00:27:14.487
So in effect, think platform engineering teams now not only have to govern the way traditional like software is being developed, but they also have to govern the tools that will produce these artifacts.
00:27:14.487 --> 00:27:15.807
One last comment, by the way.
00:27:15.807 --> 00:27:21.502
So I think um since you brought this up, I've been noticing a pattern with these mismatches.
00:27:21.502 --> 00:27:28.036
And I think this is where this This might be an opportunity for platform engineering teams to work closely with product teams.
00:27:28.036 --> 00:27:33.339
And when I talk of mismatches, I'm referring to, let's say for instance, this cadence mismatch.
00:27:33.339 --> 00:27:37.122
So the cadence mismatch is uh productivity versus security, right?
00:27:37.122 --> 00:27:39.982
So that's been a huge mismatch there.
00:27:39.982 --> 00:27:45.615
And one way to bridge or close that gap is platform engineering, to the rescue.
00:27:45.615 --> 00:27:47.527
That's one way to think about this.
00:27:47.527 --> 00:27:50.897
The other is you can think of it as an impedance mismatch.
00:27:50.897 --> 00:27:57.180
So impedance mismatch is, if you look at what we expect from applications, it's deterministic.
00:27:57.180 --> 00:28:01.571
But the tools we're using to build those applications is actually non-deterministic.
00:28:01.571 --> 00:28:10.540
it's fundamentally an impedance mismatch between a non-deterministic tool and our expectation for it to produce deterministic artifacts, right?
00:28:10.540 --> 00:28:14.563
So that's another mismatch that the platform engineering team has to resolve.
00:28:14.563 --> 00:28:17.515
And the third one is fundamentally accountability.
00:28:17.515 --> 00:28:25.009
Like you made a point earlier on where you said the accountability still has to sit with the human engineering team.
00:28:25.009 --> 00:28:26.692
And that is absolutely true.
00:28:26.692 --> 00:28:39.008
So there is this accountability mismatch where agents are doing a lot of the work that we would otherwise have done, but we are expected to continue to take accountability even if we have not done the work.
00:28:39.008 --> 00:28:43.951
So that actually places an enormous burden of accountability on us.
00:28:43.951 --> 00:28:49.010
and we may not be intimately familiar with everything that's gone into building that artifact.
00:28:49.010 --> 00:28:52.682
There's a whole lot there that I could take apart, Manju.
00:28:52.682 --> 00:28:54.364
I mean, you mentioned cost.
00:28:54.364 --> 00:29:10.226
And I think one of the things we should be a little concerned about is, yes, you can use an AI coding assistant to produce just about any code that you want, but sometimes it's using a hammer to crack a nut.
00:29:10.226 --> 00:29:12.299
And it's an expensive hammer.
00:29:12.299 --> 00:29:18.634
at times when it's just turning through doing things that are really quite simple and you could automate.
00:29:18.634 --> 00:29:44.999
And sometimes I feel you probably should use the tool to produce a program that will do the thing that you want to do rather than get the AI agent to actually complete the task because it's going to use up tokens to do it, whereas program can repeat itself over and over again at much lower cost without consuming all those tokens over again.
00:29:44.999 --> 00:29:55.977
are we in danger of seeing what happened to cloud computing where everybody thought, oh, it's so much cheaper because you only pay for what you use.
00:29:55.977 --> 00:29:59.179
And then everybody started using to do so much more.
00:29:59.179 --> 00:30:01.540
What sort of controls to companies.
00:30:01.540 --> 00:30:02.672
You mentioned platform teams.
00:30:02.672 --> 00:30:06.202
Is it just the platform team or is it the finance team as well?
00:30:06.324 --> 00:30:15.001
What does the finance team in an enterprise need to understand now about how to manage the use of these agents?
00:30:15.001 --> 00:30:18.955
Yeah, I think overall, if you look at it, let's tackle the last point you made.
00:30:18.955 --> 00:30:23.428
platform team serves as the abstraction layer.
00:30:23.428 --> 00:30:25.078
I'm using this term very loosely.
00:30:25.078 --> 00:30:31.603
So it's taking what the finance team wants the organization to do to stay true to.
00:30:31.603 --> 00:30:39.788
So it converts the needs of the finance team and translates it in a self-service manner to how the engineers can consume the platform.
00:30:39.788 --> 00:30:50.176
So it's basically saying, well, you engineers, you can use all the autonomy you have, but work within the financial guardrails that we have put in place.
00:30:50.176 --> 00:30:59.480
in effect, the platform engineering teams becomes the translation layer between what the finance team wants and what the engineering team wants to accomplish.
00:30:59.480 --> 00:31:01.563
So I think we are good on that front.
00:31:01.563 --> 00:31:05.105
And you can have cost guardrails, and you can have cost visibility.
00:31:05.105 --> 00:31:07.686
So all of that will play out nicely.
00:31:07.689 --> 00:31:16.532
Then the other consideration, I think the other point you were referring to is on the precursor or the precedent we have with cloud computing.
00:31:16.532 --> 00:31:18.073
And I think that is fascinating.
00:31:18.073 --> 00:31:28.607
And if we want to extend that metaphor and that example, yes, and much the same way as people eventually realize that moving to the cloud is not just for cost reasons, right?
00:31:28.607 --> 00:31:29.589
So in fact, it's...
00:31:29.589 --> 00:31:36.284
we doubt that anyone who's maybe using cloud in the right sense actually has managed to decrease its usage.
00:31:36.284 --> 00:31:40.268
Eventually everyone's cloud expenses go up, right?
00:31:40.268 --> 00:31:41.368
And not down.
00:31:41.368 --> 00:31:44.269
So especially if you're trying to innovate, right?
00:31:44.269 --> 00:31:44.881
And so on.
00:31:44.881 --> 00:31:46.892
So cloud expenses will shoot up.
00:31:46.892 --> 00:31:52.857
So which means much like cloud became a business enabler and the true value of cloud.
00:31:52.857 --> 00:31:58.823
only comes when you can use the cloud to drive innovation that you would have otherwise not been able to.
00:31:58.823 --> 00:32:02.125
Very similar parallels exist in the AI world.
00:32:02.125 --> 00:32:09.388
it's probably very rare to very unlikely that somebody is going to use agentic coding tools to reduce costs.
00:32:09.388 --> 00:32:15.713
On the contrary, they might use agentic coding tools to drive new sources of revenue.
00:32:15.713 --> 00:32:19.645
to build stuff that might have otherwise seemed infeasible, right?
00:32:19.645 --> 00:32:24.259
So something that would have been uh from a business perspective, very unviable, right?
00:32:24.259 --> 00:32:35.058
So I think if we're just limiting the use of agentic coding tools to doing what we've always done, the cost implications are going to be huge and we might not be able to justify it.
00:32:35.058 --> 00:32:36.991
Thanks for sharing that, Manju.
00:32:36.991 --> 00:32:41.442
I think there's a lot to unpack in that.
00:32:41.442 --> 00:32:46.405
And great perspective on how our lives are changing.
00:32:46.405 --> 00:32:51.378
Can I just, perhaps as a final question, ask about where we're going to see?
00:32:51.378 --> 00:32:56.423
Because what you mentioned shouldn't be seen as simply a cost play, just as cloud computing.
00:32:56.423 --> 00:32:59.205
to reap the real benefits wasn't just about costs.
00:32:59.205 --> 00:33:05.819
One of the challenges at the moment is that some firms have decided they don't need as many developers.
00:33:05.819 --> 00:33:09.932
And that typically means they don't need as many junior developers.
00:33:09.932 --> 00:33:16.930
We both have children who just started university and the immediate future for a junior engineer.
00:33:16.930 --> 00:33:28.925
seems a little uncertain at the moment because senior engineers can get more done when they would have passed on some of those easier tasks to a junior engineer.
00:33:28.925 --> 00:33:42.346
How do you see us gaining the experience necessary to be productive in order to to be useful in an organization and to be employable in an organization.
00:33:42.346 --> 00:33:47.390
Yeah, and like you mentioned, Jon, I tell my son, who is in university now, is...
00:33:47.390 --> 00:33:50.580
In general, fundamentals are definitely going to be important.
00:33:50.580 --> 00:33:56.144
So the need for fundamental understanding of how software is engineered is not going to go away.
00:33:56.144 --> 00:33:58.175
So I'm very bullish on that.
00:33:58.175 --> 00:34:02.027
So that's one point I'll make, regardless of how software is being built.
00:34:02.027 --> 00:34:04.400
So engineering uh software is...
00:34:04.400 --> 00:34:15.873
I mean, if we assume that it is an engineering problem, the need for like foundational engineering concepts, which is whether it's architecture, design, security, reliability, resilience, right?
00:34:15.873 --> 00:34:17.643
Fail over redundancy.
00:34:17.643 --> 00:34:21.353
Those I think become increasingly important, not less important, right?
00:34:21.353 --> 00:34:22.643
So that's one point.
00:34:22.643 --> 00:34:39.324
I think uh the other thing to keep in mind, and especially if we have junior engineers or somebody who's in university listening to this, what they should not assume is that the next generation of software that we will build will bear a lot of resemblance to previous generations of software.
00:34:39.324 --> 00:34:43.438
So it's not going to be traditional, unintelligent, rule-based software, right?
00:34:43.438 --> 00:34:45.630
So it's not just automation software.
00:34:45.630 --> 00:34:48.711
So the nature of applications themselves will change.
00:34:48.711 --> 00:34:55.418
So which means we've got to just prepare for the world where every application is going to be intelligent by design.
00:34:55.418 --> 00:34:58.201
So I think that is the new reality.
00:34:58.201 --> 00:34:58.762
And so...
00:34:58.762 --> 00:35:09.101
it's inevitable that maybe if you're looking at today's job descriptions, you'll find there's this huge demand even now for AI engineers, right?
00:35:09.101 --> 00:35:18.682
Those job descriptions ideally should have been for a software engineer who knows AI, who understands AI engineering or who can implement AI engineering.
00:35:18.682 --> 00:35:23.336
If you fast forward maybe a few years, we can basically see the blurring of these lines.
00:35:23.336 --> 00:35:25.239
Every software engineer will...
00:35:25.239 --> 00:35:28.132
implicitly be expected to be an AI engineer.
00:35:28.132 --> 00:35:43.034
So there's not going to be a distinction between a software engineer and an AI engineer, which basically tells if you're in university, just know that you are entering a workforce that expects you to be an AI engineer and not necessarily a software engineer.
00:35:43.034 --> 00:35:45.356
So that could be another thought.
00:35:45.356 --> 00:35:45.967
What else?
00:35:45.967 --> 00:35:56.576
And I think the other thing is, uh for instance, Creativity, the foundational human skills, those are going to continue to remain core to what we do.
00:35:56.576 --> 00:36:02.893
If I go back to my example of we'll continue to use tools, tools will get better at execution.
00:36:02.893 --> 00:36:09.389
What we'll really get paid for will be our executive functions, curiosity, critical thinking, creativity.
00:36:09.389 --> 00:36:21.260
And in fact, we have a position that we actually published in our recent report where we say, that it's creativity and not productivity that's going to be the yardstick for measuring engineering excellence.
00:36:21.260 --> 00:36:23.601
And maybe that's a good thought to end on.
00:36:25.141 --> 00:36:27.222
Thanks very much for sharing that, Manju.
00:36:27.222 --> 00:36:29.394
Always a pleasure to talk with you.
00:36:29.394 --> 00:36:37.152
And I'm looking forward to your keynote at API Days Singapore on the 14th and 15th of April.
00:36:37.152 --> 00:36:41.266
Thanks very much, and see you again soon.
00:36:41.266 --> 00:36:42.271
Likewise, Jon.
00:36:42.271 --> 00:36:42.893
Thank you.
00:36:42.893 --> 00:36:44.139
Have a nice week ahead.
00:00:00.000 --> 00:00:05.724
AI is changing the way we all work and technology professionals are no exception.
00:00:05.724 --> 00:00:14.711
The availability of GitHub Copilot, Claude Code, is changing the way we work with the machines as we're coding.
00:00:14.711 --> 00:00:23.387
And so very pleased to discuss the future of software engineering with Manjunath Bhat, uh distinguished VP analyst at Gartner.
00:00:23.387 --> 00:00:24.257
Welcome, Manju.
00:00:24.257 --> 00:00:24.875
Thank you, Jon.
00:00:24.875 --> 00:00:25.893
Thanks for having me.
00:00:25.893 --> 00:00:29.077
It's a pleasure to talk to you, Manju, always.
00:00:29.077 --> 00:00:38.345
You've been a keynote speaker at API Days Singapore the last couple of years and also recently at API Days Australia.
00:00:38.345 --> 00:00:48.444
And I know that you've done a lot of research about software engineering and you're tracking very closely the changes in the way we do software engineering.
00:00:48.444 --> 00:00:56.954
Can you sort of give us a picture of what of what's been the most dramatic change that you've seen in last year or so.
00:00:56.954 --> 00:01:09.352
Yeah, I think that that's a good place to start and I will call out, I think for the purpose of listeners to this podcast and who may not be familiar with what I do or what our team does.
00:01:09.352 --> 00:01:13.635
So as you said, I'm part of Gartner, part of Gartner's software engineering practice.
00:01:13.635 --> 00:01:26.373
And one of the many analysts who focus on the impact of AI on software engineering plus also the other side, which is how you're starting to see uh a new software development lifecycle emerge for AI.
00:01:26.373 --> 00:01:29.647
So literally this is, we're seeing this play out in two ways.
00:01:29.647 --> 00:01:35.102
What we're calling AI native software engineering, which is impact of AI on the traditional SDLC.
00:01:35.102 --> 00:01:43.760
And then the rise of what we can think of as the agent development lifecycle or the ADLC, which is the SDLC for AI.
00:01:43.760 --> 00:02:02.612
I think with that background, one of the big shifts, if you ask me, Jon, I call out, think this big shift in the last few years has been where software engineering has moved primarily from being something that is human driven, but AI augmented to being now agent driven and human augmented.
00:02:02.612 --> 00:02:07.975
So I think that is at the core of many of the subsequent shifts we are starting to see.
00:02:07.975 --> 00:02:20.683
And when I say like, you know, AI augmented versus something that's driven, think of this as like when this entire wave started, it almost felt like, well, we'll continue to work within our IDE, right?
00:02:20.683 --> 00:02:24.786
So, and you'd have these developers actually tabbing through functions.
00:02:24.786 --> 00:02:27.426
So function was the unit of change.
00:02:27.426 --> 00:02:38.054
And so we, think as we started moving from just like these tools, like suggesting functions to now implementing entire functionality, right?
00:02:38.054 --> 00:02:45.908
So that at its heart is the shift from AI moving from being an assistant to being a long-running agent, right?
00:02:45.908 --> 00:02:51.205
So, I mean, metaphorically, people have said, oh, well, agents have become coworkers.
00:02:51.205 --> 00:02:59.979
So we are sort of less inclined to use that term because on one hand, it denigrates uh the real meaning of what is a coworker, right?
00:02:59.979 --> 00:03:12.556
So even we've tried to stay away from the term peer programmer because if you think of those actual human terms, you would assume that uh humans actually, we improve learning from our peers.
00:03:12.556 --> 00:03:19.682
So there's a very healthy learning loop, but these agents, at least until now, they don't demonstrate online continuous learning.
00:03:19.682 --> 00:03:23.014
So which is why we still prefer to call them like long running agents.
00:03:23.014 --> 00:03:39.377
So I think if you ask me the big shifts, like I discussed, like human driven to being agent driven, I think the other thing is also what this has meant is that it's also, I think on the positive front, You can think of humans are now like as in we are able to, you know this paper, right?
00:03:39.377 --> 00:03:44.099
Backing up attention is all you need was this transformative paper on transformers.
00:03:44.099 --> 00:03:52.979
Well, what that also means is human attention is not only important and it's human attention is actually a scarcer commodity, right?
00:03:52.979 --> 00:03:55.024
Attention in that paper refer to something else.
00:03:55.024 --> 00:04:05.872
But if we now look at the impact it has had on the way we work, it's not just knowledge that's uh important, but where we drive our attention, right?
00:04:05.872 --> 00:04:30.829
where we, and I think with this long running agents, what it has enabled we as humans to do is it's enabled us to direct our attention in areas that matter most, whether it is in terms of business impact, if we are in the corporate world, or uh if we're working on a hobby project, we can just get to some desired outcome as soon as possible, just completely eliminating friction in the process.
00:04:30.829 --> 00:04:47.043
I think from what I've seen, every programming course I've ever tried before in the last 30, 40 years, every programming course has always started with a Hello World application.
00:04:47.043 --> 00:04:58.430
And it sounds silly to only put up Hello World on the screen, but in the past, it's been very difficult to get to Hello World because you have to set up an entire environment.
00:04:58.430 --> 00:05:00.062
You have to understand the syntax.
00:05:00.062 --> 00:05:01.973
have to get their syntax right.
00:05:01.973 --> 00:05:08.065
And the early compilers, interpreters would punish you quite severely for not getting it right.
00:05:08.065 --> 00:05:11.379
And you just get syntax error or no response at all.
00:05:11.379 --> 00:05:17.994
But you can get to Hello World now with one of these AI coding assistants almost instantly.
00:05:17.994 --> 00:05:33.261
And I'm interested in your comment about pair programming because pair programming is about a dialogue between people, peers who exchange ideas and the whole is greater than the sum of the parts.
00:05:33.261 --> 00:05:46.935
You can get a conversation out of an AI coding assistant, but I think your point is that it's more like an assistant or a, I've heard some people describe it as an enthusiastic intern.
00:05:46.935 --> 00:05:48.528
They won't always get it right.
00:05:48.528 --> 00:05:54.721
they can come up with some exciting things that are always interested in creating something, but it won't necessarily be the right thing.
00:05:54.721 --> 00:06:00.274
And you have to adjust and make it go back and backtrack a few things.
00:06:00.274 --> 00:06:12.377
I guess use your own expert knowledge of what good looks like in order to iterate with the coding assistant to get to where you want to go.
00:06:12.377 --> 00:06:22.507
are following the best practices that, know, is that a, is that where you see things are now and more of that, or where do you see this heading?
00:06:23.023 --> 00:06:29.329
I think if we think about it, like you said, AI has made it very easy to uh build a prototype.
00:06:29.329 --> 00:06:37.136
I think the real gap is from taking a prototype to production, which is where we still see a lot of friction.
00:06:37.136 --> 00:06:44.091
So I completely agree that if you just want to build a Hello World program, it's become a no-brainer.
00:06:44.091 --> 00:06:48.048
In fact, it has lowered the barriers, which is why it's a good sign for the industry.
00:06:48.048 --> 00:06:53.442
because you can have so many, even people from outside the traditional tech sector, right?
00:06:53.442 --> 00:07:03.663
So, and people who would have thought, this programming is something that's an arcane kind of technology, and probably outside of my realm, now it feels within reach.
00:07:03.663 --> 00:07:12.502
And even within the tech sector, you find that product owners who might have stayed away from development thinking, I, all I can do is build a wireframe, but...
00:07:12.502 --> 00:07:18.406
with these kind of tools, now they can go beyond a wireframe and see something actually working.
00:07:18.406 --> 00:07:23.187
So in many ways, it has bridged this gap between different roles.
00:07:23.187 --> 00:07:35.576
So between product owners and engineers, plus also for engineers, I think the biggest benefit, I think this is an important one to call out, is that it's dramatically improved the pace at which you can experiment.
00:07:35.576 --> 00:07:40.173
And so the cost of experimentation is almost like hitting zero.
00:07:40.173 --> 00:07:47.166
you can try out n number of experiments with almost zero cost and then decide, okay, this is the path I'm going to go to.
00:07:47.166 --> 00:07:51.672
And taking that prototype to production is where all of the friction lies.
00:07:51.672 --> 00:07:54.473
So that's maybe one way to think about this.
00:07:54.473 --> 00:08:06.915
And the other comment about pair programming is still, if you look at, for instance, where pair programming really becomes valuable is, it's one human judgment versus another human judgment, right?
00:08:06.915 --> 00:08:17.747
So I think this is the essence of the difference where what you'll start to see is increasingly with these agentic workflows, it's making coding a very execution focused activity.
00:08:17.747 --> 00:08:23.341
So the value is no longer just in the art and science of producing that code.
00:08:23.341 --> 00:08:28.916
the value of implementing something is becoming lesser and lesser.
00:08:28.916 --> 00:08:33.770
where there's huge value is like in the, what we call, you know, executive function.
00:08:33.770 --> 00:08:39.033
So think of this as humans being valued not as much for execution, but for executive function.
00:08:39.033 --> 00:08:51.559
Now that executive function can manifest itself in good decision-making, you good judgment, your ability to sense whether this is the right thing to build, building like customer trust, user trust.
00:08:51.559 --> 00:08:57.376
And if we look at bad programmers, this was really two humans exercising this kind of human judgment.
00:08:57.376 --> 00:09:00.038
with the agentic workflows so far, right?
00:09:00.038 --> 00:09:06.985
It's still like, you don't get the same feeling that you are looking at another person's like human judgment.
00:09:06.985 --> 00:09:09.458
So which is why I sort of hesitate.
00:09:09.458 --> 00:09:15.885
And in fact, that one of the big downsides, if you look at in recent times, there's been this huge trend about vibe coding, right?
00:09:15.885 --> 00:09:19.240
One of the downsides of vibe coding is also for the developer.
00:09:19.240 --> 00:09:22.360
there's no quick iterative learning mechanism in place.
00:09:22.360 --> 00:09:29.157
So you don't, because with vibe coding, almost, you assume that you don't care about the code, which is why it's really good for building prototypes.
00:09:29.157 --> 00:09:36.460
But for production grade software, you do want the human developer, the person using these tools to also improve, right?
00:09:36.460 --> 00:09:43.173
And not only that, you also expect that the tools will improve, which is, I think, a twofold downside to this process.
00:09:43.173 --> 00:09:45.667
It's a limitation right now that the...
00:09:45.667 --> 00:09:52.500
by completely offloading work to an AI, we are not learning in the process unless we consciously choose to.
00:09:52.500 --> 00:10:00.465
And the other limitation with these LLM models or AI or agentic coding tools is it's not learning continuously either, right?
00:10:00.465 --> 00:10:06.190
So that is where most of the new like infusion of innovations is happening, Jon.
00:10:06.190 --> 00:10:09.692
So if you look at, maybe if you ask me, where's the...
00:10:09.692 --> 00:10:12.442
broader surface area of innovation, I'd say context, right?
00:10:12.442 --> 00:10:15.504
And which is why like context engineering is important.
00:10:15.504 --> 00:10:30.631
And so in many ways, we started with these tools like essentially become innovating at the experience layer, but fast forward now and in future, you'll find that if they have to continuously improve, they got to innovate at the context layer, right?
00:10:30.631 --> 00:10:33.634
So context layer becomes the new innovation surface.
00:10:33.634 --> 00:10:43.445
So I find it's certainly a productivity improvement and I'm not a great fan of hand coding, HTML, CSS.
00:10:43.445 --> 00:10:53.554
So the coding assistant certainly takes away a lot of that legwork to set up a page or or a set of functions.
00:10:53.554 --> 00:10:59.820
I guess to your point is the context really has to come from me as the coder.
00:10:59.820 --> 00:11:06.745
I have to say not only do I want a page that has these characteristics, but it has a particular purpose.
00:11:06.745 --> 00:11:22.347
And then I found it does accelerate the cycle ah because even if you're hand coding everything, you would start with a small a small program and then start to add functions on top of that because you need to be able to test as you go.
00:11:22.347 --> 00:11:25.631
No point writing 10,000 lines of code and then start testing.
00:11:25.631 --> 00:11:26.802
It's not going to work.
00:11:26.802 --> 00:11:28.982
You have to test a little bit.
00:11:28.982 --> 00:11:34.287
there is still a cycle that you should go through, a build, test, learn cycle.
00:11:34.287 --> 00:11:44.715
But I think to your point is that it's up to the human to tell the assistant, you need to start heading in this direction.
00:11:44.715 --> 00:11:49.591
And I haven't found when I've said, well, actually that file's getting too big.
00:11:49.591 --> 00:11:54.556
Can you break it out into two or three files by function?
00:11:54.556 --> 00:11:57.008
Or there are some hard coded variables there.
00:11:57.008 --> 00:12:00.162
uh Can't you create a configuration file?
00:12:00.162 --> 00:12:04.336
That configuration file is not protected anywhere.
00:12:04.336 --> 00:12:07.467
It's exposed in the repository.
00:12:07.467 --> 00:12:08.299
Can you put that?
00:12:08.299 --> 00:12:23.160
So having to constantly remind or ask the assistant to build out something that's going to be more secure, more scalable, more production ready is still on the expert.
00:12:23.160 --> 00:12:26.825
So where do you see our expertise?
00:12:26.825 --> 00:12:47.331
going into though you talked about executive function but the executive function is sort of thinking a little bit about the context but it's also having an understanding of what is what is compliant what is secure what is what is what is scalable what's cost-effective also for the for the company Yeah, 100%.
00:12:47.331 --> 00:12:51.734
So I think oh a few thoughts responding to that.
00:12:51.734 --> 00:13:01.496
One, if you look at uh recent trends that have surfaced to mitigate those kind of issues that you mentioned, one primarily is spectrum in development.
00:13:01.496 --> 00:13:16.342
So I think that has emerged as one of the ways where you can overcome the limitation of traditional vibe coding, where it was primarily meant as a stateless interaction mode between the developer and the assistant.
00:13:16.342 --> 00:13:20.784
And as soon as the developer exits the session, all context is lost.
00:13:20.784 --> 00:13:23.086
So that was a huge limitation.
00:13:23.086 --> 00:13:29.318
So you're not essentially uh giving sufficient context to the agent.
00:13:29.318 --> 00:13:38.083
So with specs, we can think of specs as a mechanism to steer the agent to do what we expect it to do.
00:13:38.083 --> 00:13:52.035
Now, it's not necessarily uh meaning that specs It's spec-driven development and not necessarily that the agent, because it's non-deterministic fundamentally, you can't expect it to be a spec-fulfilling agent.
00:13:52.035 --> 00:14:01.860
So I think we got to maybe set that expectation that just merely by creating a specification, we can't guarantee that the agent adheres and complies with that specification.
00:14:01.860 --> 00:14:05.413
So it's just a way for us to ensure standardization.
00:14:05.413 --> 00:14:07.754
It's a way to ensure consistency, right?
00:14:07.754 --> 00:14:10.355
So governance uh rules are in place.
00:14:10.355 --> 00:14:14.798
I mean, I am starting to look at specs in a two-fold manner.
00:14:14.798 --> 00:14:23.832
One is, if you are, let's say, a platform engineering team, if you are part of the security and risk team, you want your governance policies codified.
00:14:23.832 --> 00:14:28.794
And what's the best way to codify and institutionalize those policies?
00:14:28.794 --> 00:14:30.455
Well, that would be specs.
00:14:30.455 --> 00:14:32.032
I see you mentioned cloud code.
00:14:32.032 --> 00:14:36.544
So you might put that in a .md file for Claude and all of the markdown files.
00:14:36.544 --> 00:14:45.774
So that becomes uh a vehicle to, in fact, serve this twofold purpose of improving developer productivity plus also meeting governance needs.
00:14:45.774 --> 00:14:48.466
So I think that's one huge benefit.
00:14:48.466 --> 00:14:56.650
The other thing that also becomes important is, know how, like think going back 20 years ago, one of my favorite books was Martin Fowler's Refactoring.
00:14:56.650 --> 00:14:59.193
He's one of his very popular books as well.
00:14:59.193 --> 00:15:02.907
And I almost thought that, well, has refactoring gone out of fashion?
00:15:02.907 --> 00:15:10.423
But in fact, you can think with AI augmented or AI native coding, refactoring might actually see a resurgence.
00:15:10.423 --> 00:15:23.258
So it's probably, refactoring has never been as important because as AI keeps generating more and more code, we've got to compensate for all of the newly generated code to make sure it's also continuously refactored.
00:15:23.258 --> 00:15:25.870
So I think that is extremely important.
00:15:25.870 --> 00:15:26.981
Who does the refactoring?
00:15:26.981 --> 00:15:34.066
Probably is a moot point that you can still direct the agent to refactor code, but refactoring is important.
00:15:34.066 --> 00:15:39.571
The other thing that also becomes important is verification and validation harnesses.
00:15:39.571 --> 00:15:47.496
when you have such a huge amount, such a huge volume of new code being generated, it's just implausible, right?
00:15:47.496 --> 00:15:59.217
So I mean, it's unthinkable that you can just have humans verify every line of code that is being generated or like, you you just can have human in the loop and human oversight.
00:15:59.217 --> 00:16:03.592
It's good in theory, but you would very soon find humans as the new bottleneck.
00:16:03.592 --> 00:16:19.278
And so if we got to overcome that, what might need to happen is our, like the success with these agentic coding tools is directly proportional to the degree to which we have a very high degree of verification and validation maturity.
00:16:19.278 --> 00:16:25.576
So which means a uh fast inner loop will also require a faster outer loop.
00:16:25.576 --> 00:16:28.279
So I think that is how I'm thinking about it.
00:16:28.279 --> 00:16:55.791
So you touched on some things and I guess we started talking about individual programmer productivity and now you're talking about what it means to the enterprise because the enterprise needs to enforce some standards that should encourage certain patterns to be used, if only for the sake of readability by other developers, but also to your point about validation.
00:16:55.791 --> 00:17:19.017
And in a sense, before generative AI, we were automating testing, we were setting style guides for an organization, architects would create patterns and even anti patterns don't do this to an organization, but it would have to be enforced manually because manual code reviews are very, very time consuming, and no organization really gets to do it.
00:17:19.017 --> 00:17:20.929
100 % of the time.
00:17:20.929 --> 00:17:35.670
And the linters that have been used to verify compliance with a style guide, are often, then it still requires a judgment because there's a tension between standardization and innovation.
00:17:35.670 --> 00:17:47.318
Standardization is very valuable because you can validate things, you can verify that things are not going to go out of control, but you'll only ever get the same as what you had before.
00:17:47.318 --> 00:17:50.029
You won't get new things unless you innovate.
00:17:50.029 --> 00:18:10.018
So the linters that were put in place, they may come up with a, identify a violation of a style guide and then someone, some senior engineer would have a conversation with the less senior engineer about why they should uh or should they really conform with a pattern.
00:18:10.018 --> 00:18:18.606
But for organizations to manage that, I guess what it means is that it's not enough just to automate a simple rules-based system.
00:18:18.606 --> 00:18:24.089
you have to get another agent to look for what can go wrong with this.
00:18:24.089 --> 00:18:26.674
Where do you see that evolution occurring?
00:18:26.674 --> 00:18:32.780
Is that going to be built into the tools or do we need an external set of tools that are going to...
00:18:32.780 --> 00:18:52.394
think a couple of ways this will start to unravel is that even now when we're looking at our uh IDEs, and by the way, my favorite like acronym, like think of this as mutating an acronym is, I say IDEs are not just integrated development environments, they're now intelligent development environments, right?
00:18:52.394 --> 00:18:55.662
So that's the new IDE, if you will.
00:18:55.662 --> 00:18:59.853
In these intelligent development environments, it's no longer just assistance.
00:18:59.853 --> 00:19:03.663
We've gone from assistance within the IDE to single agents.
00:19:03.663 --> 00:19:08.256
But to your point, Jon, coming to what you're describing is these are multiple agents.
00:19:08.256 --> 00:19:15.357
So if you look at tools like whether it's Amazon Kiro and Cursor and few others, they've started using the term sub-agents, right?
00:19:15.357 --> 00:19:24.651
So it's actually an orchestrator agent that spins off and works with orchestrates, a bunch of sub-agents.
00:19:24.651 --> 00:19:31.651
So you can sort of imagine that there are subagents who will keep a watch on what the other agent has produced.
00:19:31.651 --> 00:19:36.904
So in a sense, one subagent is going to verify the code of another subagent.
00:19:36.904 --> 00:19:48.058
if we are worried about agents grading their own homework kind of a problem, I think what this is also coming out to be is that, you will not just have like one model.
00:19:48.058 --> 00:20:00.866
So maybe you use the developer or the coder subagents to use one model, maybe a GPT 5.2, 5.3, and then the verification subagent could be a Claude model, a Claude Opus and so on.
00:20:00.866 --> 00:20:10.195
So in that sense, you're still taking advantage of agentic verification without just maybe like just overly relying on one model doing it all.
00:20:10.195 --> 00:20:11.576
So that's one thought.
00:20:11.576 --> 00:20:29.963
the other one is, I think on the positive side, I'm starting to see how a lot of the knowledge used to be considered tribal knowledge, everything that exists maybe in a senior engineer's head, we resorted to maybe using Confluence and a few other tools to institutionalize that knowledge.
00:20:29.963 --> 00:20:42.299
But it generally became a very passive source of knowledge for the organization because there was no good way to uh weave that knowledge residing in those sources of truth or systems of record like Confluence, right?
00:20:42.299 --> 00:20:43.200
And weave that in.
00:20:43.200 --> 00:20:49.403
So which means you can think of agents as a um mechanism to institutionalize tribal knowledge.
00:20:49.403 --> 00:20:50.983
So which is huge, right?
00:20:50.983 --> 00:21:04.262
And so I have actually had calls on this topic where people are starting to think where as soon as this, you know, maybe as people start to retire as senior engineers, senior architects, there is a risk of them retiring from the workforce.
00:21:04.262 --> 00:21:05.056
How might...
00:21:05.056 --> 00:21:14.366
you think of retaining all of their decades worth of expertise that one, they have gleaned and they're yet to contribute.
00:21:14.366 --> 00:21:19.366
So in many ways, you can create like a digital twin of Jon Scheele, right?
00:21:19.366 --> 00:21:22.738
With your decades of experience, have an agentic version of yourself.
00:21:22.738 --> 00:21:26.489
So even after you've retired, junior engineers can tap into your expertise, right?
00:21:26.489 --> 00:21:29.079
So I think that that's a huge bonus point.
00:21:29.079 --> 00:21:42.218
The last one actually that comes to mind in that, in the enterprise is I was also thinking where we, when DevOps came along and it became DevSecOps, it was more about like how you wanted to bridge silos, right?
00:21:42.218 --> 00:21:44.579
And that was more of an operating model shift.
00:21:44.579 --> 00:21:53.353
But if you start looking at agents, now agents can actually start to bridge these silos between teams that otherwise might not have communicated.
00:21:53.353 --> 00:22:00.067
So I look at maybe, there's a DevOps agent that's uh having visibility into production issues.
00:22:00.067 --> 00:22:08.584
and it's passing on all of the insights to the development team saying, hey, this is a problem with the architecture that you currently have.
00:22:08.584 --> 00:22:13.627
These are the kind of issues I'm seeing every day and I'm probably fixing it on your behalf.
00:22:13.627 --> 00:22:18.431
So you better do this at the architect, take care of this at the architecture layer.
00:22:18.431 --> 00:22:21.334
Or maybe security teams have a use case.
00:22:21.334 --> 00:22:33.542
You might essentially say, if you look at vulnerabilities being fixed and determined, you can have those agents actually pass on that feedback to the security team who should have participated in threat modeling.
00:22:33.542 --> 00:22:49.064
So in effect, you will start to see the agent as a uh common, it's a common war room that is a virtual war room where it's bringing folks from architecture, development, security and ops together who might have otherwise not communicated.
00:22:49.064 --> 00:23:00.115
I think that brings to mind practices that people have promoted, but not so easy to put into practice.
00:23:00.115 --> 00:23:07.773
publishing a standard or a style guide or a pattern or an anti-pattern, documenting things, that...
00:23:07.773 --> 00:23:11.689
that only served a purpose if people would read those things.
00:23:11.689 --> 00:23:19.695
And in an organization, it was often very hard to get people to read and understand and follow all of those things.
00:23:19.695 --> 00:23:23.058
And then finding the right pattern to match up.
00:23:23.058 --> 00:23:29.553
the practicality of that is improved by having agents who can help you to locate it.
00:23:29.584 --> 00:23:31.506
in a more conversational way.
00:23:31.506 --> 00:23:37.641
Tell me what the pattern is when I'm trying to connect these two types of systems together.
00:23:37.641 --> 00:23:50.885
And we talked about platform engineering in the past and the idea that a platform is set up by the operations team to help guide the development team.
00:23:50.885 --> 00:23:58.064
to produce good code in the first place, but that is always a challenge to push that feedback loop back through.
00:23:58.064 --> 00:24:03.909
And I guess what you're describing is agents being able to facilitate that.
00:24:03.909 --> 00:24:08.773
So what do you see as a good platform engineering practice now?
00:24:08.773 --> 00:24:14.267
Yeah, so in effect, I think this is probably the best time to build a platform.
00:24:14.267 --> 00:24:18.549
So in effect, basically twofold impact on platform engineering teams.
00:24:18.549 --> 00:24:27.814
One, I think my other mutation of the acronym is IaaS, so where it's no longer just infrastructure as a service, it's intelligence as a service.
00:24:27.814 --> 00:24:31.035
So I think that internally is starting to play out.
00:24:31.035 --> 00:24:33.237
We did a case study with Verizon.
00:24:33.237 --> 00:24:38.077
We have also done another one with a healthcare services provider called Vizient.
00:24:38.077 --> 00:24:48.481
So in most of these large enterprises, you're starting to see platform teams actually step up, one, to make it easier to embed AI as part of the SDLC.
00:24:48.481 --> 00:24:49.362
That's one part.
00:24:49.362 --> 00:24:52.463
But also like we discussed, SDLC for AI.
00:24:52.463 --> 00:24:54.443
So that's, think, the second part of it.
00:24:54.443 --> 00:24:58.439
Now, the way platform engineering teams can use this is it's...
00:24:58.439 --> 00:25:12.816
In many ways, think using guardrails, platform engineers typically found it very difficult to enforce these governance policies, but they resorted, I think the best tools they had at their disposal was templates.
00:25:12.816 --> 00:25:19.394
So if you look at the likes of Backstage, which is famously used for just allowing templatized workflows.
00:25:19.394 --> 00:25:24.778
So if you want to build maybe a new Node.js service and new microservice use this template.
00:25:24.778 --> 00:25:29.644
And you can spin up like a Hello World service very quickly if you use templates.
00:25:29.644 --> 00:25:38.832
And the benefit of templates is that on one hand, it complies with what the platform engineering team needs, but on the other hand, it also like just improves developer experience.
00:25:38.832 --> 00:25:44.917
I think these kind of templatized workflows was the only tool that the platform team said.
00:25:44.917 --> 00:26:00.144
But now if you look at agentic tools, Yes, you'll start to see, well, of course they will have to permit the use of agents, but what you'll start to also, I think the big responsibility on the platform team is governance of those agents.
00:26:00.144 --> 00:26:09.361
And I think, when I say governance, I mean, it's not just from a security perspective, also looking at, for instance, how much is it costing the organization, right?
00:26:09.361 --> 00:26:21.195
So I forget the actual source, somebody said that, you're not doing enough, you're not utilizing AI to its fullest potential unless you spend$1,000 per engineer, right?
00:26:21.195 --> 00:26:26.192
So I think now people are, it's costing a lot as well when you use these tools.
00:26:26.192 --> 00:26:31.576
And with every new release, by the way, of Anthropic Claude the cost just tends to go up, right?
00:26:31.576 --> 00:26:32.426
It's not coming down.
00:26:32.426 --> 00:26:36.561
So the better the model is, the greater the reasoning capabilities, those all come at a cost.
00:26:36.561 --> 00:27:01.647
I think in short, there's a huge need for platform engineering teams to establish one guardrails, but also put in place governance around costs, governance around expected reliability, scalability, and essentially all of the non-functional requirements that a service should meet before it gets to production.
00:27:01.647 --> 00:27:14.487
So in effect, think platform engineering teams now not only have to govern the way traditional like software is being developed, but they also have to govern the tools that will produce these artifacts.
00:27:14.487 --> 00:27:15.807
One last comment, by the way.
00:27:15.807 --> 00:27:21.502
So I think um since you brought this up, I've been noticing a pattern with these mismatches.
00:27:21.502 --> 00:27:28.036
And I think this is where this This might be an opportunity for platform engineering teams to work closely with product teams.
00:27:28.036 --> 00:27:33.339
And when I talk of mismatches, I'm referring to, let's say for instance, this cadence mismatch.
00:27:33.339 --> 00:27:37.122
So the cadence mismatch is uh productivity versus security, right?
00:27:37.122 --> 00:27:39.982
So that's been a huge mismatch there.
00:27:39.982 --> 00:27:45.615
And one way to bridge or close that gap is platform engineering, to the rescue.
00:27:45.615 --> 00:27:47.527
That's one way to think about this.
00:27:47.527 --> 00:27:50.897
The other is you can think of it as an impedance mismatch.
00:27:50.897 --> 00:27:57.180
So impedance mismatch is, if you look at what we expect from applications, it's deterministic.
00:27:57.180 --> 00:28:01.571
But the tools we're using to build those applications is actually non-deterministic.
00:28:01.571 --> 00:28:10.540
it's fundamentally an impedance mismatch between a non-deterministic tool and our expectation for it to produce deterministic artifacts, right?
00:28:10.540 --> 00:28:14.563
So that's another mismatch that the platform engineering team has to resolve.
00:28:14.563 --> 00:28:17.515
And the third one is fundamentally accountability.
00:28:17.515 --> 00:28:25.009
Like you made a point earlier on where you said the accountability still has to sit with the human engineering team.
00:28:25.009 --> 00:28:26.692
And that is absolutely true.
00:28:26.692 --> 00:28:39.008
So there is this accountability mismatch where agents are doing a lot of the work that we would otherwise have done, but we are expected to continue to take accountability even if we have not done the work.
00:28:39.008 --> 00:28:43.951
So that actually places an enormous burden of accountability on us.
00:28:43.951 --> 00:28:49.010
and we may not be intimately familiar with everything that's gone into building that artifact.
00:28:49.010 --> 00:28:52.682
There's a whole lot there that I could take apart, Manju.
00:28:52.682 --> 00:28:54.364
I mean, you mentioned cost.
00:28:54.364 --> 00:29:10.226
And I think one of the things we should be a little concerned about is, yes, you can use an AI coding assistant to produce just about any code that you want, but sometimes it's using a hammer to crack a nut.
00:29:10.226 --> 00:29:12.299
And it's an expensive hammer.
00:29:12.299 --> 00:29:18.634
at times when it's just turning through doing things that are really quite simple and you could automate.
00:29:18.634 --> 00:29:44.999
And sometimes I feel you probably should use the tool to produce a program that will do the thing that you want to do rather than get the AI agent to actually complete the task because it's going to use up tokens to do it, whereas program can repeat itself over and over again at much lower cost without consuming all those tokens over again.
00:29:44.999 --> 00:29:55.977
are we in danger of seeing what happened to cloud computing where everybody thought, oh, it's so much cheaper because you only pay for what you use.
00:29:55.977 --> 00:29:59.179
And then everybody started using to do so much more.
00:29:59.179 --> 00:30:01.540
What sort of controls to companies.
00:30:01.540 --> 00:30:02.672
You mentioned platform teams.
00:30:02.672 --> 00:30:06.202
Is it just the platform team or is it the finance team as well?
00:30:06.324 --> 00:30:15.001
What does the finance team in an enterprise need to understand now about how to manage the use of these agents?
00:30:15.001 --> 00:30:18.955
Yeah, I think overall, if you look at it, let's tackle the last point you made.
00:30:18.955 --> 00:30:23.428
platform team serves as the abstraction layer.
00:30:23.428 --> 00:30:25.078
I'm using this term very loosely.
00:30:25.078 --> 00:30:31.603
So it's taking what the finance team wants the organization to do to stay true to.
00:30:31.603 --> 00:30:39.788
So it converts the needs of the finance team and translates it in a self-service manner to how the engineers can consume the platform.
00:30:39.788 --> 00:30:50.176
So it's basically saying, well, you engineers, you can use all the autonomy you have, but work within the financial guardrails that we have put in place.
00:30:50.176 --> 00:30:59.480
in effect, the platform engineering teams becomes the translation layer between what the finance team wants and what the engineering team wants to accomplish.
00:30:59.480 --> 00:31:01.563
So I think we are good on that front.
00:31:01.563 --> 00:31:05.105
And you can have cost guardrails, and you can have cost visibility.
00:31:05.105 --> 00:31:07.686
So all of that will play out nicely.
00:31:07.689 --> 00:31:16.532
Then the other consideration, I think the other point you were referring to is on the precursor or the precedent we have with cloud computing.
00:31:16.532 --> 00:31:18.073
And I think that is fascinating.
00:31:18.073 --> 00:31:28.607
And if we want to extend that metaphor and that example, yes, and much the same way as people eventually realize that moving to the cloud is not just for cost reasons, right?
00:31:28.607 --> 00:31:29.589
So in fact, it's...
00:31:29.589 --> 00:31:36.284
we doubt that anyone who's maybe using cloud in the right sense actually has managed to decrease its usage.
00:31:36.284 --> 00:31:40.268
Eventually everyone's cloud expenses go up, right?
00:31:40.268 --> 00:31:41.368
And not down.
00:31:41.368 --> 00:31:44.269
So especially if you're trying to innovate, right?
00:31:44.269 --> 00:31:44.881
And so on.
00:31:44.881 --> 00:31:46.892
So cloud expenses will shoot up.
00:31:46.892 --> 00:31:52.857
So which means much like cloud became a business enabler and the true value of cloud.
00:31:52.857 --> 00:31:58.823
only comes when you can use the cloud to drive innovation that you would have otherwise not been able to.
00:31:58.823 --> 00:32:02.125
Very similar parallels exist in the AI world.
00:32:02.125 --> 00:32:09.388
it's probably very rare to very unlikely that somebody is going to use agentic coding tools to reduce costs.
00:32:09.388 --> 00:32:15.713
On the contrary, they might use agentic coding tools to drive new sources of revenue.
00:32:15.713 --> 00:32:19.645
to build stuff that might have otherwise seemed infeasible, right?
00:32:19.645 --> 00:32:24.259
So something that would have been uh from a business perspective, very unviable, right?
00:32:24.259 --> 00:32:35.058
So I think if we're just limiting the use of agentic coding tools to doing what we've always done, the cost implications are going to be huge and we might not be able to justify it.
00:32:35.058 --> 00:32:36.991
Thanks for sharing that, Manju.
00:32:36.991 --> 00:32:41.442
I think there's a lot to unpack in that.
00:32:41.442 --> 00:32:46.405
And great perspective on how our lives are changing.
00:32:46.405 --> 00:32:51.378
Can I just, perhaps as a final question, ask about where we're going to see?
00:32:51.378 --> 00:32:56.423
Because what you mentioned shouldn't be seen as simply a cost play, just as cloud computing.
00:32:56.423 --> 00:32:59.205
to reap the real benefits wasn't just about costs.
00:32:59.205 --> 00:33:05.819
One of the challenges at the moment is that some firms have decided they don't need as many developers.
00:33:05.819 --> 00:33:09.932
And that typically means they don't need as many junior developers.
00:33:09.932 --> 00:33:16.930
We both have children who just started university and the immediate future for a junior engineer.
00:33:16.930 --> 00:33:28.925
seems a little uncertain at the moment because senior engineers can get more done when they would have passed on some of those easier tasks to a junior engineer.
00:33:28.925 --> 00:33:42.346
How do you see us gaining the experience necessary to be productive in order to to be useful in an organization and to be employable in an organization.
00:33:42.346 --> 00:33:47.390
Yeah, and like you mentioned, Jon, I tell my son, who is in university now, is...
00:33:47.390 --> 00:33:50.580
In general, fundamentals are definitely going to be important.
00:33:50.580 --> 00:33:56.144
So the need for fundamental understanding of how software is engineered is not going to go away.
00:33:56.144 --> 00:33:58.175
So I'm very bullish on that.
00:33:58.175 --> 00:34:02.027
So that's one point I'll make, regardless of how software is being built.
00:34:02.027 --> 00:34:04.400
So engineering uh software is...
00:34:04.400 --> 00:34:15.873
I mean, if we assume that it is an engineering problem, the need for like foundational engineering concepts, which is whether it's architecture, design, security, reliability, resilience, right?
00:34:15.873 --> 00:34:17.643
Fail over redundancy.
00:34:17.643 --> 00:34:21.353
Those I think become increasingly important, not less important, right?
00:34:21.353 --> 00:34:22.643
So that's one point.
00:34:22.643 --> 00:34:39.324
I think uh the other thing to keep in mind, and especially if we have junior engineers or somebody who's in university listening to this, what they should not assume is that the next generation of software that we will build will bear a lot of resemblance to previous generations of software.
00:34:39.324 --> 00:34:43.438
So it's not going to be traditional, unintelligent, rule-based software, right?
00:34:43.438 --> 00:34:45.630
So it's not just automation software.
00:34:45.630 --> 00:34:48.711
So the nature of applications themselves will change.
00:34:48.711 --> 00:34:55.418
So which means we've got to just prepare for the world where every application is going to be intelligent by design.
00:34:55.418 --> 00:34:58.201
So I think that is the new reality.
00:34:58.201 --> 00:34:58.762
And so...
00:34:58.762 --> 00:35:09.101
it's inevitable that maybe if you're looking at today's job descriptions, you'll find there's this huge demand even now for AI engineers, right?
00:35:09.101 --> 00:35:18.682
Those job descriptions ideally should have been for a software engineer who knows AI, who understands AI engineering or who can implement AI engineering.
00:35:18.682 --> 00:35:23.336
If you fast forward maybe a few years, we can basically see the blurring of these lines.
00:35:23.336 --> 00:35:25.239
Every software engineer will...
00:35:25.239 --> 00:35:28.132
implicitly be expected to be an AI engineer.
00:35:28.132 --> 00:35:43.034
So there's not going to be a distinction between a software engineer and an AI engineer, which basically tells if you're in university, just know that you are entering a workforce that expects you to be an AI engineer and not necessarily a software engineer.
00:35:43.034 --> 00:35:45.356
So that could be another thought.
00:35:45.356 --> 00:35:45.967
What else?
00:35:45.967 --> 00:35:56.576
And I think the other thing is, uh for instance, Creativity, the foundational human skills, those are going to continue to remain core to what we do.
00:35:56.576 --> 00:36:02.893
If I go back to my example of we'll continue to use tools, tools will get better at execution.
00:36:02.893 --> 00:36:09.389
What we'll really get paid for will be our executive functions, curiosity, critical thinking, creativity.
00:36:09.389 --> 00:36:21.260
And in fact, we have a position that we actually published in our recent report where we say, that it's creativity and not productivity that's going to be the yardstick for measuring engineering excellence.
00:36:21.260 --> 00:36:23.601
And maybe that's a good thought to end on.
00:36:25.141 --> 00:36:27.222
Thanks very much for sharing that, Manju.
00:36:27.222 --> 00:36:29.394
Always a pleasure to talk with you.
00:36:29.394 --> 00:36:37.152
And I'm looking forward to your keynote at API Days Singapore on the 14th and 15th of April.
00:36:37.152 --> 00:36:41.266
Thanks very much, and see you again soon.
00:36:41.266 --> 00:36:42.271
Likewise, Jon.
00:36:42.271 --> 00:36:42.893
Thank you.
00:36:42.893 --> 00:36:44.139
Have a nice week ahead.
