The real conversations in SA tech aren't buried in LinkedIn comment sections. They're happening face-to-face. On 30 September, we gathered over 30 engineering leaders at OfferZen's Cape Town office for our third Tech Leader Exchange this year.
Leaders from companies like Buffer, Shoprite, Lula, Super Group, and Entersekt shared what's really happening as their teams tackle AI in engineering.
We started with a simple framework for thinking about AI adoption, shared in a keynote by Barbara Fourie, OfferZen's Head of Product. From there, we broke into roundtable groups for peer-to-peer discussions. The focus stayed practical throughout: what's working, where teams are still hitting roadblocks, and what others are doing to move past them.
Here's the framework, along with the key takeaways from those conversations.
OfferZen's AI-enabled engineering framework
The framework maps out three levels of AI adoption: AI-assisted, AI-integrated and AI-autonomous.
Level 1: AI-assisted
At this level, you're still in the driver's seat for the full workflow. A good shorthand: one prompt in, one response out. You might get a task done faster, but nothing is set up to be repeatable or scalable.
Level 2: AI-integrated
Here's where you start to see real productivity gains. You're embedding AI into an existing process so that a scoped task gets completed in a consistent, repeatable way. You're still steering and reviewing, but you've handed the execution to AI in a structured way.
Level 3: AI-autonomous
Now the focus moves from single tasks to full multi-step processes. You're creating the conditions for agents to move through several stages of work independently: discovery, execution, and even self-correction. Your job is to frame the problem, set up the environment, and step in with your judgement when it matters.
Keep in mind
A team isn't simply at one level. Different kinds of work can sit at different levels depending on the risk involved, how clearly the work is defined, and how much context your AI agents have. And while we're talking about engineering here, the same framework can apply to product, design and data teams.
So, what's the real question at each level?
How much of the work are you handing over to AI? Is it a single small task, one step in a wider process, or the whole process?
Does every task need to reach level three?
Not at all. The goal is to be intentional about where different types of work belong, and to adjust as your team's confidence grows and your AI capabilities evolve.
5 key takeaways on AI-enabled engineering
Across four roundtable groups, these were the key insights that came through.
1. Risk appetite, not capability, is what keeps teams at level 2
Most teams operate at level 2 because level 3 means letting AI act without a human checking every step. Most companies aren't ready to accept that risk.
If you're in a regulated industry, the stakes are even higher. Security, authentication, compliance and financial data are all areas where you can't afford to let an agent make a call unchecked. So even when teams could technically move to level 3, they're choosing to keep a human in the loop.
Legacy systems add another layer. Older codebases can be harder for agents to operate in reliably, and several participants noted that teams working on greenfield projects moved through the levels noticeably faster.
Getting to level 3 also requires the right foundation first: the infrastructure, architecture and internal tooling that make autonomous workflows possible. It's a point Andrew Baker, CIO at Capitec, knows well. Designing the architecture from scratch was what enabled Capitec to adopt AI at the pace they did.
"There is a lot of regulation and concern, particularly because we do a lot of security and authentication stuff. We're not trusting AI to be completely autonomous. We are making sure that humans at least check everything, at least click the button. We want human accountability for what goes wrong." – Participant
2. The shift from coding to planning and orchestration
The balance between planning and coding is flipping. The idea of spending 4.5 hours planning for every 30 minutes of execution came up again and again. Now, PMs are diving into codebases themselves. Engineers? They're talking less about lines of code and more about managing agents, making decisions, and setting the right context.
This shift isn't about cutting back on code just for the sake of it. The real value now comes from the work that happens before anyone writes a single line: understanding the problem, setting the right constraints, and building solid context.
"I've been in a new job for three months, and I think I've opened the IDE about four times." – Participant
3. The SDLC needs to be rebuilt from scratch, not patched
Most of the tools and processes we use in engineering weren't designed because of technical needs. They're built around what humans can handle. Microservices? That's because no one can keep a whole system in their head. User stories? We need to break things down so the work feels manageable. Jira? It's there to track work at a human pace. Agents don't have these limits. They can reason across entire systems simultaneously, so a lot of these structures aren't just old – they actually get in the way.
"Microservices and user stories were designed around human comprehension limits, not technical necessity. We build microservices because humans can't comprehend the whole system. We've got to reimagine the whole thing." – Participant
Some teams are already making changes. Several have replaced Jira with lighter tools like GitHub Projects or just the CLI, tracking only what's relevant at agent speed. Others have switched to quick end-of-day check-ins, just calling out anything that unexpectedly blocked progress. A few have gone even further, reaching level 3: fully autonomous delivery pipelines where agents handle everything from implementation through QA, with humans reviewing the UI before it goes to staging.
"Jira was designed for human workflows. In a world where software is built in an hour, I need very different analytics. Which stage of my workflow costs the most money, which models we use, and what are the failure rates? Not Jira's complexity." – Participant
4. Junior developers are adapting faster than we think
The topic of junior developers sparked the liveliest debate of the night. Companies are holding onto senior engineers longer because AI tools significantly amplify their output. At the same time, hiring for junior roles has slowed down. Part of that is because AI subscriptions have shifted the cost-benefit calculation.
But there's a bigger issue: juniors can't write good prompts for problems they don't understand, and you can't fast-track real domain knowledge.
But not everyone agreed with the doom and gloom. Some argued that juniors, free from years of legacy thinking, might actually have an edge as we move into a world where agents do more of the heavy lifting.
"It's no longer about the quality of code; it's the problem-solving ability. They haven't had the years of coding experience we've had, so they'll find the easiest way to get the output right. He's (junior engineer) already created level 2 to 3 workflows where the agent is going to different APIs, running the workflow, getting output. There's an opportunity for them to bypass certain legacy historical thinking that we're actually stuck on." – Participant
The teams still running graduate programmes and giving juniors end-to-end ownership of problems rather than isolated tasks are the ones keeping the pipeline alive. At Coronation, Sameer Adams runs a rotation programme where graduates work alongside senior mentors, and he's found that the mentoring benefits flow both ways.
"I don't care if you can write code. I want to know if you can solve the problem." – Participant
5. Domain knowledge as the irreplaceable human layer
No matter how the conversation started, everyone circled back to the same idea. Sure, you can use agents to build things you don't fully understand. But good luck troubleshooting, spotting mistakes, or steering them towards the right outcome.
"You're no longer a 1x person; you can be a 1,000x person if you understand your domain." – Participant
The engineers who succeed here know their domain well enough to spot when something's off. Amplification is real, but it works best when there's expertise to amplify. Deep knowledge just got even more valuable.
"When you combine that domain expertise with the ability to build the thing, that's quite powerful." – Participant
Interested in joining an upcoming Tech Leader Exchange in Cape Town or Joburg? Join the waitlist, and we'll be in touch when the next one is coming your way.