Inverted Professional Practice

Overview

The conventional Professional Practice module is an exercise in transmission. The profession holds the knowledge. The module conveys it. Students are taught how offices are structured, how work is procured, and how a career is assembled. Practitioners are invited in to describe their world, and students listen.

That model holds for most forms of professional knowledge. It does not hold for emerging technology.

Artificial intelligence entered architectural practice faster than practice could absorb it. Many regional firms recognised the opportunity. Few had the time, the staffing, or the confidence to investigate it. For this one body of knowledge, the gap did not run from the profession to the student. It ran in the opposite direction.

The module was redesigned around that inversion. Students were trained first in subject-specific AI methods. They then worked with regional practices, not to be taught, but to teach. Each team joined a host practice to identify a real operational problem, and then developed an AI-based response to it.

The cohort of 45 students was drawn from three programmes: Architecture, Architectural Technology, and Construction Management. Teams were mixed by design. A practice does not consist of architects alone, and the problems a practice reports are rarely confined to a single discipline.

The pedagogic ambition was larger than the technology. A student who must diagnose a client's problem, agree a scope, build a solution, and hand it over has encountered the full condition of professional work. Not a description of that condition, delivered in a lecture theatre, but the condition itself.

The Inversion

Three conditions made the inversion viable:

• Timing. Generative AI was novel to everyone. Neither party held settled expertise. A student with one semester of concentrated training could plausibly hold more applied knowledge than a practitioner with twenty years of architectural experience. That asymmetry was temporary, and it was the resource the module exploited.
• Appetite. Regional practices were curious rather than resistant. Many had already encountered AI in fragments, through a plug-in or a headline. What they lacked was a structured means of testing it against their own workflows, at no commercial risk.
• Preparation. The inversion only functions if the students genuinely know something. Work with a practice could not be the site of first contact with the technology. Training had to be completed and consolidated beforehand.

That sequence was therefore non-negotiable: learn the technology first, then apply it in a setting where the consequences are real.

Pedagogic Structure

The module runs in four progressive stages. Each stage depends strictly on the one before it:

Stage 1: Technical Formation

Students were trained in AI methods selected specifically for architectural relevance. Large language models were addressed as reasoning and drafting instruments. AI agents were addressed as tools capable of acting within software rather than merely producing text. Generative image workflows were addressed as a means of controlled visual iteration, with attention to their limits as well as their capabilities.

The framing throughout was subject-specific. Students were not taught prompt technique in the abstract. They were taught what these systems can and cannot do within an architectural process.

Stage 2: Matching

A structured workshop brought practices and students together at the University (Fig 1). This was not a networking event; it was a rigorous matching exercise.

Practices described their operational pressures. Students described their capabilities and interests. Teams of three to four were then formed against that mapping, so that each collaboration began with a plausible fit between a stated need and a demonstrated skill.

Teams were also composed across the three programmes. An architecture student, an architectural technology student, and a construction management student read the same practice differently. That difference was treated as an asset rather than a complication. Each team therefore had to reach a shared account of the problem before it could act.

The workshop performed a further function: it required students to communicate technical possibility to a non-specialist audience, in professional company, before any work had begun.

Stage 3: Diagnosis in Practice

Teams then worked with their host practices, embedded in the offices of those practices (Fig 2, 3). The first task was not development; it was diagnosis.

Students had to establish what the practice actually did each day, where time was lost, and which of those losses were tractable. This required listening rather than proposing. It also required the discipline to reject their own preferred solution when it did not match the problem in front of them.

Practices are not uniform. A small residential studio and a mid-sized commercial firm do not share bottlenecks. Each team therefore arrived at a different brief, written jointly with its host.

The mixed composition of the teams proved valuable at this stage. Design bottlenecks, technical documentation bottlenecks, and programme or cost bottlenecks are not visible to the same observer. A team that could see all three produced a more accurate diagnosis than any single discipline would have reached alone.

Stage 4: Development and Handover

Teams then built. Solutions ranged from workflow protocols to bespoke tool development.

The most technically ambitious was developed by Piotr W., working with input from his host practice throughout. It is an integration connecting an AI assistant directly to Autodesk Revit through the Model Context Protocol (Fig 4, 5). The tool allows an architect to interrogate and operate on a live BIM model in natural language. It can retrieve a specified view, summarise model contents, and report on levels, rooms, and areas without the user leaving the software.

The significance of that work is worth stating plainly: it does not add AI alongside the architect's software. It places agentic AI inside the environment in which architects already spend their working days.

The practice specified the functionality it needed and tested each iteration. The tool remains in active use there today.

Each team concluded with a structured handover. Practitioners were trained in the workflow their team had developed, ensuring the capability remained in the practice once the module had ended.

Learning Theory in Practice

The module was designed against three positions in learning theory. Each is visible in a different stage of the structure:

• Experiential learning. Kolb's cycle requires concrete experience, reflective observation, abstract conceptualisation, and active experimentation. The module runs that cycle at full scale. Students experience a working practice, reflect on where its difficulties lie, conceptualise a technical response, and then test that response in use. The cycle is completed in a real setting, with a real client, against a real deadline.
• Constructivism. Knowledge here is built rather than transmitted. This is the precise inversion of what a Professional Practice module usually does. No two teams received the same problem, because no two practices had the same problem. Students constructed their understanding of professional practice by encountering a specific instance of it and reasoning outward. The social dimension matters equally: meaning was negotiated within mixed teams of architects, technologists, and construction managers, and then again with practitioners who held very different assumptions about what the technology could do.
• Connectivism. Siemens' proposition is that in fast-moving fields, the capacity to form and navigate networks matters more than the retention of any particular content. The specific tools students learned will date; the ability to acquire an emerging technology quickly, judge its applicability, and connect it to a professional need will not. Students also left the module holding a professional network.

The four stages therefore correspond to a deliberate progression: learn the technology, learn to work across disciplinary difference, learn to diagnose a real need, and learn to build against it.

Outcome & Impact

Forty-five students and fifteen regional practices took part. At a follow-up conducted six months after the module concluded, 75% of those practices were using at least one AI workflow developed with their student team.

That figure carries weight because adoption is a demanding measure. It is not satisfaction with the experience, and it is not an expression of intent. It records a practice changing how it works, on the strength of student-led development.

The six-month interval matters as much as the percentage. Novelty produces short-lived enthusiasm. A workflow still in use half a year later has survived the return to ordinary working pressure.

Three further effects are worth recording:

• Students shifted from executor to problem-solver. The module offers no brief to follow. Students must find the problem before they can address it, and the problem is not theirs. This is the condition of professional work, and it is rarely reproduced in studio.
• Practices gained capability they retained. Because handover was built into the assessment, the knowledge did not leave with the students. It stayed in the office.
• The University's regional standing was strengthened. Fifteen practices encountered our students not as applicants seeking experience, but as contributors bringing something the practice did not have.