AI now drafts code inside the tools developers use every day. Nearly half of it carries a known security flaw. In a market short 118 000 digital workers, somebody still has to read it.
The integrated development environment (IDE) was, for 30 years, a productivity detail that never reached an exco agenda. It reaches one now.
AI inside the IDE changes who can build, how fast code reaches production and what arrives in production alongside it. For South African enterprises carrying a structural skills deficit, the opportunity and the exposure are the same event.
An IDE is best understood as a workshop. Every tool a developer needs sits within reach on one bench: an editor for writing code, a build system for turning it into a running program, a debugger for working out why it is not running, version control for keeping a history of every change, and analysis tools that flag problems while the work is still in progress.
None of this is new, and none of it is glamorous. The workshop has looked broadly the same since the late 1990s.
The models are getting better at writing code that runs. They are not getting better at writing code that is safe to run.
What changed is that the workshop now has an apprentice in it. AI tooling built into the modern IDE no longer operates line by line or file by file. It reads across the whole code base, infers the conventions a team already uses, and drafts implementations from a plain-language description of intended behaviour.
A developer types "send a welcome e-mail when a new customer signs up" and receives a first draft that follows the existing patterns of the system. That is a different category of tool from autocomplete, and it deserves a different category of governance.
Why this lands differently in SA
Globally, the AI IDE is a productivity story. Locally, it lands on top of a structural one. The Collective X research puts 118 000 digital roles unfilled nationally, a vacancy rate of roughly 37%, with software developers the single largest category.
Xpatweb’s critical skills work found 92% of employers struggling to recruit critically-skilled professionals in 2025, up from 79% a year earlier.
The World Bank, in its 2026 assessment of the country’s digital skills pipeline, described the gap as a structural misalignment between what employers need and what the education system produces, with software development named first among the shortages. All of this sits against an official unemployment rate of 33.6%.
That combination is unusual and it matters. Most markets adopting AI development tooling are optimising teams they already have. South Africa is attempting to staff teams it cannot fill.
The continent-level picture reinforces the point: BCG counted 4.7 million developers in Africa by 2024, small in absolute terms but growing at 21% a year, the fastest of any continent, with roughly 660 000 GitHub developers in South Africa and 1.1 million in Nigeria. The talent base is young, expanding and disproportionately junior. AI tooling is at its most persuasive and its most dangerous in exactly that profile of team.
The productivity claim and the delivery reality
The headline numbers are real. Controlled research on GitHub Copilot recorded developers completing tasks in about one hour 11 minutes, versus two hours 41 minutes unassisted, a 55% improvement, with enterprise teams merging pull requests materially faster. Adoption has followed: Stack Overflow’s 2025 survey of more than 49 000 developers found 84% using or planning to use AI coding tools.
The organisational numbers tell a less comfortable story. The same survey found trust in the output falling, not rising, with only 29% expressing confidence in what the tools produce, down from 40% in 2024.
DORA’s research is blunter: for every 25% increase in AI adoption, delivery throughput fell around 1.5% and code stability fell around 7.2%. Individual speed and organisational delivery are moving in opposite directions, and the gap is absorbed by teams that were already short-staffed.
The security debt nobody budgeted for
Veracode’s longitudinal testing across more than 150 models found that only 55% of code generation tasks produce secure code; in 45% of cases a known security flaw is introduced, a figure that has barely moved in two years even as syntax correctness passed 95%.
Independent analysis of pull requests mixing AI and human code found AI-authored changes carrying roughly 1.7 times more major issues and 2.74 times the rate of security vulnerabilities. The Cloud Security Alliance reports AI-assisted commits exposing secrets at more than twice the rate of human-only commits, 3.2% against 1.5%.
For a South African financial services or telecommunications business, that is not an engineering quality concern. It is a POPIA concern, a Prudential Authority concern, and a board reporting concern. Code that works but leaks is still a breach.
The regulator does not distinguish between a vulnerability a junior developer wrote and one a model drafted while a junior developer approved it in nine seconds.
The models are getting better at writing code that runs. They are not getting better at writing code that is safe to run. The distance between those two things is where enterprise risk now lives.
Local workshop or cloud workshop
IDEs split broadly into those that run on a developer’s own machine, such as Visual Studio, IntelliJ IDEA or PyCharm, and those that run in a browser on hosted infrastructure.
The cloud option solves real local problems: standardised environments, compute-heavy builds handled remotely, and a machine specification that no longer depends on what a developer could afford.
It creates two others that are distinctly South African. The first is data residency, because a browser-based environment means proprietary source code and, depending on configuration, production-shaped data crossing a border.
The second is billing, because seats and inference are priced in dollars against revenue earned in rands, on top of connectivity that is neither uniformly fast nor uniformly cheap outside the metros. The sensible posture for most local enterprises is hybrid rather than absolute: hosted environments for standardisation and scale, local environments and locally hosted models for the repositories where residency or cost sensitivity is genuinely material.
The junior developer question
One finding deserves more attention than it gets. Less experienced developers accept AI suggestions at roughly 31.9% against 26.2% for senior engineers, and junior developers are about twice as likely as seniors to adopt the tools in the first place.
The people least equipped to evaluate a suggestion are the people most likely to accept it. In a market where the pipeline problem is the whole problem, this cuts both ways.
Handled well, AI tooling compresses the time a capable graduate needs to become genuinely productive on a real code base. Handled badly, it removes the exact tasks through which juniors historically became seniors, and produces a cohort that can ship code it cannot debug.
South Africa cannot afford the second outcome. The country is not short of people who can prompt a model. It is short of engineers who can tell when the model is wrong.
Five actions for South African technology leaders
Govern AI-assisted code as a distinct class of change. Mandatory human review, secret scanning on every commit, and dependency analysis are not optional overhead once nearly half of generated code carries a known flaw. Make the review requirement explicit in the SDLC rather than assuming existing practice covers it.
Measure delivery outcomes, not developer sentiment. Perceived productivity and actual delivery have been shown to diverge. Track change failure rate, lead time and stability before and after rollout, so the adoption case rests on organisational evidence rather than enthusiasm from the teams using the tools.
Decide the residency question before the tooling decision. Establish which repositories may run in a hosted environment and which may not, on POPIA and contractual grounds, and let that classification drive IDE selection. Retrofitting a residency position onto an already-adopted cloud workshop is considerably harder.
Budget tooling in rands against a dollar cost base. Per-seat licensing plus inference consumption is a dollar-denominated operating cost that scales with usage, not headcount. It belongs in the same forecasting discipline as any other material currency exposure, not folded into a flat annual IT line.
Protect the apprenticeship, deliberately. Pair AI-assisted work with structured review by senior engineers, and keep a defined share of foundational work manual for developers in their first two years. The tooling should shorten the path to competence, not remove the path entirely.
My question for every South African technology leader reading this: if a junior developer on your team shipped a piece of AI-generated code tomorrow that quietly hardcoded a credential, how long before anyone knew, and would the answer be a scanning tool, a review process, or a customer notification under POPIA?
The workshop already has the apprentice in it. What remains a choice is whether anyone is supervising.
* Eugene Perumal is a strategy and architecture principal with over 20 years' experience in enterprise technology across telecoms and financial services, including senior roles at Vodacom Group and Absa Group. He is currently a global practice leader in the field of AI software factories and AI engineering. He holds Master’s degrees and certifications in enterprise architecture, AI governance, cloud and analytics. He writes on enterprise AI strategy, ROI measurement and the shift to agentic AI deployment.
Share
