Sipho had been at Langkloof Financial Cooperative, a fictional regional financial-services cooperative, for seven months when he presented his first design to the design authority. The design was for the queued synchronisation that would replace the onboarding team's direct call into member records, the exception described in part 1 of this series. The document was good. It covered idempotent message handling, ordering, a dead-letter queue and replay. Every section was correct.
Then the head of risk asked what would happen if a field agent's tablet synchronised the same member twice, three days apart, with a different address each time. Sipho knew the document contained the word "idempotent". He could not explain what it would do in that case, because he had not worked it out. An assistant had.
Nobody at Langkloof thought Sipho had done anything wrong. He had used the tools the cooperative gave him, and the result was a correct design he could not defend. That is a capability problem the organisation created, and this article is about how to fix it.
Answers and learning are different products
When an architect asks an assistant a question, two different things can happen. The assistant can supply an answer, which solves today's problem. Or the architect can use the assistant to build a mental model, which solves the next ten problems, including the ones that arrive as a hard question in a meeting.
Both are legitimate. The trouble starts when an organisation needs the second and only rewards the first. In architecture, where the work increasingly consists of judgement, trade-offs and defending decisions (the shift described in part 1), an architect who can only relay answers becomes a bottleneck in the one part of the job AI does not do.
The same gap shows up in hiring and promotion. A portfolio of polished designs says little about whether the person behind it can reason through a case nobody prepared them for. Hire on evidence recommends interviews that test reasoning on live problems for this reason, and Experts govern explains why that judgement becomes more valuable, not less, as generation gets cheaper. An organisation that wants senior architects in five years has to grow them now, with the tools people actually use. Banning assistants does not do that, and neither does leaving people to use them however is fastest.
There is research on this, and it is worth reading carefully rather than in headlines.
- Retrieval strengthens memory. In a well-known experiment, Roediger and Karpicke (Psychological Science, 2006) found that students who practised recalling a passage remembered more of it two days and a week later than students who spent the time re-reading it, even though re-reading gave slightly better recall on a test five minutes after study. Retrieval feels less productive in the moment and pays off later. The general finding, often called the testing effect, has been studied extensively since.
- Unrestricted AI help can harm later performance. Bastani and colleagues (PNAS, 2025) ran a field experiment with nearly a thousand high-school mathematics students. Students given a standard chat interface did better during practice, but when access was removed they performed worse than students who never had it. A version of the tutor with prompts designed to protect learning largely removed the harm.
Neither study was about architects, and the second was about school mathematics in one setting. It would be wrong to claim they prove anything specific about professional learning. What they support is a design principle: the way an assistant is used determines whether it builds capability or replaces it. That principle is the basis for the pattern below.
The learning loop
CloudNala's pattern has five moves. None is new on its own; together they turn an assistant from an answer machine into a training partner. Each move limits what the assistant may do. Read from the bottom up, the five moves also form a learning ladder: rungs a learner climbs inside the loop, each with its own evidence, shown later in this article.
1. Map before you ask. Ask the assistant for a short learning roadmap for the topic, then cut it. For Sipho's topic, the map was: message delivery guarantees, idempotency, ordering, poison messages, replay and reconciliation. Cap the map at what can be learnt in two weeks, and name two or three primary sources to learn from, such as the integration platform's own documentation and one well-regarded book chapter. Limiting sources prevents the endless reading list that replaces learning with collecting, the same trap Stop collecting AI tutorials describes for engineers.
2. Answer before you ask. For each item on the map, write your own answer first, however rough, and only then ask the assistant to critique it. This is retrieval practice. It feels slower, which is the point.
3. Raise the difficulty. Ask the assistant to quiz you with progressively harder questions, and to stop giving hints once you get two in a row right. The first questions test recall ("what does at-least-once delivery mean?"). Later ones test application ("a tablet resends the same onboarding record after three days with a changed address; walk through what each component does").
4. Explain it back. Write a one-page explanation for someone outside the field, then ask the assistant to find the weakest sentence and question it. Explaining in plain words exposes the gaps that technical vocabulary hides. Ask the assistant to play a sceptical risk officer, not a supportive tutor.
5. Apply it to real work. Learning ends in a work product: a design decision, a test case, a runbook section. Sipho's final step was to write the replay test for the double-synchronisation case himself and walk the design authority through it.
Resource limits are part of the design
The loop works because it is bounded. Three limits matter.
Time. A learning ladder should take days or a couple of weeks, alongside real work. Open-ended study without a work product drifts.
Sources. The assistant should be used to question and explain material from named sources, not to be the source. Where a fact matters, the architect checks it against the primary documentation. This also guards against confident errors, which an assistant can produce in any domain.
Assistance level. Decide in advance when the assistant may give a full answer. At Langkloof, the rule is that during the ladder, the assistant gives hints and critiques, and full worked answers only after the learner has made two attempts. A simple instruction file in the team's assistant settings sets this mode, so nobody needs to remember it.
How Langkloof built it into the architecture practice
Langkloof did not create a training programme. It changed three things in the practice.
First, every architect has one learning ladder open at a time, chosen with their lead and tied to a decision they will have to defend in the next quarter. Sipho's next one is data retention for onboarding documents.
Second, design authority papers now include a short "questions I expect" section, written by the author before the meeting. The assistant may help generate likely questions. The author must answer them without it. This turns the meeting itself into retrieval practice, and it gave Sipho a reason to work through the hard cases before someone else asked them.
Third, evidence of learning is a work product, not a certificate. Learning paths by role, not by tool argues for the same thing at the level of a whole learning programme. At the level of an individual architect, the evidence is a decision they can defend, a test they wrote or a runbook section they own. The ladder below shows what the assistant may do at each move of the loop and what counts as evidence that the learner has climbed it.
Failure modes
Learning theatre. Quizzes completed and summaries generated, with no work product at the end. If the ladder does not change what the architect can do in their next design review, it was entertainment. Stop collecting AI tutorials makes the same point about engineers who finish tutorials without being able to explain the system they built.
Hint mode for everything. Not every question needs to be learnt. When an architect needs a syntax reminder or a configuration value, a straight answer is the right tool. Reserve the loop for knowledge the architect will have to defend or reuse.
Assistant as examiner of record. An assistant's judgement that someone "understands" a topic is not evidence. A person who knows the topic should see the work product.
Punishing honest gaps. If admitting "I relied on the assistant for that part" is penalised, people will stop admitting it, and the gap will appear at the worst moment. Langkloof's leads treat the admission as the start of a ladder.
A checklist for leads
- Does each architect have a current learning goal tied to a real decision?
- Do design papers include the questions the author expects, answered without assistance?
- Is the team's assistant configured with a hint-first learning mode that people can switch on?
- Are learning sources limited and named, with primary documentation checked for facts that matter?
- Does every ladder end in a work product that a knowledgeable person reviews?
Key points
- An answer solves today's problem; a mental model solves the next ten. Architecture increasingly needs the second.
- Research on retrieval practice, and a field experiment on AI tutoring, support designing assistant use around effort, hints and recall rather than finished answers, while not proving specific effects for professionals.
- Use a five-move loop: map, answer first, raise difficulty, explain back, apply to real work.
- Bound the loop by time, sources and the level of assistance allowed.
- Count work products a knowledgeable person has reviewed as evidence of learning, not quizzes completed.
This is the final part of Architecture Beyond the Artifact. For the role-level view of learning, read Learning paths by role, not by tool.
How CloudNala can help
CloudNala helps architecture and engineering teams build learning into their practice rather than bolting a course onto it. We set up hint-first assistant configurations, design learning ladders tied to real decisions, add "questions I expect" sections to your design papers, and help leads review the work products that show capability is growing, so that faster answers do not come at the cost of judgement.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an Architecture Practice Review or write to us at consult@cloudnala.co.za