AI-Assisted Coding Isn’t for Juniors — It’s a Force Multiplier for Senior Engineers

11:55 · Watch on YouTube ↗

Transcript 2,219 words · about 15 min to read

Auto-generated captions from YouTube, not hand-corrected, so names and technical terms may be imperfect. The video is authoritative.

You got a good one there. >> Yeah. >> All right. Another AWS reinvent community session. I'm with Calvin who is the CTO of Six Feet Up, a application development firm outside of Indianapolis. >> Yep. >> Calvin, welcome. Uh, I don't think I've ever had you on video. >> Uh, no, we did do a video like about two years ago >> at reinvent probably. >> Well, reinvent or every time I get on a Zoom call with you, you're like, "Hold on, hold on.

I'm going to hit record. " So this is kind of planned, not planned, but at tech field day cloud specifically AI field day field day, >> you did a session on um uh AI assisted coding and it just was not enough time. >> I know we that I was asking all of these questions and I said we have to continue this. So this is the continuation of that conversation to an to an extent. First off, we're here here at reinvent, so we have to give some acknowledgement that Cairo exists.

>> Yeah. Can you break down to us what Cairo is compared to some of the other AI assisted coded co code assistants and why someone would use Cairo versus cursor versus some of the other ones you introduce and I'll link I'll link the the the tech field day talk underneath so we don't need some of that stuff. >> Yeah. So I think the the AWS agent coding solution the Cairo tool is meant more towards spectriven development. So help you develop specs, help you develop the the plan that's going to go execute and then break that plan up into small chunks.

I think I think that's a smart play. It comes down to like managing your context of what you're feeding these LLMs to try and get back reasonable code to, you know, commit into your application. There's a couple tools in the same category like this. Uh Devon is another similar one that basically spec driven development as opposed to like cursor or cloud code or um windurf and and some of the other ones. >> They are more generally type in what you want to do, build some code.

These ones try and direct you down that uh build some specifications first. So what I typically use Cyro for is expectally that that spec build, but I don't use it actually to build code. I then take that spec and give that spec to one of the other. >> I think that's smart because I I think each of these have their own kind of idiosyncrasies or specialties that they seem to be good at at the moment. And that's that's always a moving changing sea of of the agentic AI world.

But it's very quick. I find that a good usage pattern is not to try and dedicate yourself to just one of these agents, but like take one agent, get started with it. Maybe it's performing the way you want for that kind of a task. And as soon as it starts to feel like you're not getting the traction or the the advantages out of it, switch over to another one. Switch over into Goose, switch over into Codeex, Cursor, or I like Claude Code a lot.

Those are all really good ones because they've got different system prompts on the covers. They're working with different base models under the covers. I I like goose personally. I've talked about this quite a bit on the the previous podcast or the previous session I did because you can bring your own models too, right? You can use OAMA models. You can bring Mistral or Codeex or you know any open models like OSSGBT models and drive those in different ways and try and take the same context.

So manage your project in specs, manage the state of the project on the file system with like markdown files and allow other agents to like read those files in as new contact like fresh contact windows and see how far they can get with the their progress. >> So let's map this out a little bit. So you know this is not any different than when we're undergoing any software process. >> Oh no, that's the funny part. This is not new. This is actually what we should have been doing all the way along is writing good specs first.

And ironically at uh reinvent on the show floor they had the we can actually use that as the reference. They had a fourstep demonstration on the uh show floor. One was planning which we're talking about now. The next was design then code then deployment. And what I felt to be kind of clever was that they used a video game the arcade. Have you seen the the thing where you can uh plan an arcade game? You can design it. You then code it and then you deploy it.

It was using each one of AWS's premier products in each phase. So, uh Cairo, Nova, uh and uh and Bedrock, etc. to to do the development. And what I what I thought was clever and what I wanted to talk to you about is that you actually work with not necessarily junior developers, but a lot of senior developers. >> Yeah. All senior developers with you. I mean, unless we're engaging in a client where we're talking to them and helping their junior teams build up their skills.

And what I thought was interesting is that every time I read one of these reports about AI assisted coding, it talks about how good uh it is for junior developers but not so useful for senior developers. >> I'm I'm the exact opposite on that take, right? I I I I think that the senior developers it's interesting because senior developers have have learned this and done this you know many many more times than any junior developer just because of the sheer fact of the time in the chair doing the the work and experiencing all the various edge cases and and all the the journey that goes along with it and that's what I feel like gives them the advantage with these kind of tools is that you you can ask things of an LLM of the code step of that based on your knowledge of the world and if your worldview encompasses 30 years of of coding experience you've got more context to get exactly what you want out of that tool and do things that a junior developer doesn't even know is possible.

" But now I've got these agentic tools working in my my corner. I can send them on their way on some what could be an experiment uh on a on a a thought I had, you know, years ago, but never never pulled the trigger on. And this is why I like the demonstration on the show floor because for folks who are used to managing teams, building systems, this process is the development or systems engineering process. And as we think about where we inject AI, whether we're talking about code development, uh, uh, operations, etc.

we we intuitively know where to deploy the AI assisted uh systems at, but I don't think anybody sat down and actually codified this. >> Well, everyone's got their take on it. I think when when the tools first came out, they were all focused on this box alone. Yes. Like they didn't even have a plan mode or an architect mode. Some of the early tools did like ader chat had architect mode and then all the other ones followed suit eventually having like a plan mode of some kind and and some of the pitfalls is that the coding assistants are designed to solve the coding problem no matter what it took.

So what I saw was missing in the design phase of it is just basic hygiene such as and you talked about this a lot around rules but the coding assistant recreating uh uh libraries that already exist. >> Oh yeah. >> Like why would you go back and recreate spend all this time creating fragile code for a library I can just call? And I guess it's kind of there's two two pieces there. Like yeah, you don't want to like re re recreate the wheel.

Some of the issues have been that the coding agents have picked up old versions of libraries and they'll bring them in. So you're starting with tech, right? >> But there's also I think a school of thought where >> I can go from completely scratch, completely bespoke. I can lean in on the AI tools and have them build exactly the thing I need and I'm not bringing all the baggage along from those frameworks. Right? So I'm getting the exact experience I want.

there'll probably be better performance because you're not having a whole overhead of all that framework behind the scenes and and now you're obviously in charge of maintaining it. But I think I mentioned this yesterday another show that if I was a SAS player like a Salesforce, SAP, Service Now, I think these these folks should be a little worried about what's coming next because you can now build exactly the thing you want. The reason people bought those tools is because they didn't want to spend the money to build a bespoke version of the tool that did exactly what they wanted.

That's becoming a possibility. >> Yeah. Now the build versus buy conversation becomes what now if you have senior level engineers that really understand planning design and the bottleneck has always been just having someone to write the code to the previous spec and we've perfected deploy. I think >> the I don't know that's an interesting one that deploy box really. Well I think that's where a lot of juniors get tripped up. I agree that >> that's that's the biggest >> I agree that that's where a lot of juniors get uh tripped up.

But when you take a senior and you give a senior AI now you I can run infinite texts like the all the tests that I don't have time for. >> You you could because you you you've been a systems person like all on the infrastructure side of things and you same with me. I kind of came from that similar background and then layered code and applications on top of it. There's a a I think a great majority of the developers out there are they want to play in the code box.

They want nothing to do with that deploy box. >> Oh, that's where >> that's where we like >> Yeah, there it's not just what we like. It's where you solve problems before they become problems. >> So, Capital, we could talk about these four boxes all day. uh we'll we promise we'll get a longer session but I really wanted to uh follow up the conversation think about how do we codify how to use a code assistant especially when you have juniors and seniors you need to put them in the same room I think what I would really love to see is more content around how do juniors and seniors engage with one another >> I like that >> the the one of my theories is that juniors can now work as business analysts and prototype much faster and now take those prototypes to seniors to help develop.

That's a theory. >> I Well, I think higher education is going to have to adjust to this as well. I think that that junior developer is going to become more of a an apprentice or a a craftsman or a journeyman on a on an artisan type journey as opposed to go to school, get a CS degree, come out, get a you know entry- level jobs doing production level code. I don't think that path exists in this world. I I I tend to agree.

PWC has uh has made a big deal out of their from their you know audit and tax track of no longer hiring juniors to just come in and do and collect data. AI can do that and tools can do that. How do they manage AI systems? com and I'm everywhere as CTO advisor talk to you next CTO advisor community chat All