# Ensuring AI is Acting as Intended: A Q&A > Source: > Published: 2026-08-28 20:32:55+00:00 # Ensuring AI is Acting as Intended: A Q&A AI adoption in growing, and as it does, more organizations are starting to get a handle on controlling agents, making testing and security a first-class capability for AI-generated code, and using validation, policy and [governance](https://sdtimes.com/ai-agent-governance/) to ensure outcomes are what was required. SD Times recently sat down with Johnny Halife, the CTO at software engineering company [Southworks](https://www.southworks.com/), to discuss these issues. The following has been edited for length and clarity. **SD Times: ****Development teams are using AI to create code faster than ever before, but Ai can’t be relied on as of yet to make decisions around problem-solving. Why is this still something AI struggles with?** **Johnny Halife:** AI is very good at execution, but it has no stake in the outcome. Code generation is craft work. Its syntax, patterns, boilerplate, glue. There are millions of prior examples and a fairly clear notion of correct, which is exactly the shape of problem these models are built for. That’s why teams are shipping faster than they ever have. Deciding what to build is a different job. You have to determine which problem is worth solving this quarter, which trade-off you can still live with in 18 months when the team that made it has turned over, or whether the honest answer is to build nothing and delete the ticket. Ask a model to choose and it will hand you four defensible options with no preference among them, or it will infer a preference from how you phrased the question and reflect that back with more confidence than the evidence supports. Neither involves actual human judgment. So the bottleneck moved. It used to sit with implementation capacity. Now it sits with the ability to articulate what you actually want and to recognize the good version when it appears. Organizations that staffed for throughput and thinned out their senior judgment are about to find out how expensive that trade was. The teams getting real leverage treat AI as a fast, tireless instrument with a human holding the vision. **SDT: When developers create applications, they often have to make decisions about which problems to solve in the code, or to make tradeoffs in code to get something delivered more quickly. So, trust in AI remains suspect. What will it take for AI to get to that point where it can make some of those decisions?** JH: The question assumes this is a training problem, and that if you feed the model enough context, judgment follows. I don’t think that’s the bottleneck. Instead, you have to start with where those decisions actually come from. A developer pushes back on an abstraction because they watched one exactly like it rot at a company they left in 2019 in an industry they no longer work in. They can apply that experience in seconds. If you ask them to explain it, you get “I’d push back on this,” which is the compressed output of 20 years, with the 20 years removed. That compression is the problem. We synthesize, assume shared context and strip everything else because nobody has time to attach their biography to a code review. The record captures what happened, not why it happened. A Jira ticket holds the request. A PR holds the change. The deliberation happened on a call or in one person’s head over a weekend, and it left nothing behind. Then, there’s the question people skip: when the call is wrong, who owns it? Someone sits in the postmortem, carries it, and decides differently next time because of how it felt. Decision rights follow accountability. I don’t see us handing accountability to a model, and I’m not sure we should want to. So my honest answer is that I don’t know if we get there, and I’m not convinced the effort is worth its price. The judgment developers exercise is downstream of who they are. Everything they’ve shipped, everything that broke on them at 3am and every team they’ve watched come apart isn’t context you upload. **SDT: Organizations have bought into the notion of “human in the loop.” It seems to me that term is an understatement. Being ‘in the loop’ is understood to mean, ‘You don’t have to do much, but when something important comes up, we’ll let you know.” With all of the problems organizations have had to get AI to deliver desired outcomes, it would appear the humans need to be much more involved than simply being “in the loop.” How do you see the role of software developers continuing to evolve?** “In the loop” got interpreted as standby. The system runs, and you get pulled in when it flags something. But this reading is where organizations are getting into trouble. The version I’d argue for is smaller loops with explicit entry and exit criteria. A developer is the fixed point of a compass. Everything starts there, the radius is bounded, and the circle closes back at the same place. What’s changing isn’t whether humans participate. It’s that their participation moves to the edges, defining what goes in and what counts as done, instead of sitting in the middle. Rick Rubin has a passage in *The Creative Act* about this. He points out that many Warhol paintings were executed by other people and by machines, “while he supplied the ideas and retained authorship.” The same was true of the 1960s rock records where the band didn’t play, and of novelists who invent the world and hand the prose to someone else. Outsourcing execution never cost those artists ownership of the work, because the authorship was in the decisions. That’s the arrangement available to developers now, and it comes with a condition Rubin’s examples make obvious. Warhol was in the room. He set the constraints, saw the output and rejected what missed. He wasn’t on standby waiting to be paged. I’m genuinely optimistic about this, and I think it’s the biggest shift since the internet. If AI collapses the timeline on craft, the leverage moves to whoever can design and sketch the thing worth building. That’s a more demanding role than the one we have now, and it sounds nothing like standby. **SDT: Let’s talk about architecture for a moment. What can be done from that standpoint to ensure AI is acting as intended? Is it simply making better prompts? We’re also seeing that even with certain access and guardrails, AI still is going rogue more often, and more dangerously, as we’re seeing through recent unintended data exposure or deletions. Why are these defensive steps being taken not always working?** Better prompts help, but they’re the wrong layer to be relying on. My guiding principle is zero trust, with a clean line in the sand. How I want the AI to behave goes in the prompt. The things that must never happen go in IAM or somewhere else where they can be enforced deterministically. Think about how you already handle this with people. Every company has a handbook that sets expectations, defines values and describes lines nobody should cross. It’s a behavioral contract, and it works most of the time because people mostly follow it. No organization then concludes the handbook is sufficient and grants every employee admin access to every system. Would you let any developer on any team run a query against production on a Wednesday afternoon? For most companies the answer is no, and it’s enforced in the permission model. Prompts and system instructions are the handbook. They’re probabilistic, so they’re worth writing carefully and making unambiguous, but they’ll only be followed most of the time. Permissions are the enforcement layer, and they’re deterministic. If you genuinely don’t want something to happen, the answer is no access, not an instruction asking for restraint. I’d also push back on “going rogue.” That framing implies intent — some hidden agenda from a thinking thing. What happens is more mundane. The context ran too long to reason over coherently, or the request was ambiguous enough that a plausible reading was also the wrong one. In 22 years, I’ve worked with plenty of people who forgot the WHERE clause and wiped a table. Nobody called them rogue. The difference is volume. A person does it once and stops, usually with a sinking feeling. An agent does it across 12 repositories before anyone reads the log. The failure mode is old. The speed and the parallelism are new, and that’s what the architecture has to account for.