Coffee With Digital Trailblazers
AI Coding Competencies: Hype, Realities, and the Future
This episode of Coffee with Digital Trailblazers focused on AI coding competencies, where Isaac hosted a discussion with two special guests, Dave Bachman and David Cassel, about the current state and future of AI-powered software development tools. The conversation explored how AI tools like Claude and Manus are being used in development, with Dave sharing his experience building 15-16 functional applications and David discussing his practical approach to implementing AI tools with his teams. Key themes included the importance of proper requirements engineering and iterative development approaches, the need for enhanced quality assurance processes, and concerns about security and risk mitigation when using AI-generated code. The discussion also touched on the debate around artificial general intelligence (AGI) and its feasibility, with Dave explaining his perspective on the challenges of achieving consistent reward signals in complex domains.
Hosted by Isaac Sacolick, CEO of StarCIO
[00:00:01] Speaker A: Greetings, everyone.
Welcome to this week’s coffee with digital Trailblazers. Happy to be here this Friday in April for our 169th episode.
And this one, I almost guarantee you, will be a special one. I think all of you have read about or even used AI to develop code or learn about how AI is doing more of our coding encoding. What I mean here specifically is software development.
And probably some of you who are a little bit more following the news around this, somewhere in the last, I don’t know, five or six months, there’s been just an explosion of improvement in the core AI models, particularly Codex and Anthropics.
What’s it called, Claudia? Claude Compute. Do I have that right? I’ll remember.
[00:00:58] Speaker B: Claude Code.
[00:00:59] Speaker A: Claude Code. There we go. Thank you. So they’ve gotten a lot, lot better. And over the last year there’s been entire tools and platforms, including Vibe coding platforms that have emerged. And so software development as we know it from those of us who have been doing development for a long time has changed dramatically.
And that’s going to be our discussion today. AI coding competencies.
Where is their hype? What is the reality?
What do we need to do to be able to use these tools responsibly? And what is the future of software development look like now that many of us are using AI coding competencies and tools? I have some data for you that I pulled.
One comes from Panto. It talks about AI coding.
And the most interesting piece that I picked out of this, not Only just the 84% of developers are using it, 51% daily, but you see a lot of metrics on the productivity improvements that AI is driving.
They actually have this measured through a study saying it saves 3.6 hours per week per developer using AI coding tools. Not really quite 10%, even though a lot of the studies quote 20 to 30%.
But now we have it quantified into some hours.
On the flip side, when we talk about realities and responsibilities, some really good data here from Code Rabbit that we have to just wrap our arms around. That pull request for those of you who know terminology from GitHub and how code is checked in, 1.4 times more critical issues coming from from AI generated code and major issues that’s 1.7 times more.
Some of the issues, password handling, insecure object referencing and some of the defects it’s creating around business logic, concurrency and exception handling.
I have two articles on vibe coding, one of them is on InfoWorld, one of them I just finished this week that compared Vibe coding and spec driven development.
For those of you who don’t know what Vibe coding is, it essentially means I’m having a conversation with an AI code generating tool about building an entire application and it will start building one after that first prompt.
It will be very transparent in terms of what it’s building.
You can continue to refine the information so that it gets to a better requirement. 92% of US developers said they have used it. Fortune 500 companies say they have a platform around it. Interesting enough, the productivity around these tools is split, with the most senior developers getting the most benefit from using Vibe coding tools and junior developers admitting they’ve used these tools but aren’t fully understanding how they’re using them, and then some of the things that they’re using them for. And so maybe we’ll dive into a little bit more around that with Dave and David, our two special guests.
Spec driven development is a variant of Vibe coding. And what that does is it puts the end user through a process to create actual specs, documents, things like architecture designs, requirements documents, task lists, lets the developer review those and collaborate with stakeholders around that, and then that spec becomes what’s used to develop the code. On the right hand side, I just pulled some quotes for you from professor and Dr. David Bachman’s blog. He has some really good posts there that I encourage all of you to go check out.
Now, anyone could build software, but maybe AGI is really impossible. I really like that post, Dave, and I hope you’ll comment on that when we get to the future of software development.
David Cassell also has a blog is one post that gets into the details on software development in the age of AI and really a precursor to this discussion today on AI coding competencies. I got a bunch of people who commented on what awed them and inspired them and what really blew up in their face. So that’s our discussion today. And with that I really want to jump in.
First, welcome Professor Dave Bachmann to the floor. Dave and I have been friends going back to my college years, and I was just reminding him that I took his chaos theory class during my senior year reading through James Glick’s book.
Dave, I bring that up because when I studied neural networks in grad school, when I studied artificial intelligence there, and my thesis was on a machine learning algorithm called the Projection on Convex Sets, it was less about experimenting computing, it was a lot more around math theory.
And so I got a really strong appreciation around how reinforcement learning works, how a whole bunch of natural language processing algorithms work. And nowadays most of the people Using these tools go right into the practice and the experimentation and very little into the overall science and math behind them.
So maybe you’ll comment on that. But let’s just start with you’ve used some tools, you’ve written about them.
Give us a little bit of background of yourself, which tools you’ve used and what’s really awed you in the competencies of these tools and what do you think is overhyped. Welcome, Dave.
[00:07:05] Speaker B: Thank you, Isaac. It’s great to be here and I appreciate the invitation.
So, yeah, I’ve been a professor of mathematics since 1999, which is scary to say. I’ve been teaching artificial intelligence and machine learning for at least the last 10 years. That actually started with boot camp, a 12 week intensive boot camp that Google ran for faculty where they brought me into their Mountain View facility and into their New York facility and worked side by side with Google software engineers for five days a week, for eight hours a day for 12 weeks or something. So it was really intensive and it was really transformative. My own experience, my own knowledge base and my own teaching. So since then I’ve almost exclusively been teaching classes on machine learning and artificial intelligence. And nowadays of course, all the kids want to understand what’s going on because that’s where their employment’s going to be and they’re going to have to be using AI tools whether or not they’re going to be going into software engineering. And so I help them understand exactly what you said, Isaac. A lot of the mathematics behind it, understanding these algorithms, they build neural networks from scratch, which is raw based Python, all the way up to Pytorch and more advanced libraries and I’ll have them construct even a transformer model from scratch. So we’ve got to know the ins and outs of how all these things work. And I try to keep them up to date on newer developments like mixture of experts models and whatever. And I’ve been actively developing a lot of classes on how to use the newer tools like agent decoding and all the new things you hear about skills, mcp, managing parallel agents, all of this are things that I try to keep abreast with and do my own experimentation with and partly for my own benefit and partly for my students.
What Isaac said is absolutely correct. About five months ago, around December, there was a serious step change in the ability of these models to write code and create full functional software applications.
Cloud code was first, as Isaac said, and then Codex caught up soon after that. And I’ve built about 15 to 16 different highly functional Apps, I would say full development packages since then, just in the past few months, kind of alternating between codecs and cloud code. So I understand the capabilities of both and it’s just impossible to keep up. Even just yesterday, Opus 4.7 came out. You’ve probably all heard the rumors of Mythos Codex Desktop has been revised in the last week. Claude Code Desktop has been revised in the last week. So it’s just unbelievable the pace of development.
[00:09:49] Speaker A: Dave, Dave, can you just walk us through a use case that wowed you that you didn’t expect to work or just illustrated some capabilities that are worth illustrating what, what these tools are capable of today?
[00:10:07] Speaker B: Yeah, absolutely.
So I would say up until last November, December, the way I’d use these tools was by if I had a component of a larger package or if I had a single file package, then I could essentially cut and paste into a chat window and ask for suggestions on the code or even have it write single file code.
You know, I could use, I used cursor a lot to do some, what’s now called agentic coding, where it would write out some, some chunks of the code itself. But what really changed and what really surprised me, it did catch me off guard, was its ability to create multi file, multi language packages that all work together and work in many cases seamlessly. Not always, of course. I’m sure we’ll get to the limitations of these things, but you asked about the things that surprised me because when it works, it’s just, it seems like magic.
Even to those of us who understand some of the nuts and bolts on this, it still seems like magic.
[00:11:08] Speaker A: Thank you, Dave. Let’s move on to David Cassell. David’s been a listener of the Coffee with Digital Trailblazers for a few episodes.
David, just introduce yourself and give us a sense of what have you been using the AI coding tools to do, which ones and what’s odd you and what do you think is overhyped?
[00:11:30] Speaker C: Sure. Thanks, Isaac. Great to be here. I’ve been in software development professionally for about 30 years now, working as a fractional CTO. So really emphasizing the leadership aspects of working with technology, but still very hands on.
And a major part of technology leadership today is how do we get our teams to embrace and work with these changes, but do it in a responsible way that is productive but still accountable.
[00:12:01] Speaker D: Right.
[00:12:02] Speaker C: And so my focus on this is a very practical approach. I’m looking at tying technology work to business outcomes.
Funny thing, back in 94, I went to a PhD program in artificial intelligence.
And so you can imagine AI at that time, very different animal than it is today.
Um, and I actually, you know, you talked about it being very mathematically driven at the time, and that was never really my strong suit. I like building things.
So I ended up deciding to shift focus and, and lean into software engineering instead.
So fast forward to now.
Been spending a lot of time working with these tools and getting my, my team to work with them as well.
Personally, I’ve been working with Manus, Claude and Microsoft Copilot primarily.
And one of the things I found really interesting about Manus in particular is the first one I used this way was I can set up an issue on GitHub, right? A ticket that’s got a nice description of here’s what it is I want to accomplish, here’s some implementation notes about which files I think are relevant or an approach I might want to take.
Same kind of input I would give to maybe a junior developer.
And then I can give Manus a GitHub token so that it can go read the issue, it will digest it, think about it, I’ll tell it, you know, ask clarifying questions as needed. So we’ll discuss it a little bit.
And then when it presents an approach, and I like the approach that it has in mind, I say, cool, go create a pr.
And it does. And just with that level of interaction, it’s kind of like working with another human developer. It’s a collaboration where I’m specifying what it is I want and it goes ahead and does it.
Obviously not perfect, but we don’t expect perfect results from our human developers either.
That’s the positive side.
The negatives again, there’s plenty of room to talk, but in terms of overhyped, I think it’s critical to remember that this is not a silver bullet.
These AI coding tools are amazing tools, but the thing I keep telling everybody who will listen is it’s a tool. The person using the tool remains responsible for the output, right? Whatever happens as a result, you don’t get to blame the AI and say, well, that’s what Claude came up with.
It’s our responsibility to say, I’ve got this result, I’m going to review it and I’m going to take ownership of what it’s doing and make sure that result is actually taking us in the right direction.
[00:15:06] Speaker A: David, can you comment? You mentioned it’s not perfect. That’s been my experience using these tools, is that, you know, when I asked it to create some regular expressions for me, you know, and, you know, I was parsing some Web pages and trying to extract some information.
It is pretty, you know, it worked well for the instance that I gave it, but it did a miserable job of anything that could be generalized.
It just made a ton of assumptions. And any QA tester who knows how to test for boundary conditions or parameter testing was going to find issues with it.
And it took quite a bit of back and forth and my own knowledge of how regular expressions work to finally get it to do something that was valuable. And that was a snippet of code that was maybe 15 lines.
Now I use a vibe coding platform.
It’s spitting out directories and files, it’s creating the entire scaffolding of an application and then eventually it’s getting into some business logic.
I mean, am I change, you know, so tell me a little bit what you mean by not perfect. I give you my example and then go into a little bit of what does it take to validate? You said taking responsibility. What do developers need to do to make sure that they’re going to accept that pr?
[00:16:37] Speaker C: Sure. Like a common part of the development process is when one developer creates a pull request to say, you know, here’s some changes I want to submit that goes through a review process where another human being is going to look through that and say, does this work? Is this a good approach? Is it maintainable? Is it scalable? Is it secure?
All the kind of things we want to look for, right? And we as human developers still retain that responsibility.
Real simple example, I managed to come up with a fairly simple crud search kind of app a little while ago.
And I wanted some filters that the users could use to find certain things.
And Manus approach was okay, cool, I’m going to do a database query, return all the data to the browser and do the filtering client side, which for a small set of data, okay, I guess that’s valid, but it’s completely not scalable and it’s not generally the way we do things. So I pointed that out to Manus and said, I want the filtering to happen at the database level.
It said, okay, fine, and made a bunch of changes and we got where we needed to be. But it took that thinking about how is this actually working to get there.
[00:18:00] Speaker A: Thank you, go ahead. Sorry.
[00:18:02] Speaker C: Just one other quick thing I like to throw in is that I like to have the AI tools have a fairly focused thing to do.
And I always ask them, you know, write some unit tests for this. Right? Give me. If we don’t already have a test harness, then let’s create one. Let’s come up with some unit tests. And one of the advantages of that is that once we have a test harness, we can go in as humans and say, here’s a couple more use cases I want you to make sure you’re testing.
And that’s a nice way to just kind of expose where the problems are and give it some parameters to work with.
[00:18:39] Speaker A: Thank you, David. Dave, I’m going to bring you back next.
Same question.
You know, where have you seen the AI exceed expectations and where have you seen it not perfect and needs to get into fixing or iterating improvements to what you’ve developed?
[00:18:58] Speaker B: Yeah, be happy to comment on that. And Isaac, actually I loved one thing you said, which was that when it didn’t work, you had to really rely on your own knowledge to get it to work. And that is, to me, that’s the key. It’s not necessarily the coding ability, it’s understanding what it is that you’re building, understanding when it’s working and when it’s not working, and then being able to guide the agent to tell it what what’s wrong and what it needs to fix.
So like David said, it’s a bit like working with the junior software developer where you have to supervise. You’re now the manager, you’re the supervisor, and you’re still the one ultimately responsible for making sure the thing works. And that’s really going to rely on you really understanding what it’s supposed to do.
What David said about unit test is absolutely right. So when I write an application these days, it’s not uncommon for me to sit down for two hours and write just the initial prompt and then let it think for 20 minutes. And at the end of 20 minutes it’s written 10,000 lines of code. I can’t possibly manually review all 10,000 lines of code, but I can write a lot of unit tests and I can make sure that I have pretty high confidence that it’s actually working.
[00:20:16] Speaker A: Before I let you go, I got Derek, I’ve got Joanne, John, all raising their hands when I did the piece and I literally just finished it. On Vibe coding and Spec Driven Development, I found a whole bunch of articles saying, look, non technical people can use these tools to build applications.
Even what you just said, it took a couple hours to write a prompt and it’s not feasible for you to do an exhaustive code review of what’s inside these things.
Dave, give me your citizen development using Vibe coding tools Realistic today, is it? Or is it? You know, I really need to have somebody who’s going to be able to rely on their knowledge to understand how this thing is working.
[00:21:06] Speaker B: It depends a lot on what you’re building, what you want to build.
So I’d say I’ve given a lot of workshops for people. If any of your listeners are interested, I’m happy to come and do a workshop for them within an hour. I’ve gotten very non technical people up to speed to the point where they can create fully functional apps, but the apps they make have to rely on their own knowledge base. So you don’t necessarily have to know how to code, but you have to know what it is you want to build at every level, sometimes even where you want the buttons to be, what shape you want the buttons, what should happen when you click here versus there, what you’re going to see, what you’re not going to see. So you have to really, you know, if it’s a really nice functional app, you have to really understand what is going to happen as the user interacts with it and what, what it’s supposed to do under the hood so you can guide it appropriately. So it doesn’t necessarily mean you have to know how to write code, but you have to have be technically minded enough so that you can guide it in that way.
[00:22:11] Speaker A: Thank you, Dave. I’m going to open up the floor to my other speakers, folks. You can comment or you can ask a question, or you can do both. Hello Derek, thank you for being patient.
[00:22:25] Speaker E: This is a great conversation and I’m enthralled and intrigued with the way you guys have gone through this development, especially over the number of years. But the question I have is I don’t actually work with AI code development, but I do work with AI code developers. And one of the questions I always have is I’m looking at this from a resilience and risk factor as you guys are working with these entities and you’re talking about 10,000 lines of code to be generated. How are you guys working with the AI coding tools where it may introduce silent risk? How are you dealing with the tech debt or the insecurities or the faults that it may create, and what systems or methodologies or agents or other tools are used to help do code scrubbing, to help mitigate these things as you’re still learning the process moving forward?
[00:23:08] Speaker A: David, do you want to take that one?
[00:23:12] Speaker C: Yeah, I’d be happy to.
So I’d say in a way the answer to that hasn’t changed recently, right? Because the change in process is we’re spending a lot less time on one aspect of the software development process, but we’re distributing that time to other parts.
So the act of actually writing code has shrunk drastically. We’re spending a lot less time on that, but we need to be much more precise in what we’re specifying upfront. Right. We need to be thinking about what is it we’re trying to create, how should that work, how is it going to interact with other systems, how do we secure that?
The QA aspects, I see that in my mind, QA has actually drastically risen in importance as part of the overall process because it’s easy to get to a point where there’s so much code, it’s hard to understand the details of it. It’s hard to make sure we’re looking at every individual pie.
But having that mindset of how do I break this?
Right, Is really, really important.
So that’s one aspect of it I think, is that the, the things we’ve done in the past, the, the human reviews, the QA process, that remains critical.
The other thing I tend to push for is, you know, if, If I see a 10, 000 line PR, I’m rejecting it.
I think it’s beneficial to really try to be focused on a component at a time. Right. Let’s build this from the ground up like we do, so that we’re. We’re getting chunks of things that we can actually pay attention to and really do our proper due diligence on at a reasonable pace.
[00:25:01] Speaker A: David, can you do that? I mean, like, you know, it wants my, my attempt in using replit. You know, it wants to spit out the whole thing. Shooting match. You know, it was done before I started responding to its prompt. And now I’m going to come back to it and say, you know, break down Dave’s 10,000 lines of code into individual PR so I could see what’s going on. It will respond to that.
[00:25:26] Speaker C: Well, we can tell it to do things like present to me the architecture you intend to use.
Right. And so, you know, don’t write any code yet. Just tell me how you plan to approach this. What are the components? And then we can look at that and say, all right, that, that seems like a good choice for the database. A good choice. The front end, I don’t see how this is going to scale because there’s no load balancer in here, for example, just to throw something in.
So having that iterative process of kind of building up to say, let’s look at it at this level, and then let’s break it down and Then once we’ve got a good kind of overall approach and overall structure, now we can say, all right, let’s focus on the data management aspect to this.
What happens, you know, how are we going to represent our data? What does that look like? Okay, good. So now go ahead and give me the schema, right? Give me a database schema. Give me whatever I’m going to need for that component. Now let’s do a careful review and then we can kind of build up from there. Right. So instead of trying to one shot it, which puts us in a really difficult position to evaluate the quality of the work, we can instruct it to give it to us a piece at a time.
[00:26:40] Speaker A: Got it. Hi, Joanne, you have insight a question or both for the, for our team here?
[00:26:49] Speaker F: Well, sorry, I didn’t realize I was on mute. I guess both. I would say that one of the things that I find is dramatically off is from internal teams in large corporations where they look at, you know, the hype around vibe coding and they don’t approach building AI, whether it’s generative or agentic, but primarily on the agentic side from a systems design point of view.
And I think that’s one of the things that nobody is talking about because like, when I give a PR or anything else to our principal architect, I do it in a way that is designed to give him like, here’s a KPI, here’s the dependencies of that KPI, here’s the co dependencies, here’s the cross references, here’s the processes that they most likely connect to and make sure that these nodes are available in the knowledge graph.
And I’m saying this from the perspective of we don’t just sit down with cursor and write code.
We do a lot of systems thinking around this because if you don’t, you end up with challenges in memory or challenges in inferencing or ontologies or whatever. And I think that’s an area that tends to be largely overlooked. And so my question to your two guests is, do you find the same.
[00:28:21] Speaker A: I want Dave to take this one. Dave, you illustrated a lot of expertise to be able to have a meaningful dialogue, but to achieve the economics that OpenAI and Anthropic and others are trying to get out of these tools.
They’re making it sound like anybody can use this very easily without a lot of experience. Back to that question. And I agree with Joanne that systems thinking is needed here. I very much agree with Dave David, that QA is a much more important skill set. And I love this idea of breaking down the design into components and working on those individually.
How do we close that gap when the technology providers and even the CIOs may not want this, they may just want to jump in and get solutions done quickly?
[00:29:13] Speaker B: Yeah, I’m happy to respond to that. And actually both, both Joanne and David also said some really important terms of systems thinking is what Joanne said. David used the word planning. I think that is vitally important and can’t be emphasized enough. In fact, I think OpenAI and Anthropic are aware of this.
Generally the best practice when you start a new project is to put it explicitly in something called plan mode.
Both companies have that and they encourage you to dialogue in this plan mode before you ever have it write code.
It’s really crucial there that you go back and forth with it. It’ll tell you how it’s going to structure the repo before it writes code and then you can approve of that, you can modify that.
All of those good practices of systems thinking and all of that is vitally important to end up with something.
I also agree that incremental app development is vitally important and you shouldn’t ever expect an app to just come out with a single prompt. That’s not going to happen, especially if it’s a complicated enough app.
As I said, I’ll write a single prompt where I describe a full app and often what I have in mind are all of the stages that I think the development’s going to go through and I’ll lay that all out with the agent and then I’ll say only do the first stage. And what that helps it do is it structures the repo in a way that will be beneficial when later down the road. And that’s why the initial commit often is quite large, because a lot of that is just scaffolding to not actually code yet. And then I’ll incrementally after that, ask it to add features or change features, see what’s working, see what’s not working, run tests and all of that. It’s a long process. You shouldn’t ever expect that right off the bat you’re going to get a fully functional app. It can take weeks or in some cases months. I’m a single app developer developer, so for me it’s usually on the order of weeks.
[00:31:17] Speaker A: It’s really interesting.
So David mentioned QA as a shift and Dave, you’re highlighting the amount of time and your expertise in basically writing good detailed requirements and doing the iteratively so you could see the AI respond to them. I mean, historically, enterprise teams are terrible at writing requirements.
Is that something when you’re doing your teaching, are you seeing, are you going to have, are you reinforcing that or how are you reinforcing that through your workshops?
[00:31:52] Speaker B: Yeah, good question. It’s hard in a workshop, in a one hour workshop where you’re trying to get novices from zero to app development. It’s hard to emphasize this enough with my students. Yeah, I’ll have a lot of assignments where they’ll turn in their requirements, their specs for their app before they ever actually code it and we’ll talk about what’s reasonable, what’s not reasonable. I think these are just good practices and you’re absolutely right, it’s difficult, it’s not easy and it can be done wrong much more easily than it can be done right.
[00:32:23] Speaker A: Thank you, Dave. John, let me take my quick break and then we’ll come back to your question. I think I saw Joe had a question as well. Folks, welcome to this week’s coffee with Digital Trailblazers.
We have Dave and David speaking about AI coding competencies, hype realities and the future.
Very exciting conversation for those who don’t know, which is probably everybody here except for the folks that are being who are there.
We had a dinner with Digital Trailblazers earlier this week. I invited many of our speakers and our friends for the coffee at Digital Trailblazers to join me for dinner. We did this in New York City and pictured in here is Joe, Liz, Michael, Heather, Derek and a whole bunch of others who have been here some of the time. I’m there in the middle and it was a fascinating, fabulous evening, a lot of fun and just want to reach out to you this network. We meet every Friday at 11am Eastern time. There are more opportunities to meet. I will be in Orlando, Vegas, Anaheim, Tucson, Houston over just the next six weeks doing events. If you’re in any of those cities, do let me know that. To meet up. I’m going to try to meet up with Dave out when I’m in Anaheim.
So yes, we are expanding this program, doing some new types of events and hope you’ll reach out to us and let us know that you want to be involved with them. On the 24th next week we’re going to talk about tomorrow’s workforce apprenticeship pathways for the AI driven organization and on May 1st we’ll be talking about this is John’s suggestion, AI POCs that matter, selecting, pivoting and delivering value. John, I really hope you could be here for that One. And I will announce all of May’s episode coming next week. John, welcome to the floor. You could share an experience with cogeneration or you can ask Dave or David a question. Welcome, John.
[00:34:33] Speaker D: Hi Isaac, thank you for having me on. And I, I saw that the power for these things, creating codes when I used it to build some utilities and very simple things like take something out of an email and put it in that blob and translate it and variations of that.
And then lately I’ve been using them actually to try to make my websites better for SEO.
And one of the things I saw that’s just kind of really resonating with me is that when I was at the big tech companies, even people that are very, very experienced, they have standards that they follow and they get their code reviewed by kind of security experts at these large companies. And so I guess the question I really wanted to ask Dave and Dave was if you guys could really provide some guidance on what kind of applications should be written and what kind of applications should people really shy away from writing with fibcode and AI and if, you know, like if you could speak about this at levels like beginners and more moderate and advanced developers. So just love to hear your thoughts on kind of like where, where you recommend people go and what, what do you recommend people maybe not do.
[00:35:44] Speaker A: David, you want to take that one?
[00:35:45] Speaker C: Sure.
I, with your permission, John, I’d actually like to reframe the question slightly.
[00:35:52] Speaker D: Yeah, yeah, by all means.
[00:35:55] Speaker C: So, so the question you asked is what kind of applications should we use these tools to approach? And I’d like to reframe that as how should we approach different kinds of projects? Right.
So for example, if your VP of marketing can vibe code his way through some kind of a little utility for which he’s the only user and the consequences of a wrong result are not a big deal, or they’re obvious and easy to work around.
[00:36:30] Speaker B: Have at it.
[00:36:31] Speaker C: Have a blast.
If that same person submits an 800 line PR to a mission critical system that is driving the business, you gotta shut that down. Right.
And so my point there is that the processes we use are going to be different based on the kind of thing we’re trying to accomplish. So it’s, for me it’s not so much about what can we do with these tools in terms of output, it’s about how do we use them to achieve those outputs. And the answer is different. For a one person little utility versus the run the business application, does that make sense?
[00:37:10] Speaker D: Yeah, I think that’s an absolute great answer, Dave.
[00:37:14] Speaker A: I’m going to challenge you a little bit on this and then we’ll go to Joe and Derek.
You know, I, I used, I think it was replit yesterday to, and, and my prompt was, you know, make me a WordPress plugin that will interface with a third party tool. Let me embed some forms and reports in my WordPress user interface. And before I could give it any more specifications, it spit out a Word plus plugin that I could go and upload.
And I was just like, wait a second, somewhere in here I’m gonna have to give it my API key.
And I have no idea what it’s doing with this and what its code may access or do with the information behind that.
So I bring it up because what might seem like a simple request can lead to disastrous results if you’re not checking things.
[00:38:11] Speaker C: Agreed. And so I’m going to give you an example of something we, we did in our company.
One of our clients has this really specific way that they want to get invoices, right? There’s several different things and they all absolutely, positively have to be in the exact same file, right? A PDF file.
Well, those things are in a bunch of different places.
Hey copilot, write me a Python script that, you know, takes these different files, puts them into the right thing, creates a PDF out of it, and then we can email it away.
Took half an hour, right.
And every time we run that script, every time the person who does invoices runs that script, you know, she, she runs it. You know, she puts things in the right place, she runs the script, and then importantly, she brings it up and checks it. So if it’s wrong, there’s a simple check that you can do and then, okay, fine, we adjust.
The consequences of that script going wrong are not really a big deal. Right.
So that’s a case where I’m not really worried about the software engineering process that goes into that.
The example you gave, there’s, as you mentioned, right. There’s the potential of you’re giving it an API key. You’re, you’re doing something that’s going to affect your public website.
Your business doesn’t exactly fall down and die if the thing doesn’t operate correctly, but there are consequences. Right.
So to me, that raises the bar on the level of software engineering that we want to apply.
[00:39:48] Speaker A: Got it.
Just reading through the comments here, some really good ones. One from Lisa Mohamed’s asked me a question around digital sovereignty.
I think I actually want to, to cover that in a separate discussion. I think there’s a lot to that. So let’s go to Joe. Joe, welcome to the floor.
We’re talking about co generation. Do you have a comment or a question or both?
Joe, you’re on mute.
And Joe was speaking earlier, but we cannot hear Joe.
There he goes.
[00:40:27] Speaker G: Yeah, I’m sorry, I’m having some Internet interruptions here. There are so many things I want to ask these two learned gentlemen. I don’t even know where to start. But, you know, I’m not a. I’m not as prolific a writer as you guys are, but I did write a blog post that talked about what I see as the real danger in AI, and that is not that it’s going to replace the developers, but it’s taking companies down the path of just doing the same old things faster, you know, building faster horses instead of inventing cars. And so I really, I want to ask the question, are we building using AI? Are we approaching software development and the development of the way in which companies can operate and leverage this technology? Are we doing that differently or are we really just delivering the software on Friday instead of next month?
[00:41:19] Speaker A: I can take.
Who wants it? Go ahead.
[00:41:22] Speaker B: Yeah, it depends a lot on the company and how forward thinking the company is. I mean, one of the great powers of these tools is it lets you iterate very, very fast. So you can, you can, if you had just some like crazy harebrained idea for your next app, you just build it in a day or a couple of weeks and it’s done. And then you can see if it works or doesn’t work. And if you are forward thinking enough to use these tools as prototyping tools, where you’re just experimenting with seeing what works and what doesn’t, then I think you could have very, very innovative companies. But I think you’re also right that there’s a lot of companies. I know, I’ve read a lot of articles about companies where the CEO has this directive to his employees saying, use AI somehow to be more efficient and sort of forcing everybody to adopt AI tools and not really knowing how to do that and what to do. And they just interpret it exactly as you said. It’s just a way to boost productivity and do more of the same, just faster.
[00:42:20] Speaker A: Yeah, Joe, I’m seeing a middle area.
You know, there’s one hand taking what we’ve done before and, you know, improve on it. You know, improve a user interface, take something that’s built on a legacy platform and upgrade it. And then there’s, you know, new innovations. I don’t see that happening as much as I’d like it to. That’s why we’re not seeing a lot of gen AI being used to build customer facing applications or interfaces. But in the middle area are things that companies just couldn’t get to either because of a lack of expertise or time or just bandwidth to work on something.
And so now somebody goes and prototypes something that, you know, in a few hours, in Dave’s terms, that pushes a lot of work upstream and downstream about whether they can move it to production.
Right. Upstream to make sure they got the right requirements and downstream to make sure they got the data security and testing right. But a lot of things that are being worked on are just things that the enterprise couldn’t do before. And in some ways it’s competing with what low code and no code was doing before this. Right. Make it easier to build support applications. Derek, love to hear your question.
Yeah.
[00:43:38] Speaker E: Again, great discussion as we continue with this. My question I asked. Artificial intelligence has said it’s going to replace a lot of these entry level jobs. So as a person that’s looking to get into artificial intelligence and letting, looking to get into a corporation that’s implementing and pushing artificial intelligence development, what kind of AI skills should they be looking for? What skills matter when it comes to new developers? The writing code, validating code, doing threat modeling and defending it. How do you guys approach this and what are you teaching your students as far as the things they’re going to need as far as the future of AI development moving forward that they can start start looking at now so they will be able to get a job when it comes that time when they go through college.
[00:44:16] Speaker A: Derek, great, great question. I want both Dave and David to answer this one. David, why don’t you start?
[00:44:22] Speaker C: Sure.
So, fun thing. One of my daughters is actually a computer science major right now.
And you know, five years ago that would look like, hey, that’s brilliant, right? You’re going to be set for life today. It’s a little more squirrely. Right. It’s a little harder to see what that’s going to turn into.
What I’ve been advising her is focus on broad level software engineering. Right. Because the idea of writing a specification, it’s always been part of software engineering, but it’s not usually something that gets talked about as much. Certainly at an undergraduate level there’s a lot more emphasis on programming language syntax and data structures and that kind of stuff which is, is really important and useful, but maybe a lot less so today than it used to be.
So the idea of how do we use these tools in an effective way, how do we use them while remaining accountable.
That’s the stuff that I want her to be picking up. Right. Is come out of this experience, being able to use the tools that are present to accomplish great things.
[00:45:34] Speaker A: Thanks, David. Dave?
[00:45:36] Speaker B: Yeah, I’d say something similar. I think it depends a bit how technically minded people are. I generally advise my students to go one or two directions if they want to get into the tech industry.
I feel like you could. I think there is always a place for the human element of design.
I think the hardest part with any new application is just coming up with the idea. That’s always been the hardest part and that will continue to be the hardest part. Hardest part.
So, you know, application design, the UX elements, just designing a beautiful application, this takes a lot of human input, a lot of human artistic value, so that sort of thing. And for people who are more technically minded, you know, really understanding the math, the back end, not so much the syntax or the coding, but understanding how these algorithms work is always going to be a useful skill. So, so focus on basic principles.
And then the other thing I tell my students is that you got to keep up that this stuff is changing so fast, whatever I tell you now isn’t going to be relevant three years from now. Except for those two aspects, the basic principles and the design elements. I think those will stick around.
But anything technological is going to change. And so there’s no substitute for just spending at least an hour a day just reading the news and trying to keep up.
[00:47:00] Speaker A: Thank you, Dave. You know, we’ve talked about the human element a lot here. We’ve talked about starting with the value and working backwards. I’m glad you brought up the math because it’s usually where I start from, is like, you know, you’re using tools, but you have little understanding of how they function inside. I mean, I don’t know the ins and outs of TCPIP or I don’t know how key punch cards used to work.
But I do understand, to David’s point, object oriented programming. I know what a good API looks like.
I know how to write a robust data pipeline that’s impervious to data issues that come up with it. And if you don’t know some of these things, it’s going to be really hard to write your technical expressions and evaluate what the results look like when AI is creating code for you. Joanne, your question or a comment?
[00:47:56] Speaker F: Well, both. I’m sorry, you know me better than that, Isaac.
First of all, My question is best advice for Q and A tools for Agentix.
It’s my question of the week to everyone I know who’s in the space.
We haven’t found a really, really good one yet.
[00:48:20] Speaker A: Who wants to take that?
[00:48:22] Speaker C: Sorry, did you say Q A Tools
[00:48:27] Speaker F: qa? Qa.
[00:48:28] Speaker C: Sorry, misheard. All right,
[00:48:33] Speaker G: for me.
[00:48:35] Speaker C: So I, I look at it again. It’s, it’s in some ways similar to what we’ve been doing, but now we can do it more efficiently, more effectively.
When I’m directing a team to build something, I want to see scripted tests, right? I want to see a lot of scripted tests because those are really useful for, you know, some people are into the test driven development approach, but whether you take that or not, it gives us a good set of regressions and regression testing.
So I like that. But it can often be tedious work. Work, right.
Any kind of system, computer system, they’re great for doing tedious work and AI systems are great at that.
So when I tell it, you know, here’s the thing, I want you to build and you know, here’s the test framework that we’ve established. And so I want you to add scripted tests that cover at least scenarios A, B and C.
And of course you can even say I want you to suggest other scenarios.
So I don’t see it as a different QA framework for scripted tests. I see it as we can get the AI to be a collaborative partner in building out that test suite.
[00:49:54] Speaker A: Joanne, every two or three months I put a testing article on my editorial calendar to try to get, get the platform companies perforce, Smart bear to come and talk to me about what they’re doing in the AI space and you know, unfortunately, Joanne, I think it’s still lagging.
[00:50:17] Speaker F: Well, that’s actually my point because everybody that I’ve spoken to, and it’s whether they’re CEOs, co founders, founders, whatever, we’re all technical people and none of us have, have found a really good way to do quality assurance.
What we do internally is we run everything through three or four different models and we see where the gaps are. And you know, there’s a lot of scripting and, and other things that we go through, but there are, this is definitely a gap in the market. And it goes to a certain extent to Derek’s point, because if you can’t do quality assurance in a really robust way because of drift or because of, you know, ambiguities that, that sort of rear their ugly heads and then you have to disambiguate etc. Etc.
You’re opening up a threat vector that nobody ever thought of before because it’s right there and you have no way to assure, truly assure, even from, you know, the battle days of sdlc, that the quality and the assurance before you move something as live or in production is actually there. Because every time, if you run it through Claude, if you run it through, you know, any of the other frontier models, or even through routines in Claude or Olama or anything else, there is not one good way to do this.
And so FYI to anybody listening startup, but basically the codes seem to drift in a way that nobody expects because things like weird bash commands come out at the bottom and nobody knows where they’re coming from or why they’re there. And if you try tracing things back, you get down a rabbit hole that will take you three days to get out of. The one thing that the comment that I would make is when things go wrong, particularly in an enterprise that does have, have mission critical systems that you are either interfacing with, pulling data from or writing back to, you don’t have the luxury that you might have in Vibe coding to the points made earlier. But there needs to be a whole group of people that sit down and figure this out because if not, a lot of agents are going to fail longer term.
[00:52:46] Speaker A: Yeah, Joanne, I’m, I’m right with you. I’ve heard experts that I’ve asked this question have responded to me with methodology. So using adversarial neural networks to basically compete and try to break things, using parameter testing to expand and synthetic data to expand the use cases that unit testing are doing. I have not seen this codified in an end to end methodology or in a tool or anything that’s plugged into some of the Vibe coding and co generating platforms. And it is a gap.
We’re going to talk about this one. I’m going to create another episode around it so I can bring some of the experts who could talk about that. So let’s hold that thought, Joanne. John, you’re going to get the last question and I want to hear from both Dave and David after that question. Yeah, the future of AI DevOps, but go ahead John.
[00:53:41] Speaker D: Well, so I, I know that like we all know that there’s, there’s code, a lot of the code is being written by a right AI right now.
And you know, we see it various ways.
I guess question to the Dave and David is I’d love to hear if we know of any public instances where we’ve had major global outages or if we’ve had major data breaches that can be attributed back to people maybe using AI carelessly or trusting it to write code too much. If we have any data points along those areas, this.
[00:54:20] Speaker A: Dave, you want to take that?
[00:54:21] Speaker B: Yeah, I don’t, I don’t know of any off the top of my head. It’s a great question.
You know, you probably heard the rumors of Manus doing the opposite, finding security issues, then sometimes very, very old code bases that have been around a long time. So I’m, I think I’m more optimistic than pessimistic on this particular front.
[00:54:41] Speaker A: Dave, any thought? David, any thoughts?
[00:54:44] Speaker C: I, I don’t have any examples, but I’ll say I think it’s a matter of time.
There’s certainly been plenty of examples where human error leads to a major security breach. Right. That’s unfortunately not uncommon. Right.
And given that processes are still varying, we’re still figuring out how to do this. Right. And practices vary all over the place.
I think sooner or later, yeah, there will be something significant about that and that’ll really drive home the importance of, of software engineering is not dead. Right. It’s changed.
[00:55:20] Speaker A: Thank you for that, Joe. One quick question I want to ask
[00:55:24] Speaker G: for all of our trailblazers that are listening today. Gentlemen, if, if you were a cio with a 10 million dollar discretionary budget and the board breathing down your neck about AI, what’s the one thing you would do and what’s the one thing you wouldn’t do?
[00:55:41] Speaker A: That’s a better version of my question of the future of AI DevOps. That’s how I was going to set it up, Joe. It’s like, what are you advising CIOs that are either going to bet the farm now and make some big changes, or they’re going to go do some things today and not do some things today.
Dave, I want to start with you. How do you think about that, answering Joe’s question?
[00:56:10] Speaker B: You know, I’m really in academia, so my, my ties to enter the enterprise world are not great. I don’t have a lot of advice.
Yeah, I’m gonna, I’m gonna just punt on this one.
[00:56:21] Speaker A: Oh boy. David, you got an answer.
[00:56:23] Speaker C: Oh, pressure’s on now, huh?
Okay, so yeah, I mentioned earlier in my intro that I have a very practical focus. Focus, Right. My goal is to take technology initiatives and use them to deliver business value.
So how, what does that mean in the AI world?
We’ve talked a bit about how software engineering practices can be adapted to work with AI. And I think that would be my main thing from a leadership perspective. We’re going to institute practices about how we ensure good quality systems, good, you know, secure, productive, all the kind of good things we want.
We’re going to make sure that everything is well aligned with, with our business goals.
One of the things I would not do is stop hiring juniors.
[00:57:17] Speaker A: Right?
[00:57:17] Speaker C: We, we still need juniors. We still need people who understand technology and they need to come from somewhere. Right.
So that’s going, that needs to be part of our ongoing thing as a technical society, let’s say.
So I definitely want to see that continue.
[00:57:35] Speaker G: Thank you for that,
[00:57:38] Speaker A: David. I loved your answer and I included some of my own areas here on the whiteboard. I want to go back, Dave, as we’re closing out, you wrote a post, I think it was just this week about but artificial general intelligence. And in a word, I would say you called it hype.
I’d love for you to elaborate that for the group here because what we heard today mostly is yes, we can use CO generators. We have to do a lot of work up front to make sure the requirements are right. We have to do a lot of work at the back end to make sure that this thing is testable and production ready. In fact, data is showing that it’s maybe saving 10% of our time. That looks like it’s more shifting. And, you know, we still have some of the big tech players saying that we’re spending our efforts and our money going after AGI. And you’re saying how we define AGI, it’s not achievable. So I’d love to leave that thought with everybody.
[00:58:43] Speaker B: Yeah, sure, I’d be happy to talk about that. And, and those of you who want to sign up to my substack the next this Tuesday, my next post is going to be about artificial superintelligence and some of the similar issues with achieving artificial superintelligence. But artificial general intelligence, it really depends whether or not it’s possible, really depends on how you define it. And you hear a lot of people with a really sloppy definition where they’ll say something like, AGI is the ability of artificial agents to achieve any human intellectual task.
They’re mostly thinking, if you can sit down to a computer and do it at a computer terminal. Terminal, then eventually AI, if we achieve AGI, then AI will be able to do it too. And I, I do take some issue with that, but not just. I only take issue at that broad of a definition.
So the post I wrote goes into some of the technical details of this where the way these models are given their intelligence is through a process of reinforcement learning. Reinforcement learning depends on being able to give the model a consistent reward.
And there are a lot of domains where there aren’t consistent rewards. So we’ll never achieve AGI when the rewards are inconsistent. So one of the examples I gave is fine art. If you ask an artist what is good art and what is bad art, every two artists will give you a different definition.
Even if you present them with a particular piece of art, some will agree it’s good and some will agree it’s bad. That’s a classic example of an inconsistent reward signal and will never achieve AGI in those sorts of domains, even if it’s digital art. So again, I mean that sort of art is something that could conceivably be done sitting at a computer terminal.
Coding is different and software engineering in general. So software engineering is complex, Complex. I don’t want to oversimplify things. So some aspects of software engineering, like passing unit tests and just having code that compiles that is very verifiable, that is very amenable to reinforcement learning. And we’ll absolutely see not just human level performance, but superhuman level performance. And that’s probably what’s responsible for these rumors of mythos.
But the more human centered design aspects of software engineering, that’s going to be a lot more questionable whether or not we’ll achieve AGI in those sorts of scenarios.
So it really depends what the thing to think about. The thing you have to focus on is are you talking about a domain where the reward signal is consistent? In other words, a domain where there’s some sense of professional, professional consensus on what makes good performance versus bad performance or not. And if there is such a consensus, then we can train AI to achieve that level of consensus. And if there isn’t, then there’s just no way we’re going to achieve that level of intelligence.
[01:01:44] Speaker A: And Dave, I think that’s just a good learning exercise for everybody here. It’s why self driving cars and detecting tumors and robo advising during non volatile markets. And yes, it looks like writing code has those signals.
And as we use these tools are just getting better, sometimes incrementally and sometimes stepwise functions. But to quote David, software development is not dead, it’s changed. And we’ve hit on a few examples today where maybe we’re doing a little bit less coding, but a lot more of our testing and of our requirements engineering.
And we’re going to have to have a whole nother discussion around security and one around testing. So great conversation today.
Dave and David, thank you for sharing that with me and sharing this with everybody. I’m going to paste the link in for the slide that I shared earlier today back into this common stream. You can get links to their blogs and to the research that I shared in that link. I just put it up there.
Do visit us next week. April 24th we’ll be talking about tomorrow’s workforce apprenticeship pathways for the AI driven organization. And on the first we’ll be talking about AI POCs that matter, selecting, pivoting and delivering value. I’ll be at Adobe next week. I’ll be at Appian the week after. If anybody listening is going to be at those events, do reach out to me. I’d love to meet up with you everybody. Have a great weekend. Dave and David, thank you for all your insights. Thanks to John, Heather, Derek, Joe.
Hopefully not leaving somebody else out there for your questions and your answer. Joanne, throw your questions and insights and we will be back here next week for more of the coffee with digital trailblazers. Everybody have a great weekend.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。