When AI makes writing code faster, how do you decide whether your team is building the right thing?
In this episode of Tech Talks Daily, I speak with Johnny Halife, CTO at Southworks, about what happens to software engineering when code generation becomes easier but decisions still require experience. The pressure to deliver faster is familiar. The harder question is whether teams have the review capacity, testing processes, and deployment infrastructure to turn that extra output into useful software.
Johnny describes a different way of directing AI coding agents. Engineers need to specify the outcome, define what finished work should look like, and provide checks that can show whether it meets the required standard. Constantly telling an assistant what to do next can keep a person busy without giving the system enough responsibility to complete a coherent piece of work. We discuss how to create tasks that are small enough to review and substantial enough to delegate.
We also talk about context. Giving an AI system access to institutional knowledge sounds sensible, but adding every document to every conversation creates its own problems. Johnny describes borrowing from open source contribution practices, including README files, contribution guidelines, and records of architectural decisions. His approach combines an explanation of why the system works as it does with directions for finding additional information when needed. It is a useful way to think about onboarding an agent without expecting it to absorb the entire history of a business at once.
The phrase human in the loop comes up frequently in AI discussions, so I ask what it should mean in practice. Johnny describes checks before work begins and a review of test results and other evidence at the end, supported by progress updates along the way. The person responsible needs to set expectations and assess the outcome. Being available for an alert is only one part of that responsibility.
An unnamed streaming platform project provides a practical example. Johnny explains how Southworks developed the supporting process in stages, improving documentation, tests, and the infrastructure around the developer workflow. He reports a tenfold increase across requests, changes, and delivered value, although we do not have an independently verified measure or a detailed breakdown. His broader observation is that the same improvements made the environment easier for human engineers to understand and work in.
Finally, we discuss hiring and professional development. Johnny values software and cloud knowledge, curiosity, clear writing, time management, and the judgment to choose between competing possibilities. AI can make experimentation quicker, but someone still needs to decide which experiment deserves attention and when to stop.
I would love to hear how this compares with your own experience, so please share your thoughts. Where does work now wait in your engineering team, and how are you helping people make better decisions about what to build?
[00:00:00] - [Speaker 0]
Do you struggle to keep your AI agents from acting outside of compliance? Well, Denodo provides an AI data layer connecting your data systems, keeping guardrails consistent across all of your data platforms. So start scaling your business carefree with Denodo, and you can do that by visiting denodo.com to learn more. But now, on with today's show. If AI can write the code, who decides whether that work is worth doing?
[00:00:34] - [Speaker 0]
This is a question that keeps coming back whenever I hear another promise about faster software development. Generating something quickly, yep, that's useful. But somebody still has to explain the problem, review the result, and decide whether it belongs in production or not. And my guest today is the CTO of Southworks, and together, we're gonna talk about where engineering judgment fits into that process. We're gonna discuss the pressure on review and deployment, what useful context actually looks like, and why putting a human in the loop requires clear responsibilities, it's much more than a buzzword.
[00:01:13] - [Speaker 0]
And Johnny will also share lessons from a streaming platform project and the skills he looks for when hiring engineers now. So if your team has gained a fast coding assistant but also required an impressive review queue, hopefully, today's conversation will give you plenty to think about before the next sprint meeting begins. But enough for me. Let me introduce you to him now. So thanks for joining me on the show today.
[00:01:39] - [Speaker 0]
Can you tell everyone listening a little about who you are and what you do?
[00:01:43] - [Speaker 1]
My name is Johnny Jalippe, and I'm Salvador's CTO. We run a software development company. We've been doing it for, you know, twenty two years, which means that we have been around long enough.
[00:01:55] - [Speaker 0]
Yeah. You really have. And you've been doing AI before it was cool as well. Well, let's say that. And, of course, we're and we're now in this era where AI can produce code and complete defined tasks incredibly quickly.
[00:02:10] - [Speaker 0]
But, of course, it cannot always decide which work is worth doing. That seems to be the big stumbling block. But how does that change the role of the engineer? What are you seeing? As you said, you've been doing this for a long time now.
[00:02:22] - [Speaker 0]
What what changes are you seeing here?
[00:02:25] - [Speaker 1]
So I I will start from the top, which is, like, first and foremost, the biggest change is a change on expectations on our job. So everybody thinks like, hey. You're using AI. You should go faster. You should be doing, like, 10x.
[00:02:42] - [Speaker 1]
You should be like that 10x developer kind of thing, which is perfectly true, but you need to, you know, change a little bit the way you work. One of the things that that we have seen with all these AI trend is this idea of a copilot in which people kind of stand over the shoulder of the AI and say, like, hey. Do this. Do that. Now change this.
[00:03:07] - [Speaker 1]
Change that. In order to really, you know, maximize the benefit of using AI, you should be working on your... You know, this is what needs to happen, and this is what you need to build. And that planning and that idea of... I wouldn't call it communication because it's more like a spec, but you're talking to something that you need to be, like, really think it through.
[00:03:38] - [Speaker 1]
Yeah. And you have to have those skills to be precise and assume that you're talking with the most junior developer in the world that has the... This amazing capability for learning new stuff, like, really, really fast, but they know nothing about what you're doing, why you're doing it, and what success looks like. So the definition of success, how you really... And this idea of, like, you know, the definition of done, it's something that we need to be working on knowing that everybody is looking at us saying, like, hey.
[00:04:13] - [Speaker 1]
You know, AI has changed everything. So if you are still around, you need to be, like, 10 times faster and 10 times better. And as a joke on the Internet memes, make no mistakes.
[00:04:27] - [Speaker 0]
It's such a good point because speed just seems to be go, go, go, go. We have people that haven't developed before just saying, hey. I can vibe code this. So if code generation is becoming so abundant, I've got to ask, what are the other new bottlenecks appearing across decision making, review, testing, and deployment? Because the speed is picking up, but there are still issues there.
[00:04:49] - [Speaker 0]
Right?
[00:04:50] - [Speaker 1]
Yeah. Definitely. So I I would say... And and it kind of ties back to my previous point, the review. So you can generate a lot of code really fast.
[00:05:02] - [Speaker 1]
And if you think in these bite sized pieces of, like, you know, go do a, go do b now, go do c, you are not faster, and you will spend a lot of time reviewing code. So trying to figure out what's the right size or change that that you can review that it's, you know, self contained enough so you can go back and review it and you know what you're doing is number one. I think that, infrastructure is another point. So all these new code needs to lead, needs to go, needs to be verified, needs to be, you know, put somewhere where you can test it. So all the conversation around CI, CV, and continuous delivery and, you know, like, deploying live, those sort of things that were kind of, like, nice to have.
[00:05:57] - [Speaker 1]
Now they are a requirement for everything because this thing is working on its own, building things that we need to try out. And I would have to add that understanding what AI is good at and what it's not in terms of cost efficiency, it's another thing. It's another bottleneck. Because you can say, go build me an app, as you said. Right?
[00:06:21] - [Speaker 1]
Like, the bio coding thing. But it can become expensive really. Right? Like, that's that's the thing. So understanding which are the tools where you get the data and drawing the land in the sand saying like, hey.
[00:06:34] - [Speaker 1]
We have... We... We've been running these tools for checks and understanding if something is good and meets the rules and so on for so long, we don't need to reach them. We need to feed the AI the results of that to create this improvement loop, if you will. But, we need to work on the sidelines as a coach.
[00:06:56] - [Speaker 1]
Right?
[00:06:57] - [Speaker 0]
Yeah. I'm curious what you've seen at Southworks that actually shows the difference between one side of the coin where they use AI to just to produce more code for the sake of it and then almost technology searching for a problem to solve, and then the much more sensible of approach of starting with the business problem, the business outcome, and improving that. What are you seeing there that... With the the different approaches that you're seeing?
[00:07:24] - [Speaker 1]
So I I I would add, you know, to that whole thing. I think that AI is kind of a... When you use and apply the right way, it's kind of a driver for doing the right thing. So you start with build me an app or review my report or do whatever. Like, as everybody say, like, make no mistake, think hard, and do it fast.
[00:07:47] - [Speaker 1]
Right? Over time, you you you will realize that there are things that you could have automated in the past, and AI is really good to help you automate that, and then get itself out of the way. And that's an interesting thing that we have seen. Right? That people are like, no.
[00:08:07] - [Speaker 1]
We can review this and that with AI, and we can increase efficiency. And it's like... Yeah. The the success looks like when AI, it's out of the equation. Like, you can run the process, and AI does some sort of reasoning on on the results, the inputs, and stuff like that.
[00:08:25] - [Speaker 1]
So that really generates this idea of, hey. We have this problem. We fix it. We put AI to it to help us fix it. And how it works, like, as an adviser or supervisor of that process in a sense that it's out of the way.
[00:08:42] - [Speaker 1]
Like, you have the report. You have the numbers. You have the checks. Now you have somebody who can tell you what's wrong with it. And that's, like, crucial because I've been on many conversations with different CEOs and CTOs in which they say, like, we just throw AI.
[00:09:00] - [Speaker 1]
And it's like, sure. Like, is your problem worth a million dollars? And it's like, yeah. Probably not. So it's like, sure.
[00:09:10] - [Speaker 1]
So let's figure out. And it's like an enabler of things, and it doesn't get tired. So we have seen a lot of companies when they do these, you know, and checks and, you know, the the the things that are boring and tedious in which you go... Need to go through a lot of documentation, we see a lot of drift there. So you start with something.
[00:09:34] - [Speaker 1]
You say like, hey. I found this, this, and that. This is what we need to fix. These are the things that we are not using. These are the things that we need to kill.
[00:09:41] - [Speaker 1]
That works for the first month or the first three months. Six months down the road, nobody's looking at those numbers. But we... Yeah. It's kind of like, sure.
[00:09:50] - [Speaker 1]
We'll let it keep it running, and it will let you know if something drifts over time. So I think it's really interesting, but the most interesting idea is, like, using AI to help you do things and then work... Put it in this, you know, reasoning adviser role, not in the front and center of the thing because otherwise, it will get really expensive really fast.
[00:10:17] - [Speaker 0]
Yeah. It really will. And many companies, of course, will... I've been to so many tech conferences this year, and the one word that I keep hearing is context, the importance of context. And as a result, many companies are trying to give AI more context about their own systems and decisions there.
[00:10:34] - [Speaker 0]
So where does documentation help, and where does it fail to capture the judgment behind a past choice? What are you seeing here?
[00:10:42] - [Speaker 1]
I think that context... Like, everybody talks like, hey. We should write this down and write this down and the other thing, and we need to... Which is true. But when you are talking to a model, context is also constraint.
[00:10:56] - [Speaker 1]
It goes as the starting point, and it repeats on every conversation. So if you have, like, 500,000 tokens as context, then your model window for 1,000,000 is reduced to 50%. And as you start, you know, creating this session, you can run out of context. And we know that the longer the context it gets, the worse the model it... Worse the model performs.
[00:11:22] - [Speaker 1]
It's addressing. It confuses stuff. So I think that that the way we have been doing this for for, you know, software development and the engineering projects that go beyond software, but it could be infrastructure and such, is what I call it, like, standing on the shoulder of giants by mimicking what the open source has been doing for allowing contributions of people all over the world. So you have your decisions. You have your with me.
[00:11:53] - [Speaker 1]
You have your, you know, style guide, your contribution guidelines, and so on and so forth. Now you have your agents m b that it's specifically targeted to agents, but that's the same idea. And one of the things that that we have seen is these... Like, we'll tell you how to work. We'll tell you why what exists exists.
[00:12:18] - [Speaker 1]
Like, that that idea of, like, these are the decisions that led us to this point. And the other thing that we would do is, like, hey. If you need more information, this is how to get it. It doesn't necessarily mean go get it unless you need it. Right?
[00:12:34] - [Speaker 1]
Because that's the other thing. Like, you, like, shrink your user context to nothing if you put everything you know. So what we say is like, hey. You can go check the health on this API, or you can use this NCP server to check the live status, or you can do this to check the running versions. So that idea of, like, whatever the task, you have the tools, It's more about what led us to this moment and where can I find the information I need?
[00:13:06] - [Speaker 1]
We took a lot of inspiration in the open source world because they've been doing this for ages, like, before AI and before, you know, GitHub and all that. So we took the artifacts there, and then we write on the technology, like, MCP servers or APIs to say, like, hey. If you need it, go fetch it, but we don't need to give you a snapshot of everything that it's running, of everything that ever run and everything we ever thought. We we can share the decisions that led us to this point you understand the trade offs and you don't suggest something we have already, you know, discarded and here is the reason why. And then it's pointed to find the right information, like, whenever you need it.
[00:13:53] - [Speaker 1]
And that's one of the challenges that we've seen that when you try to do that, most organizations are like, well, we we don't know. Okay. We we can help you get there, but it's this idea of, like, enablement. Treating it as an onboarding of a new person that go work on your team that cannot learn twenty two years of history, like, from a company like ours in one conversation.
[00:14:25] - [Speaker 0]
And I must admit, from the moment I took context off my tech conference bingo card, it's usually followed by me crossing off the phrase human in the loop, which seems to be everywhere right now. And what should it mean in practice, though, if a person is expected to exercise real control rather than wait for an alert after something goes wrong? Because there's so many different stories around accountability, who's responsible, etcetera. But at tech conferences, it just keeps seem seem to keep saying human in the loop, and then would they move on? But what...
[00:14:56] - [Speaker 0]
What's your take on this?
[00:14:58] - [Speaker 1]
When people say human in the loop, I always rephrase it in my mind as human in the middle. Yeah. Like, in the middle of something, like, you know, more like a roadblock than an enabler. And I think that's that's what we need to change. Mhmm.
[00:15:17] - [Speaker 1]
This idea of the one shot, as I was saying, the over the shoulder, like, go do this, go do that. It's always this interactive thing. So the way we think about it as a human in the loop is, like, what do we need as as humans to supervise it? What's the definition of done? Which are the right gates for us to check?
[00:15:38] - [Speaker 1]
And then you can work so we can iterate and have these tools to say, like, hey. I tried this. It failed, so I fix it. Not I try this. Like, fix it for me, and I will continue.
[00:15:52] - [Speaker 1]
So that kind of changes where you are at. Our gates are usually on the gate. So before we talk the process, we make sure that we run a checklist of, like, hey. Which I... Which is the definition of done?
[00:16:10] - [Speaker 1]
Which are the tools that you will be running to make sure that it meets the quality standards? Do you have enough work to be cohesive work item? And then at the end. So... And that end is like, hey.
[00:16:29] - [Speaker 1]
This is what I've done. This is the result of your quality gauge. This is the result of the tools and the test that you asked me to grant. And that really puts us in the loop, but the most important thing is to... As professionals, as developers, and as humans to improve our skills to create these cohesive pieces of work with the right quality gates and the right definition of done.
[00:16:56] - [Speaker 1]
So it doesn't become like, go do this, then you wait, and it becomes like, okay. And it's like, you're just saying these strokes there. You're not delegating work. And and I think that is kind of one of the things that we need to learn, not in the sense of, like, I am forget, like, go do this and we'll we'll see what happens, But which are the things that we need to learn and which are the skills that we need to hone when we are relegating? What that other thing slash person needs from us in order to be successful.
[00:17:32] - [Speaker 1]
And that's kind of the key for all these human in the loop. It's like, as a manager, you stay in the loop of the work of your reports. Okay. What are the things that you are giving them to help them be successful? I think this is the same thing because I've seen a lot of times when when I talk to to friends and people that they are like, no.
[00:17:57] - [Speaker 1]
I I heard this person on my team. They are really good. So they keep asking me, like, what's next? And I'm like, yeah. You're probably not giving them the full picture.
[00:18:08] - [Speaker 1]
So this was the same day.
[00:18:11] - [Speaker 0]
And before you join me on the show today, I was reading how you, had worked with a streaming platform, and I'd love for you to share that story. And tell me a little bit more as well about what that taught you about applying the same principles across an engineering organization rather than just one single isolated workflow. What were your big takeaways from that? And and people have not seen it as well. Tell them about that story.
[00:18:35] - [Speaker 1]
This is this is great. So we work with a big screen company, and and we turn our our job of building a thing to build the thing that builds the thing. It sounds weird, but we build an engine that kind of we maintain and that's our job. We took it to a point in which we can do kind of a surface analysis and say, like, okay. This is self contained in app.
[00:19:01] - [Speaker 1]
It has a proper definition of of done, and it has the right quality gates, and the thing runs on its own. So over time, what happens is that most of our engineering work becomes building this distributed system that it's now the developer loop plus the infrastructure that supports it. And and that's something, like, really crucial because we were like, okay. Like, we don't need AI to figure it out. Like, do we have the tools?
[00:19:34] - [Speaker 1]
Do we have the telemetry? Do we have the test written? If not, what we would do? And it's a process of improving the whole thing. So at the end of the day, what we can see from this experience is it made it great in terms of AI and speed.
[00:19:51] - [Speaker 1]
Like, we went 10 x on the number of pull requests and changes and value that we then knew to the business. It makes it fantastic for agents to go do things, but it also made it better for humans because we got really good at writing documentation. We got really good at at synthesizing context. So if you get into a component or a piece of the thing and you say, like, okay. What's going on here?
[00:20:21] - [Speaker 1]
There is usually an explanation, a written or something that tells you what it is, and you can go do things, and it makes it lot better. So I think that that's kind of the upside. The results are fantastic, and and we have this nice dashboard with all the stages throughout the process in which we can see it's working. But, as, you know, on the morphe, philosophical side, it made us all better. So we have better documentation.
[00:20:51] - [Speaker 1]
We have better quality aids. We have better speed. And if we need to hop on and write something like the old way, which is basically open the text editor and change a file, you know exactly what you're changing because all the check... All the infrastructure and all the components are documented. But as I was saying, you need to crawl, walk, run.
[00:21:16] - [Speaker 1]
If you start from the, like, build me a system or fix this, it will be expensive and it will fail.
[00:21:24] - [Speaker 0]
Yeah. Unfortunately, so... And I always try and give everybody listening a a valuable takeaway. So now that judgment is becoming more valuable than just raw implementation speed, we're starting to do things properly again rather than moving fast and breaking things. Leaders listening, how should they change the way that they hire, assess, and and develop their engineers?
[00:21:46] - [Speaker 0]
Any big changes here?
[00:21:49] - [Speaker 1]
Yeah. But, yeah, I I I would think that at some point, I I think this became really heavy and during the pandemic, the market shifted into hiring super skilled specialist on one thing. Like, I need a React senior person, or I need somebody that knows Azure from the inside out, or I need a AWS Aurora expert, which is good because it gives you some experience. But, in this day and age, I think you need to have or or when we hire, what we look at is good fundamentals. You need to understand how the cloud works, how AI works, and you need to understand how software is written.
[00:22:35] - [Speaker 1]
You don't need to be an expert on every language or any language. Like, you need to understand what's going on. So good fundamentals becomes crucial. It's this thing... It's what separates a professional from a bald code or bilmian.
[00:22:52] - [Speaker 1]
Because when things go sideways or when you're writing that spec that we talk about, you need to know exactly, like, what you want, like, what's worth building and how. Thinkers and thinkers. That's basically... You don't need to be afraid of, like, moving fast and breaking things. It's...
[00:23:13] - [Speaker 1]
This is a great time to be alive if you are a thinker. Like, if you love, you know, trying what will happen if we change this, this is your time. It won't take a thousand years to go build it, or it won't take all your weekend or your nights or whatever. You can do it on its own, and you can see it. So curiosity, that, you know, hunger for longing and that, you know, thinking in need that it's kind of like, I need to try it.
[00:23:44] - [Speaker 1]
It's something really, really important. And the third one, I would say, and it has to do with the so called leadership skills. I I don't know if... I'll I'll put it that way, but it's a good way to summarize them that it's communication. You need to write effectively.
[00:24:06] - [Speaker 1]
Like, you need to be able to write effectively and say, like, what you want and why you want it. Time management, because one of the things that we've seen, and it has to do with judgment too, is these AI gives you these endless possibilities. So when you're not at it, you start like, hey. Not about... You know, we try to rewrite all these now into Go.
[00:24:34] - [Speaker 1]
And it's like, why not? The computer will do it. So you need to be super focused on, you know, the time management. Like, we need to get this done by deadline and make the right trade offs on your mind and be able to deal with all these possibilities that you have. And I I think that the third one is judgment.
[00:25:00] - [Speaker 1]
It's like, okay. What separates, again, a professional from mild coder, if there is such a term, is this idea of we are building a system. I remember I took a class when I was at school, and they said, like, programming languages, you mean that human able to communicate with the computer in a language they understand. Yeah. That...
[00:25:30] - [Speaker 1]
That's true. Well, we we reach the pinnacle of that that insight. We can use, like, natural language. We can use the language we use to talk to our friends. The problem is that we are not really good at syntax and semantics when we talk and language enforce some of them.
[00:25:48] - [Speaker 1]
But you need to understand what's going on, and you need to use the proper terms. That's why they're good fundamental. And I will combine all that into judgment. Right? Like, need the experience.
[00:25:59] - [Speaker 1]
You need the only the only title that keeps these leadership skills, these tinkering idea on the, you know, truth fundamental judgment. It's the experience gives you. It's what, you know, being there, doing that, so I know what's what. It's it's that. It's fun.
[00:26:18] - [Speaker 1]
I think that as developers, we are in the best time ever, the best time to be alive.
[00:26:27] - [Speaker 0]
Oh, you guys. An inspiring moment to finish on. But before I let you go, for anybody listening interested in working from you and especially, I I know you take clients from stock to scale one week at a time. So anybody listening wants to find out more about Southworks, how you might be able to help them, or just have a conversation with you about everything we talked about today. Where should they go?
[00:26:50] - [Speaker 1]
Southworks.com. Our website or socials are usually south works or my own profile that is Johnny Kalife on every major social network.
[00:27:01] - [Speaker 0]
Well, thank you so much for sharing your story today. I will put all those links in the show notes, and I will encourage people to keep that conversation going. I wanna stay in touch with you as well. It'd be great to get you back on in the New Year and see how things are continuing to evolve. We are only just a couple of months away from 2027.
[00:27:19] - [Speaker 0]
I never thought I'd say those words out loud, but I look forward to just keeping in touch with you. But just thank you for sharing your story again today. Really appreciate it.
[00:27:26] - [Speaker 1]
Thank you for having me. It's been a pleasure, and looking forward to doing it again.
[00:27:31] - [Speaker 0]
I love Johnny's emphasis on defining the work before asking AI to do it. Clear outcomes, sensible boundaries, and evidence from tests, these things give people something useful to review. Without these things, faster cogeneration can simply mean a longer queue of decisions that are waiting for somebody else. I also loved his point of that better documentation and delivery processes. These are the things that help human engineers alongside the agents using them.
[00:28:01] - [Speaker 0]
And for leaders, useful starting point might be to examine one workflow and ask where work actually waits. Is it in the writing, the reviewing, the testing, or deciding what happens next? Big thanks to Johnny for joining me. You can find everything in the links in the show notes. I'll post everything there, but I'd love to hear your experiences here.
[00:28:23] - [Speaker 0]
Please share your thoughts. Where has AI saved your team time, and where has it created another bottleneck in practice? Hopefully, we'll get a mixed bag there, but let me know as always tech talks network dot com. But that's it for today. Bye for now.