Four Takeaways from the SACAP Education Conference

Last week I sat on a panel at the SACAP Education Conference in Cape Town. Two days, around four hundred delegates, at UCT. The theme was "Architecture in Changing Times", and the room held a mix you don't often get in one place: council, government, international regulators, heads of department, practitioners, and students.

Before the takeaways, it's worth describing how the two days were built, because the shape of a programme decides a lot about what gets heard.

How the SACAP Education Confrence was put together

Day one was plenary. Everything happened in one room, in front of everyone, in a run of panels: architectural education for the future, architectural regulation in a global context, innovation in education and practice, urbanism and climate-responsive design, how curriculum translates into practice, a young professionals forum, and a closing reflection on the national building regulations. Between the panels sat the keynotes — government, two international regulators, and an international academic.

Day two changed mode. Keynotes in the morning, then four parallel breakaway sessions of peer-reviewed papers: education and pedagogy, sustainability, professional practice and technology, inclusive design. The day closed with a review of the papers and the adoption of conference outcomes.

Takeaway 1: AI was the default topic, and it crowded out the rest

Nobody in that room needed convincing that AI matters. The conversation had already moved past that, into something closer to a warning: if you're not doing AI, you won't survive.

I don't disagree that AI should be a default topic. Every conversation about the future of the profession should probably include it now. But being an AI-aware practice and being an AI-first company are not the same decision, and the gap between them is where most firms struggles.

What went largely unexplored was everything around AI. The broader digital domains — the capabilities a firm could be building, and the order in which it should build them — barely came up. Neither did the commercial half of it: how these technologies change what and how we practice architecture, or how technolgies changes our business. There was some conversation about the business of architecture, it didn't really go deep, and kept to the fees side. The more interesting question is whether new capability creates new forms of value, and therefore new services. Charging more for the same service is a negotiation. Creating a different service is a business model.

Part of why it stays shallow is that we talk about AI as if it was just one thing.

That is the conversation I'd want more of next year is what the business of architecture would look like in the future where technologies are changing us.

Takeaway 2: the best technology argument in the room wasn't labelled technology

One of the international keynotes presented work on bringing nature back into the city, specifically around flooding. The method was data-driven: analyse the catchment, generate and test options, implement. It was computational design doing real work, though it wasn't a technology talk.

The part that stayed with me was what they did with existing infrastructure. A concrete embankment had been channelling water for years. Rather than retrofit it, they demolished it, removed the retaining structure, and built a natural landscape in its place; solving a downstream problem by taking something out.

The existing wasn't wrong when it was built. It had reached the end of its useful life given what we now know.

I think that reads across to practice more directly than it first appears. The processes and workflows inside a firm are also infrastructure, also built with the information available at the time, and sometimes kept long past the point where new information should have changed them. Not everything should be demolished, and demolition takes longer than a single project. But retrofitting a workflow that was designed for a different set of constraints is a way of preserving the constraint.

Takeaway 3: the recognition ladder is linear, and capability isn't

The research I enjoyed most was on recognition of prior learning, reframed as recognition of experience learning — the argument being that experience, not only qualification, should carry a person across the professional categories. One of the international regulators described a similar mechanism on the CPD side: state what you learned, evidence it, justify it, and if it doesn't hold, revisit and resubmit. Both models share an ideal I like. Understand what a person actually knows and can do, and give them a route to close the gap.

What both share is also the limitation. The ladder in South Africa runs draughtsman, architectural technologist, senior architectural technologist, architect. It is linear. That structure works for people who are doing progressively more of the same work - I want to become an architect. It does not hold people doing different work.

Take a computational designer. She may be a professional senior architectural technologist on paper, but her work is programming and enabling other architects through it. She isn't designing the museum and isn't carrying the cultural and legal responsibility that comes with designing it. She is a capability the firm depends on, and the growth path has nothing that describes her.

One answer offered at the conference was a mapping exercise: do this work, meet these conditions, get classified there. Another ones was to fold emerging roles into the identification of works. I don't think either options solves the larger problem. Identification of works measures typologies — what kind of building, what scope of service. It doesn't measure digital capabilities, and it was never built to.

I'm not arguing that the identification-of-works categories are wrong, or that computational design should be written into the core theory of architecture. My position is narrower: as firms build capability around these technologies, there should be a separate, maybe a parallel way to recognise what those people do — alongside the professional ladder, not inside it. The alternative is an industry that stays black and white, architect or not, and stays smaller than it needs to be.

That is the conversation I want to take to SACAP.

Takeaway 4: education took blame and can't solve it alone

Universities were criticised, more than once, for not preparing students for the future of their roles. Some of that is fair. Most of it isn't, because it assumes a university can teach everything. A degree has a specific function: the language, the principles, the beginnings of creative and technical capability. The rest belongs to the individual, to the business, the mentors, and to the voluntary associations. There's real room for growth in the curriculum, but not in every area people wish it would appear.

Where I do think there's a gap — and it came up in every conversation I had with heads of department — is the middle. Curricula are being pulled between the traditional theory of architecture on one side and AI on the other, and the information between them is thin. Computational design, data-driven design, information management as a design technology. That layer isn't an alternative to AI. It is what AI gets used for. A computational designer still reaches for AI tools, but she reaches for them from inside a capability that lets her frame the problem first.

If a student's interest is form creation, we should be able to hand her computational design as a route, with the tools and the skills attached. Right now, in most places, the most common answer is that this path exists in practice and not in the curriculum.

What I'm taking forward

Two things, both started in conversations in the corridors rather than in the sessions.

• The first is the parallel-recognition argument — a capability-based validation track running alongside the professional categories. That's a conversation for the council.

• The second is a workshop for students on emerging roles: what the roles actually are, which technologies and workflows sit under each, and what a route into one looks like year by year. That's a conversation for the schools, and two of them are already open.

The conference was worth the two days. The thing I'd change is the balance. We spent a lot of time on the technology that is arriving, and less on the practice that has to absorb it.

One question to take back to your own practice

Every one of these takeaways reduces to the same question, and it isn't a question about AI.

Which capabilities does your practice actually hold, and which ones does the work you're winning require?

Not which software you own, and not which courses people have sat through — capability is skills applied to a problem, and a licence list won't tell you whether you have any.

I'm putting that question to a hundred South African practices this year, one conversation at a time, and mapping what comes back. No pitch attached to it. If you want yours mapped, or you want to argue with any of the four takeaways above, reply to this or get hold of me directly.