Today, we discuss the significant impact of AI on software development, particularly the use of AI assistants like GitHub Copilot. Our guest, Burke Holland, a principal developer advocate at Microsoft, shares insights on how developers are increasingly integrating AI into their workflows. We explore the current spectrum of AI usage, from code completion to AI agents that can write code autonomously. Burke emphasizes the need for developers to adapt to these changes while maintaining a critical perspective on AI-generated code. This conversation sheds light on the evolving role of software developers in an AI-enhanced landscape.

In this insightful episode, Burke Holland, a principal developer advocate at Microsoft for the Visual Studio Code team, discusses the transformative role of artificial intelligence (AI) in software development. The conversation starts with the observation that developers have shifted from skepticism about AI's capabilities in coding to a more supportive stance, with many now using AI tools like GitHub Copilot to assist in their work. Burke explains how these AI tools can provide significant assistance through 'completions'—intelligent suggestions that understand the context of what the developer is working on, effectively acting as a cognitive partner in the coding process.

The discussion further explores the concept of AI 'agents,' which represent a cutting-edge approach to automating aspects of coding. Burke acknowledges the potential of these agents to undertake more complex tasks but also expresses concern about the implications for developers' roles. He emphasizes the importance of human oversight, suggesting that while AI can enhance efficiency, developers must remain engaged with the code they produce to ensure quality and comprehensibility. The episode highlights the balance between leveraging AI's strengths and maintaining the critical thinking skills that are essential in programming.

As the episode wraps up, Burke encourages developers to adopt an exploratory mindset toward AI tools. He notes that the landscape of software development is rapidly evolving, and by integrating AI thoughtfully, developers can enhance their productivity while still preserving their essential skills and understanding of coding. The conversation underscores a future where AI and human collaboration can lead to better software outcomes, emphasizing the need for a nuanced approach to AI integration.

Takeaways:

1. In the podcast, we discussed how AI is changing the software development landscape significantly.
2. Burke Holland highlighted that the use of AI in coding has seen a dramatic increase recently.
3. We talked about the importance of understanding the code produced by AI to maintain quality.
4. Completions in AI tools like GitHub Copilot can enhance a developer's workflow remarkably.
5. Burke shared insights on the difference between completions and agents in AI coding practices.
6. We concluded that while AI can write code, developers still play a crucial role in ensuring its accuracy.

Links referenced in this episode:

1. softwarearchitectureinsights.com

Companies mentioned in this episode:

1. Microsoft
2. VS Code
3. GitHub Copilot
4. JetBrains
5. Speckit

Hello and welcome to Software Architecture Insights.

Your go to resource for empowering software architects and aspiring professionals with the knowledge and tools they require to navigate the complex landscape of modern software design.

My guest today is Burke Holland.

Burke is the principal developer architect working on the VS Code team at Microsoft.

VS Code is one of the most popular and arguably one of the best development platforms available today.

Burke also wants me to mention that he's living in Nashville, Tennessee, the quote unquote greatest city in the world according to science, and that also that he has a great first name.

Absolutely agree with him on the latter, but not quite so sure about the former.

We're going to have to discuss that.

Burke, welcome to Software Architecture Insights.

Thanks for having me.

Link Good to be here.

So I'm going to be a sucker here and I'm going to ask the question before we get started, what makes Nashville, Tennessee the greatest city in the world according to science?

Well, the whole point of saying according to science is so that you can't question it.

It's according to science.

You just have to accept that it is and therefore the point stands on its own.

I do just need to correct I'm a developer advocate, not a developer architect.

So by far the biggest hype change to the software development process is the introduction of AI and AI assistants.

And that's I think one of the primary reasons why we're talking today.

So hype aside, hype aside, what are most developers using AI for in the software development process today?

I think that's a really hard question to answer because we just aren't quite sure.

I think that if I had to do it hypothetically from what I just see is that you essentially have two camps of folks when it comes to AI and developers.

I think originally you had two camps.

The two camps where AI is good for writing code and the other camp was I'll never use AI to write code.

And I think that in the past 12 months we've pretty much moved from I'm not the I'm not going to use AI at all camp.

I think it's much smaller than it was and most folks are using AI in some form or fashion.

And then from there there's a slider between what how much code the developer is writing and how much code the AI is writing.

And we actually have there's a mechanism in VS code for seeing this, right?

This is a metric that we actually track and you can see it in your editor, a little progress bar that shows how much code the AI has written versus how much code you've written.

So if we talk about the left side of that, where you're writing most of the code, these are developers who are primarily using completions.

And we say completions, we mean ghost text.

And the ghost text is like.

It's like intellisense, but, like, crazy good intellisense.

And it's really good, right, for those.

If there's anyone out there who hasn't tried completions in something like GitHub Copilot, its ability to complete your thought is remarkable.

And the reason why it's so great is that as a developer, you get into a flow state and you're very much.

You and I, Lee, we're like LLMs in the sense that we assemble a context window as we're working and we're pulling in context.

We pull the database in and we pull the API in, and we pull the code base in and we pull the common library in.

And we're holding these concepts in our head as we're building a feature.

And it's very abstract, right?

And this is called the flow state.

And this is why when somebody comes in is like, hey, what'd you do this weekend?

The whole freaking context window falls apart and you have to rebuild it again.

And it's great that we now have like a word for this.

LLMs have like, given us the model for what this is like as a human being.

And so the reason why completions are so crazy helpful and magical is because they can enter the context window with you because they can see the code that you're writing.

They know what you just did, they know what's in the project, they know about the other tabs you have open.

And the completions model can literally read your mind.

That's what it feels like when you're coding and it's just like, boom.

And it spits out the next dozen lines that you need.

And you're like, that's exactly what I was going to write.

It's not that it writes the code that you don't know that you need.

This is the common misconception is that AI is going to write the code that I don't know about.

It's that it writes the code that you already know that you need to write without you even having to ask for it.

So that's like.

That's the left side completions.

And then you could ratchet that all the way to the other side, which is agents.

And this is kind of where I hang out, just because my job sort of dictates that we.

Beyond this frontier and this is the bleeding edge and this is where the agent is writing the code.

And I've now taken on a different responsibility.

Right at this point, I am more of an architect and I'm directing not just one agent, but multiple agents.

And I think that this group of developers is much smaller because a lot of these workflows are just not defined.

Like we don't know what is the right way.

What's my job as a developer?

Is it just to go to the AI and say, hey, add authentication to this application?

Do I need to create a spec first?

Do I need to review the code?

Does it.

Should it review its own code?

Like, there's so many open questions and that's what we're over here as Microsoft trying to do is answer these questions.

Because I do think that agents are probably most likely, almost definitely going to be the future of software development.

And then the question is, then what is my role as a developer?

How do I actually realize that?

So it isn't just hype.

Yeah, that.

You know what, that's probably one of the best descriptions I've heard of where we are today and where we're headed.

And so I love that view.

And in fact, I think it also takes a lot of the hype out because there's so much hype in AI right now.

Hype in a lot of different areas.

And one of the biggest hyped areas is a term that I absolutely hate, which is vive programming.

And the whole concept is, hey, I don't need to write anymore here.

I just do this.

Look at what it came out.

And I built a whole application, I've never written code in my life and I've got this whole application that just works and we don't need developers anymore.

And all this sort of thing is where the hype goes there.

Tell me your thoughts on that hype and where that hype is compared to what you were just talking about.

Yeah, so I think the vibe coding the terminology there is maybe unfortunate, but at the same time I kind of like it, but I dislike it.

So any developer, like your first reaction to just being like, just let something write code willy nilly and if it feels good, I'll just accept it.

Like the first reaction to that should be, absolutely not.

Absolutely not.

We would never do that in any other scenario.

Why is it now okay to do that?

The answer is it's not.

It's not okay to do that.

Is it okay to do that if you're building a prototype or a demo?

Yes, yes, absolutely.

And a Lot of what we do as developers is we build things just to see what can be, what we can do, and then we iterate on that to get to a further end state.

So in other words, like, if I'm building an application, I'm really spending a lot of time tinkering and trying to figure out, like, how is this best going to work?

And with, I think, like, with Vibe coding, the way Vibe coding applies to something like that is that you can put together, like four or five different versions of the thing that you're trying to do and have an agent do.

Just give me all five of them and then you can look at the five and see the different ways that it could be done and pick the one that you like the best and then just throw the rest away.

Now, if you think about that, historically speaking, that's wild that you could just write thousands of lines of code and just throw it away.

I don't care.

That's kind of what Vibe coding allows you to do.

So in that way, it's a really, really good thing.

Where it goes off the rails is when you apply that to production code.

So it's when you open up a project and you say there's a bug in this authentication, you just go ahead and fix it.

And then, of course, the joke is, you're absolutely right.

Right.

That's the Claude joke, is that it always says, you're absolutely right.

So it's going to gaslight you no matter what you do, and it's going to be like, oh, yeah, I found the issue.

Here's what the issue is.

Did it find the issue?

There's no way of knowing whether or not it actually did, other than you being able to validate the code that it wrote.

So there's sort of like two different ways of thinking about this.

One of them is that as a developer, you care about every single line of code that enters your production code base.

And I tend to fall on this side.

I don't want anything going in that I don't understand.

I don't even want it laying out an HTML page if I don't understand that.

It's putting the classes at the right level.

In other words, are you adding the same margin to sub elements when you could just add the margin in one place at the parent element?

Like, I'm concerned about that level of detail.

But then the other way of thinking about it is that it doesn't matter.

What matters is that the tests pass so that you could, in theory, you could have enough testing so that you're actually writing tests and the test is the artifact that you care about.

You don't actually care about the code that gets spit out.

Now that's a controversial thing to say.

I don't think that we know for sure whether or not that's the case.

But that's the other way to think about it is that the code can be vibe coded.

You don't care.

What you care about is the test and that the test passes and is accurate.

You hear that hype all the time.

You hear somebody who says, I just wrote blah and look at some incredible thing that could not be done before, but he did it because AI did it for him.

And look at all the money I'm making now.

And I just don't buy those things when they happen.

Know one of the things that I like to do when I think about what AI programming is good for, I love the completion is absolutely right about that.

It's thinking ahead of me and saving me steps to write and also helping me a little bit in formulating my thoughts.

So it's like, yeah, that's.

I didn't quite know that's exactly what I wanted to write, but now that I see it, that looks perfect for what my mind was thinking, where I was headed.

And so it allows me to go a little bit faster through that process.

Considerably faster through that process.

But one of the other things I'd like to think about is the pair programmer approach, right?

You're a senior programmer.

You pair program with a junior programmer all the time or another senior programmer.

The idea is you bounce ideas off of each other.

Ultimately the person at the keyboard is the one responsible, but you're both working together, contributing ideas, solving the problem together.

I like to think of AI's usefulness in that model as well too, where AI can sit there as a pair programmer for you, right, and say, you know, and this is one of the things I tend to do is I'll do something like, okay, I need to change the order of this and do it most effectively and I need to do something and I need to have blah, blah, blah happen.

And this.

What's the most idiomatic way to accomplish that?

Here.

Plunk.

Okay, that's, that's close to what I wanted to do, but not quite, but I can massage it in there and how it fits and, and I've got my code so I can think through some of those sorts of conversations.

And that, and those are the conversations I tend to have with an AI when I'm writing software is can you what's the best way to do this?

Or what's the preferred way than most people would expect to see this written so that it's easy for them to read later?

You know, those sorts of questions I find AI very helpful with as well.

I totally agree with that.

And I think that this is actually another very interesting area, because usually when you're pair programming with someone like Lee, if you and I build something, neither one of us know how to, you know, build a programming language from scratch, or maybe you do, right?

But I don't.

But technically, the AI does.

Like, it's seen it, it knows how to do that.

Could it build an operating system?

I mean, probably, right?

It's seen it.

It knows what that looks like.

It can.

It can invert binary trees and it can do a bubble source and all kinds of stuff.

It can solve really complex algorithms.

And so that's a kind of a crazy position to be in as a developer, because you have this pair programmer that literally has the sum total knowledge of programming languages and algorithms.

Right there.

Right there.

But at the same time, it's so careless that you cannot just let it go and implement things in your code because it'll be like, sure.

I've often likened this like AI.

It's almost like a consultant.

It's like the smartest consultant in the world that does not give a rip about your code base and will is more than happy to just go in and it's like it has the knowledge of the best programmer that's ever lived, but the discipline in the experience of someone who's never written code a day in their life.

And so when you're brainstorming with it, you have the opportunity for it to direct you with, with its untold and unlimited knowledge, just like you said.

And there's certain prompt strategies that people can use here.

One of them is called pros and cons.

So listeners can try this.

But if you go to the chat, either in Visual Studio code or your editor of choice, and you want to make sure that you're in like an ask mode so that it doesn't write code and just say, you know, hey, I need a persistent data.

This is an example.

I need a persistent database connection in this web app.

What are five different ways that I can do that?

Give me the pros and cons for each.

And then it will list out and be like, you can do a singleton.

Here's why that's good.

Here's where that can go bad.

And the reason why that's super helpful is that the pros and cons will highlight edge cases.

And this is the problem is that the AI doesn't know the edge cases and neither do you.

But IT can help identify them if you make it give you a bunch of options.

It's this same idea, this mindset of abundance that you can now have it spit out code and ideas that are thousands and thousands and thousands of lines long and then just throw away what you don't want and just move right on.

So we've been talking a lot about what I would call the professional software developer and the use of AI.

Let's talk about AI for development purposes.

For the non professional developer.

This is the person who writes a lot of scripts in Excel spreadsheets or the person who just needs a little bit of code here and there for some project they're working on.

So and so that's not a professional developer, but still finds themselves in need of code once in a while.

The low code user, if you will, what about them, what are their needs and how are they different from the professional developer needs when it comes to using AI?

You know, I run into this a lot when we do Microsoft's Ignite event, which is primarily like an IT Pro.

And I'll talk to people there and they'll say I'm not a developer.

But then they'll go on to describe some extremely complex PowerShell script that they've written.

And I am always thinking, but you are a developer.

Like that is not what you're doing here is not easy.

And in fact, dealing with infrastructure via code is oftentimes extremely complex.

And I actually think that it's a little bit trickier for these folks because the AI doesn't know anything about your infrastructure, right?

It's one thing for IT to write code, that's handling logic, that's all happening here.

But what if you need to, you know, write a script that stands up a server?

And I think so I think for these folks, what number one, the same mindset applies.

The abundance mindset that you can just basically automate anything and everything, right?

Agents are extremely good at scripting.

In other words, if I'm, if I'm someone who's not a web developer, but I know backend systems really well, or I'm an infrastructure person, I can now do things that I previously wouldn't do because I just don't know enough about them or I hate them.

So for instance, I might stand up an interface to some data source that I have because I can now do that.

These are the kinds of Things that you wouldn't do before because there's no value add there.

And you can just do them now.

Right.

It's nothing.

The cost of coding is so cheap now that you can, yes, you can do it.

It's almost free.

Right, right.

And if you don't like it, then don't use it, Just throw it away.

Right.

It's no big deal.

It's not like you spent any time on it.

And so I also think as just as a final note here, I would like to know from other people, like what are they doing with it?

I think part of being honest about AI right now is that we just don't know the places where it's actually most useful.

We're finding them all the time.

But to say that we fully understand how the technology impacts the different fields would be just massively incorrect.

So if you're coming to build, which will be in May, then come find us at the VS code booth.

We'll have a big booth.

I'll most likely be there.

You can come find me very short, very bald, or you just yell Burke and then come tell me what you're doing with AI.

If you're an IT pro, if you consider yourself a non developer.

Although I would argue that everybody's a developer at some level.

Yeah, makes, makes sense.

So we, we've talked a lot about, you know, AI today for most developers and non developers.

What about the next level of AI?

What the AIs that are coming next?

You know, you know, obviously agentic AI is a big thing now, but there's more beyond that as well.

I think that the again, I exist on the agent edge, we'll call it the agent edge.

And this is having agents do everything.

And I think that the next.

Sort.

Of Rubicon that we need to cross here is what we're calling spec driven development where I am using AI to write specifications and then I'm feeding the specifications back in so that I actually can get the agent to build quality software that we can trust and that we can put in production.

There are projects for this like Speckit is, is comes to mind.

It's kind of like the most prolific one at the moment.

I encourage people to check that out.

Can we actually get to a point where the AI is writing a significant amount of the code and I Burke, instead of over here spending two hours trying to figure out how to center a div, I am solving 5, 6, 7, 8, 10 problems in that same window.

And then I think so I think that's like the, that's the horizon that we'd like to get to.

And then the knock on question to that is, well, wait a minute, does that mean as a developer that I'm not writing code anymore?

And I think the answer would be is you're not writing code in the sense that you write it today.

But also your whole job as a developer cannot be reviewing code from agents and reviewing specifications.

That sounds terrible.

Like, let's just be honest, that doesn't sound like a fun job for anyone.

And so I think that we need to develop systems number one that can check the code that is being written.

And I think that as developers, we're probably going to get to a point where it's less about the lines of code that we write and more about the systems that we architect.

But we're going to be building much faster than we ever have before.

One of the things that I think about is I've been in the industry a long time and when I first started programming I was writing in machine language.

Not assembly language, but machine language ones and zeros.

Here's the code that this processor uses for adding this value to a register.

And that's the level of coding that I was doing.

And the move up to assembly language, where you actually could do things like go subs and procedures and functions that you could actually build in and attach to modules.

But still writing assembly language, you know, low level machine language, the whole act of adding an assembler to that process was a huge savings in time and energy.

And then you move up the level and you start writing in Pascal and C and Fortran and you start realizing higher level languages and compilers and the advantages of that, that whole move up the curve, you're now not really programming anymore because you're not doing the ones and zeros that the processor uses.

You're programming at a much higher level and you're still doing programming, but it's at a much higher level than you were before.

And then, you know, you know, then we started looking at higher level programming languages, you know, Ruby and then Java and then now higher level languages on top of that.

And ultimately now we're, we're to the model where is AI at the point where it can provide a higher level programming abstraction doesn't remove the programming, but a higher level programming abstraction above what we've already done before.

And that's all it is.

It's a level layer of abstraction on top that's very sophisticated, but it's still doing the same things you were doing before.

It's a little bit different approach than to say, you know, have the AI do the code and we'll do something else like test it.

You know, it's a very different model than that.

It's just.

It's making us more efficient at doing more things as opposed to taking jobs away from us.

I would.

So I would totally agree with that.

I think that's really well said.

That is just another abstraction.

It's just that it's a pretty big leap up in the abstraction tree.

We kind of went from, you know, like incremental and then we jumped like, way to the top and skipped a lot of steps in between.

And I do agree with you that, like, as a dev, do I just want to be writing tests and reviewing specs and agent code.

I do not.

But at the same time, only a very skilled developer can use AI to actually get anything done at all.

The old adage about software like the first 80% is easy.

It takes 80% of the time.

It's not bad.

And the last 20% takes the other 80% of the time.

Right.

It's always that last bit.

And that last bit is not.

Any AI is no better at that than we are.

Right.

It struggles so much with that last 20%, just the same way that we do.

So I think that we can think about it as AI can actually now do the 80% and we can focus on that last 20%, but at least we don't have to spend that first 80%.

AI can actually do that part because that's the easy part.

Right?

It can do that, and that makes.

A lot of sense.

I think my worry with that is how good is it at the 80%, meaning the code that it's producing, when it's doing that very quick 80%, let's assume it was more of a vibe programming model where it's doing 80% of the work.

We're coming back with all this code.

How efficient is it, how well designed is it, how understandable is it?

And oh, by the way, you haven't ever looked at this.

So now you need to understand this code that you've never looked at before versus code that you've written.

And we all know that supporting, testing, modifying, changing, maintaining code that you've never seen before is significantly harder than code that you helped develop.

Yes.

Although I guess the rejoinder to that would be that it is already the case that we're writing.

We're having to work with code that we've never seen before.

And the reason that we've never seen it before is because we wrote it six months ago and we do not remember it at all.

I don't know if anybody else knows what this feels like.

To go back to a project that you wrote that you were really proud of at one point and be like, I have no idea how this thing works.

Your context window just degrades and you don't even know about the code that you wrote yourself.

And so I think that if the AI is writing the code and you're having to do that, that's not a whole lot different than the way that we work today in a lot of ways.

With the added benefit that the AI can now explain that code to you.

Right?

You can see, like, what's going on here.

Where is this coming from?

Why is this happening?

And in the past, you had to do that.

I had to do that, and that took a lot of time.

So I'm getting off of AI for a little bit here to kind of, let's say an ending question here now.

Um, I. I've.

In recent projects, I've moved to the jetbrain suite simply because I like the integration that comes with that.

For the things I'm trying to do.

Tell me, but I love VS code.

Tell me why I should move back and use VS code primarily.

If your workflow and experience is better in JetBrains, why should you move back to Visual Studio code?

I don't think that you should.

I think that just as a general rule of thumb, people should use the tools and the frameworks that work best for them and you shouldn't feel compelled to move somewhere else just because someone said this is the new hottest thing, we should just reject that outright.

However, I think you should couple that with some healthy curiosity about does this other thing offer a better experience and let me try it out and see if it actually does.

And if it does, then it's absolutely worth adopting.

So I would say for, you know, if I was going to give you the pitch for Visual Studio Code, you know, the primary pitch would be because it's really fast and because it has great extensions in it to support a variety of things, it's highly configurable.

And because Copilot is easily the best deal in AI by a huge margin.

So that.

That would be my pitch on why you should try it.

But again, I wouldn't.

I don't think I would say you should use it.

You shouldn't.

Unless you find that it's better.

And if it isn't better, you should tell me why so that we can go work on.

On making it as.

As the best possible experience it can be.

That's a better answer than I was expecting.

That's a great answer.

So I appreciate that answer.

That's.

That, that's, that's wonderful.

And in fact, the matter is, like I said, I've used them both for various projects.

I happen to be working on a project now that I'm using Jet.

Really am enjoying it.

I love the AI integration there, but it is not as good as what you have in VS code.

But I find the integration with it is pretty good.

So it's one of those catch 20 things.

I like a lot of things, but there's a lot of things I'm missing there too.

So.

Yeah, yeah, that's what's so great for developers is like there's.

Think about all the choice that you have when it comes to AI, when it comes to agents, when it comes to editors.

Like as a developer, all of this is good for us, all of it.

To have all this selection.

All these tools are great.

JetBrains makes fantastic products.

Okay, give me your last closing thought.

My last closing thought, My last closing thought is that I'm tired.

So if you're listening to this and you're tired, and what I mean by that is that while I was, I was out on vacation and while I was out, I think like five new tools dropped, two new models dropped, a lot of opinions changed about AI and like, what's where this is actually going.

And I would say that if, if that's how you feel, that you're not alone and that if anybody tells you that they've got this completely figured out in terms of they have the optimal AI workflow, they've got it down just somehow, agents are just magically solving all the problems in their lives.

You should have a healthy amount of skepticism towards that because that just simply isn't the case.

And you should relieve yourself of the stress and the anxiety that you're being left behind and you don't know what's going on because I don't know all the time what's going on.

And I'm still trying to figure it all out.

So if you feel like I feel you're in good company.

Some of the best AI advice I've heard in a long time.

Thank you for that.

So my guest today has been Burke Holland.

Burke is the principal developer advocate working on the VS code team in Microsoft and a firm believer in the city of Nashville.

Burke, thank you so much for joining me on Software Architecture Insights.

Thanks for having me, Lee.

Bye, everybody.

Thank you for joining us on Software Architecture Insights.

If you found this episode interesting, please tell your friends and colleagues you can listen to Software Architecture Insights on all of the major podcast platforms.

And if you want more from me, take a look at some of my many articles@softwarearchitectureinsights.com and while you're there, join the 2,000 people who have subscribed to my newsletter so you always get my latest content as soon as it is available.

Thank you for listening to Software Architecture Insights.