Field Report

The gains are real. In field experiments at three large companies, developers with an AI assistant completed about 26% more pull requests a week, a measure of output rather than time.[1] In a randomised trial at Google, AI tools cut the time engineers spent on a well-defined task by an estimated 21%, though that estimate was not statistically conclusive.[2] It is not uniform. In an early-2025 trial, experienced developers working in their own large, mature codebases took 19% longer with AI, and believed afterwards that they had been about a fifth faster.[3] It may be the most human result in the literature, and the researchers think newer tools have probably changed it.[4]

Faster code is not faster delivery. Google's DORA surveys associate more AI adoption with lower delivery stability, even as throughput improves, and describe the tools as amplifying whatever discipline a team already has.[5] A 2026 study makes the gap concrete. Maintainers reviewed AI-written patches that had already passed a widely used benchmark's automated tests, and would not have merged about half of them.[6] A test can confirm that code works. Only someone who knows the project can say whether it fits.

Our reading is that the difficult work has not disappeared. More of it now sits in checking, choosing and fitting software to the place it has to live. That is an interpretation across several kinds of study, not a measured law, and we found no study that measures the cost of deciding what should be built.

Learning is an open question. In one experiment, developers who learnt an unfamiliar library with AI help understood it less well afterwards.[7] Asimov's "The Feeling of Power" (1958) imagines arithmetic surviving only inside machines until a technician relearns it from them.[A] It is satire, and here only an analogy.

So every MonoSpace project combines human judgement with AI-assisted work. People decide what is built and remain responsible for the result. AI assists with research, implementation and automated testing, which lets us inspect more states and edge cases than manual testing alone could, and people still judge how the product feels in use. None of this guarantees quality. It is our answer to where the work has moved.

The problem is the definition. Those surveys count a project as a success only if it meets its first estimates of time, cost and features, and they count only overruns. When researchers applied the same rules to more than five thousand real forecasts, an organisation whose forecasts were unbiased and unusually accurate scored 35% "success".[8] Being good at estimating earned a failing grade.

Surveys built around outcomes find something duller. In 2005 and 2007, between a quarter and a third of projects were cancelled or poorly delivered: lower than the folklore, and still high for an applied discipline.[9] Success also depends on who keeps score. In a survey of 617 South African projects, reported success reached 64% once business and strategic value were counted, against 34% in an earlier round that measured success more narrowly.[10] A project can miss its dates and still be worth having, or arrive on time and change nothing.

The most useful recent evidence is local. In its 2024–25 review of public-sector ICT, the Auditor-General evaluated 72 projects at 44 public bodies and reported findings on 41 of them, with a combined value of R12.1 billion, at 23 of those bodies.[11] The findings concern objectives for time, budget, quality or business outcomes that were not being met, which is not the same as every one of those projects having failed. The problems it listed read like a list the industry could have written decades ago: weak project management, scope changes nobody approved, missing business cases, plans misaligned with what the organisation was meant to achieve, and systems bought and never used. The R12.1 billion is the value of those projects, not a measured loss, although it reached the news as "R12 billion wasted".[12]

Technology still matters in the worst cases[13], but it rarely explains the ordinary disappointment. In 1987 Fred Brooks argued that the hardest part of building software is deciding precisely what to build.[14] We find it useful to describe most of what stays expensive as distance: between what was asked for and what was needed, between the people who pay for a system and the people who use it, and between launch and the years after. That is our way of organising the evidence, not a finding in it.

A systematic review of experiments on eliciting requirements (finding out what a system actually needs to do) found interviews, especially structured ones, among the most effective techniques, ahead of more elaborate methods.[15] The shortfall often runs the other way: a classic field study of large software projects found knowledge of the application domain thinly spread among the people building the systems.[16] Some needs only appear once a system is in use, a pattern engineers call IKIWISI: "I'll know it when I see it".[17] That is an argument for showing work early, not for doubting the client.

A second distance sits inside the first: the person who commissions a system is often not the person who will use it. In a 1995 study pairing more and less successful projects at 17 US companies, the more successful project had more links to its customers in 11 of 14 pairs. The authors called supervisors standing in for the real users possibly "the most common mistake in the custom environment".[18]

That paper was meant to be our evidence against go-betweens. It also rated a trusted support line, in close contact with the developers, the best link of all, and recommended that custom developers add one.[18] Locally, business analysts in banking describe requirements work as translation across languages, cultures and expectations about hierarchy.[19] A good intermediary can shorten the distance.

Involving users helps, though less than its reputation suggests: a review of 87 empirical studies found that most reported a positive relationship with the system's success, and the rest a negative or inconclusive one.[20] We found no study that compares direct and mediated communication head to head.

So the useful question is not how many roles stand between a client and a developer, but how far the builders are from the knowledge they need. We try to get as close as practical to the people who hold it. On an internal system, that usually means the organisation's own staff and processes. On a product with external users, feedback comes from them directly. On some small, well-defined projects, interviewing users isn't practical, and privacy-conscious evidence of how the product is used stands in.

Connectivity makes the point. In 2024, 82.1% of South African households had at least one member with internet access somewhere, but only 17.4% had fixed internet at home. The figure was 49% in Cape Town, 2.7% in rural households and 0.4% in rural KwaZulu-Natal.[21] A system for a Cape Town office and one for rural parents are different design problems in the same country.

Power has changed fastest. Load-shedding peaked in 2023 at an estimated 6,948 hours and largely subsided from March 2024[22], although just over a third of households still reported a power cut in the week before they were surveyed that year.[21] It returned briefly in 2025, between January and April.[23] Designing for outages is still sensible. Designing as if 2023 never ended is not.

Some old constraints have eased. Microsoft, Amazon and Google all run cloud regions in the country[24][25][26], and POPIA allows personal information to go abroad under defined conditions.[27] Hosting location is now a choice for more projects, though one that still carries compliance, cost and performance trade-offs. What hasn't gone is arithmetic: a subscription priced in dollars cost about two and a half times as many rand in 2023 as in 2010.[28]

Users close gaps like these every day, and improvisation is a real strength. But a system that only works because its users keep improvising has handed its distance to them.

Iteration was never the rebel position. Winston Royce's 1970 paper, usually blamed for "waterfall", called single-pass development "risky" and said it "invites failure".[29] Prototypes work, too: a review of case studies found that they increased participation and improved the fit between systems and needs.[30] The same review found the hidden cost. Where people had loose access to unfinished work, they read incompleteness as shoddy design, and in two cases that contributed to the project failing.

How feedback is gathered matters as much as how often. Novice designers who received critique after each prototype fixated on their first idea and did worse than those who made several before hearing anything.[31] A design shown alone collects kinder ratings than the same design shown among alternatives, and usability testing turned out to be good at finding problems and poor at producing fixes.[32] People know when something is wrong. Nobody should expect them to design the repair.

The South African evidence is sobering for anyone selling iteration. In the same local survey, agile projects were reported 42.6% over budget on average, against 10.2% under for waterfall, with no difference in business success.[10] Iteration also spends the client's time: the on-site customer role in extreme programming was found to be pressured and hard to sustain.[33]

None of this argues for getting it right first time, which almost nobody does. Pixar's co-founder has written that "early on, all of our movies suck".[B] That is a company's account of itself, so we take it as an attitude, not evidence. AI now makes convincing, high-fidelity prototypes cheap, which may make the expectation problem worse. That is our reasoning rather than a result.

So we iterate with structure. Show alternatives where a decision is being made. Say plainly what unfinished work is and isn't. Ask reviewers for problems and context, not fixes. Keep reviewers few and contact frequent. Count the client's time as part of the budget. And decide deliberately when to stop, because the evidence doesn't reward late change for its own sake.[34]

Showing people more can make things worse. In a series of pre-registered experiments with about 3,800 people, those shown how a model worked were sometimes less able to notice and correct its large mistakes on unusual cases, a gap that closed when those cases were flagged.[35] Explanations of an AI's recommendations made people more likely to accept them, whether or not they were right.[36] And hiding the implementation behind stable interfaces has been a founding idea of software design since 1972.[37]

Understanding still matters, at particular moments. In 1983 Lisanne Bainbridge set out the irony of automation: a designer who tries to remove the operator "still leaves the operator to do the tasks which the designer cannot think how to automate".[38] The more reliably a system runs, the less practised people are when it doesn't. In a small exploratory study of seven people, teaching them how a calculator worked made little difference on routine problems and a considerable one on novel ones.[39]

Games, which teach complicated systems to people who will never read a manual, show the same shape. In a study of more than 45,000 players, tutorials helped only in the most complex of three games, and in a simpler one an on-demand help button reduced players' progress by 12%.[40] Games are voluntary and business software usually isn't, so this is a pointer, not proof.

The principle we hold now is narrower. The people responsible for a system should be able to anticipate what it will do, recognise when it is failing, and know what it can't do. The implementation can stay hidden. Explanation belongs in the handover and in the unusual moment when something has gone wrong, not in a manual nobody opens.

We found no evidence that software has got worse across the board. The honest version of that worry is Christopher Alexander's. He told software engineers in 1996 that "better" could mean "merely technically efficient, not actually good".[43] That is a question about purpose, not a measurement.

Nor is custom software self-evidently an advantage. The best causal evidence we found favours renting, at least for young firms: cloud adoption raised revenue and employment for younger UK businesses.[44] Owned IT built organisation-specific capability over time, for firms that lasted long enough to collect it.[45] Security cuts both ways too. Microsoft's hosted Exchange was unaffected by the 2021 attacks on on-premises servers, and was itself breached two years later through what a US review board called "a cascade of security failures at Microsoft".[46][47]

Lock-in is real, and so far documented mostly for cloud infrastructure: fewer than 1% of UK customers switch provider each year.[48] From 12 January 2027, the EU Data Act prohibits switching charges for data-processing services within its scope.[49] The work of moving doesn't disappear. For South African buyers, a dollar-priced dependency also moves with the rand.

We should apply the same test to ourselves. A system that only its original developer understands has what engineers bluntly call a truck factor of one, and an exit cost of its own.[50]

So the question is not rent or build. It is what fits, what should be reused because it fits, what has to be built because nothing does, and what leaving would cost, asked before arriving.

What needs looking after isn't only the code a team wrote. In a study of more than 4,600 projects, 81.5% kept outdated dependencies.[55] When the Log4j flaw surfaced in 2021, the organisations that coped best were the ones that knew where they used it.[56]

Peter Naur argued in 1985 that a program is a theory held by the people who built it, and that reviving it from documentation alone is "strictly impossible".[57] The strong version doesn't survive: American federal agencies still run critical systems between 23 and 60 years old[58], and 41% of abandoned open-source projects were rescued by new maintainers.[59] The weaker version holds. Handover without overlap loses the reasons behind a design. E. M. Forster imagined where that ends. In "The Machine Stops" (1909), there "was not one who understood the monster as a whole", although its builders "had left full directions".[C]

So handover transfers the ownership of change: an overlap between the people leaving and the people arriving, access in the right hands, an inventory of what the system contains, a budget and a named owner. Because useful software keeps changing, ongoing funding has a structural justification. That is the case for a retainer and, awkwardly for our earlier prejudice, for a subscription too.

Depending on the project, we stay on for maintenance, retained support where a system must stay available, and adjustments as needs change.

Money is not the villain. Across many studies, financial incentives modestly improve performance[61], and in a large 2025 survey of South African developers, a better salary was the most common reason for leaving a job.[62] An argument that sets meaningful work against decent pay deserves to lose.

The better-supported concern is how work is organised. Observers saw workers as more like instruments when the work was repetitive, fragmented and paced by a machine.[63] Measurement is where that becomes practical: once a measure becomes a target, it stops being a good measure.[64] Researchers who study developer productivity argue that activity metrics should never be used on their own to reward or penalise individuals.[65] That is an argument for better measurement, not for none.

So "cogs" stays on this site as a metaphor, labelled as one: work arranged so that the person doing it matters less than the throughput.

The best language we found for the difference is David Pye's: a workmanship of risk, where quality depends on judgement exercised during the making, and a workmanship of certainty, where quality is settled before anything is made.[68] Pye didn't rank them, and neither do we. Nor do we claim that craft produces better software. Its own researchers call creativity in software development "under-studied", and studied closely, craftsmanship looks like disciplined engineering rather than artistry.[69][70]

What follows is practice, not proof. We get as close as practical to the people who hold the knowledge. People decide what is built and stay responsible for it, with AI as tooling. We show alternatives, frame unfinished work for what it is, and decide when to stop. We reuse what fits, build what doesn't, and keep supporting what we build. We also build tools meant to reduce friction between the people reviewing work and the people building it; nobody has evaluated tools of that kind, so we claim nothing for ours.

None of this is shown to produce better results. What we can do is report what we learn: anonymised lessons from real projects, with measured facts kept apart from observation. Expect "a recent project changed well beyond its brief, and this is what it taught us", never "our projects prove".