From Prompt to Process

Many Architects and Planners now use chatbots and image generators in their daily work. But integrating them consistently within a design project remains surprisingly sporadic. Why?

If you like simple answers, try this:

To generate tangible contributions, you need to provide accurate project context which, in a design project, is changing on a day-to-day basis. In consequence: The human designer needs to constantly hold the chatbots hand - reasonably laborious and no easy feat.

Or this:

Generative AI is showing awesome productiveness when you can define precise target coordinates. The objective of design work however is largely concerned with defining such target coordinates, so architects are effectively focussed on an effort that precedes the practical use of AI.

For the past three years I am helping architects to find a way into applying AI in their work environment. This text is my first attempt to extend my map of this new technology by a look underneath at our current work methodology and how we might achieve a better fit between the new capabilities of AI and the craft of planning.

AI as a personal Skill

That AI as a new form of software is not the problem and that we already possess the necessary competences in principle, I set out in an earlier article which was based on Nate B Jones findings at the time.

I am viewing the application of AI as a skill one needs to acquire. Being confidently able to exercise this skill is the entrance-gate to exploring alternative methods of executing planning work. I summarised my recommendations in acquiring that skill in Chapters 1 to 3 further down in this text.

AI for Knowledge Management

As stated above, adequate context information is essential when looking to employ AI consistently within a project’s planning process.

Exploring the means of assembling and providing these contexts will quickly lead you into technical realms that are beyond the scope of a common, browser-based chatbot license.

In contrast to outlining current techniques of AI enhanced knowledge management however, I have focussed this text on the specifics of our current design information and why I believe these are of limited use for AI systems. In Chapters 4, 5 and 6 I am outlining my current take on some characteristics of the data-quality that is common in design projects.

A New Working Methodology

Having developed some confidence in applying AI as a natural assistant in your daily work; having obtained some deeper insights in the functionality of AI-Agents and Knowledge-Management-Systems; and having created a string of tangible AI outputs, I feel we are left with a potentially uncomfortable question:

How far are we prepared to adopt our current working methodology to safely tap into the full potential of AI as a new digital technology.

The tool is the same for everyone. What differs is the methodology each of us builds around it: which tasks do we hand over, in what order, with what context, and how we check what comes back. That methodology is not supplied with the subscription. It is something each of us assembles, mostly without noticing that we are doing it.

I should be clear about the limits of what follows: The working methods indicated in this text are my own. They have grown out of daily practice over three years and they work for me. They are not products, and I have no evidence yet that they transfer unchanged to another office. How an individual working method becomes a shared convention is, to my mind, one of the open questions of this whole undertaking.

To enter and navigate a new Terrain

Without a clear and proven answer to this question, AI integration feels like a hike though a vast and wondrous mountain range. Whilst one generation leaves you utterly speechless, the next output is childish nonsense. In addition, every few weeks a new advancement is being published that makes a further room of new possibilities suddenly accessible.

The technology and its development are by now well documented. There are countless tools, start-ups, educators and influencers creating an overwhelming stream of information. All have one core message in common: Your work profile remains – all you need to do is to equip yourself with Artificial Intelligence.

A recent seminar in Weimar led me to take the opposite perspective. To look at the human side and not the tool. To ask why we design the way we do and where the tool and our objective fail to align.

The following chapters are intended to help you finding a way into applying AI in your daily work as an architect but also outlining the questions and challenges you will face, once you have reached the first or second tier in your journey of adopting this new technology.

Let’s start at the beginning, so we trace our steps later:

Expect the range to be wider than you’d expect

The very first prompt of that Weimar session illustrated how far apart the capabilities AI systems are by now. We asked several language models to produce a schedule of accommodation for a fictional school project. The results ranged from a mediocre bullet list to a fully worked out table — not because of a better prompt, just the difference of engagement that each system applies to the given task.

Various unlicensed, free-to-use AI models are proving particularly bland for anything of modest complexity. Evidently, the period of free introduction offers is over. In contrast to not long ago, I have lost the imagination to say which useful tasks freebie-AI might be good for. To my mind, anyone who makes their first attempts exclusively with such limited systems is risking wrong conclusions and potentially a false course into the land of AI.

Then there is the character of the models. How different the various systems perform in dialogue is something everyone should establish for themselves. The better the exchange of thought, the more your chatbot becomes a productive counterpart. I currently work with three primary and three secondary language models in rotation, depending on what I want to achieve. An important finding: expensive is not necessarily better.

Why most of us fail to know when to prompt

Having obtained an initial feel for the new digital tool another observation followed: Most of the participants in Weimar were lacking the instinct to determine when a task is suitable for AI processing.

Every day we encounter countless situations in which information has to be found, compared, structured, assessed or reformulated. A technical question comes up. Requirements have to be reconciled, a meeting prepared, one option checked against another. We respond to all of these with practised routine: either we sort the topics chronologically into a linear list of tasks to be worked through, or we assign a topic to someone who then has to work out how to handle it.

In neither case are we conditioned to immediately translate the task into an executable prompt. Recognising a need, clarifying the route to a solution, and working through the task have so far been separated events. What has to be trained is the ability to identify those tasks that can go into straight execution by formulating a prompt rather than adding an entry on our Todo list.

Yesterday’s methodology

Monday meeting: we agree to bid for the school project mentioned earlier. Some helpful person has downloaded 27 documents of scope, requirements and so on. I agree to take on the job of reviewing the lot and to start structuring an offer so that everyone is able to give their inputs. I know I will need a few quiet hours over the coming days, so I schedule the task for Thursday. Knowing full well that a lot can happen in my calendar until then.

Today’s methodology

The scope document is being analysed by AI while the Monday meeting is still running. Building on the first result, I task my chatbot to propose a room-schedule and ask to add an allowance for structure, services and circulation areas for a three-storey building. On that basis I request the AI to estimate a fee calculation, then related to the scope of services a staffing calculation. All of it produced on the side by the AI while I am sitting in a routine meeting. Of course, all results are to be understood as a first proof and are to be checked and tested for plausibility, exactly as if a new colleague had prepared them on my behalf. Over the following days I ask my chatbot two or three times to retrieve some specific details from the tender documentation. Come Thursday the initially allocated time-slot is used to turn the products from the past days into a comprehensive result and not to sift through the documents and establish a basic structure.

It’s not about prompt engineering

This example is not about formulating the perfect prompt but about the presence of mind to hand a task over to AI in the very moment it occurs. I achieve my most effective prompting whilst the necessary route to a solution is being formulated in my mind. The possibilities of the new tool are known; for many, the reflex remains the old one: write it on the task list, Deal with it on Thursday.

Collections of supposedly optimal prompt templates do not solve this. What matters is training the ability to notice and act throughout the working day: Here the AI could execute some research for me; there we could structure a set of design parameters. And whilst we’re at it, that decision could be quickly cross-checked for good measure. My recommendation: condition yourself by handing such tasks immediately, even if at the second or third step you don't use the generated results. AI is excellent for doing things on the side that you usually won’t have time for. Rest assured: come Thursday, new tasks will be found for the time you have saved by utilising your chatbot.

From this observation comes the conviction I stated at the outset: prompting cannot be learned in a classroom. It can only be practised. Ideally where the real everyday tasks live: on your desk at work.

Isolated tool training does not reach this point. You can explain a system at length without a single reflex being exercised. In my experience only practice on real tasks in one's own working context is effective — not in the evening, not on a demonstration example. That makes the problem of getting started a resource problem that employees cannot solve for themselves. Where management does not allow the necessary time for experimenting and testing within the work-context, people will almost certainly remain stuck in the theoretical application of AI without any practical effect.

On the origins of a false expectation

Over the past years the advancements of browser-based services have turned us into digital consumers. The introduction of the first smartphone and touchscreen in 2007 is probably a good marker, even though the transformation as was obviously a longer development. With the touch of a finger, we confirm a desired product or discard it with a swipe. The best beaches googled, the destination clicked, the system does the rest: ticket issued, hotel booked, beach lounger reserved.

We choose and configure our desires in the palm of our hand and believe to have planned: The railway portal takes origin and destination and returns the matching connections. A kitchen- or car-configurator leads through models, colours, fittings. Entertainment, groceries, fashion – all configured, ordered, delivered at the touch of a button. So why not architecture next? The on-screen interaction has become more impressive year by year, but all of it moves entirely within a pre-determined space of possibilities. The app does not produce your journey; it selects an existing connection. The configurator does not generate the product; it merely enables you to access the catalogue. Many keep forgetting the decisive difference: the list of possible choices is pre-determined. Even though the choice grows broader and the digital experience becomes more immersive: a connection that does not exist cannot be booked.

Adjust your approach to find the right mindset

Involuntarily many seem to carry these learned patterns of expectation into AI. For sure: familiar interfaces reinforce the effect. An input field, an answer, a subscription and a price model — interacting with chatbots and image generators fits seamlessly into the appearance of other digital services. Accordingly, we demand the desired product in the tone of an order: "You are an award-winning architect. Design me a house. Don't make mistakes."

When the resulting output fails, frustration follows. The AI’s answer seems superficial or professionally wrong. And immediately we collectively fall into a widely accepted and rather comfortable conclusion: The technology makes mistakes. Human checking and correction are indispensable. The systems are not yet mature enough for serious planning work. Back to the familiar software. Carry on as before.

A suitable reaction that safeguards our comfort zone: We remain in the ordering mode of personalised digital services and expect planning solutions from a new, infinite catalogue that simply does not exist in that form. To achieve tangible results, we need to adjust our approach instead of hoping for the next model upgrade. Weren't we going to acquire a new skill and practise it?

To move forward I am recommending a slightly adjusted approach, which at first glance might appear banal: "I want to plan a house. How could you support me in that?" The difference is not a question of tone. The opening establishes who is the author of the process.

Who delegates and who assists. Not: who orders and who delivers.

Algorithms require clearly defined target coordinates

Automated procedures - algorithms - require defined inputs and traceable rules so that, within a given domain, they can repeatedly produce admissible results. Artificial Intelligence is amazing because it is adding a new probabilistic approach to this capability. Nonetheless, one condition carries over: where I can name precisely what I am aiming at, AI can produce remarkable results. Where I cannot, the output may be impressive and stimulating, but it stops being usable as planning material - because neither the system nor I have anything to measure it against. Some of these limitations might be resolved in future generations of AI models. Nonetheless, I fail to imagine a future digital system to design in full autonomy. The human direction of the decision-making process will remain vital.

In short: If a building design could be derived from a fixed catalogue of laws, standards and set rules, someone would have conceived that algorithm a long time ago.

The process of planning in contrast is not the application of set rules; it is the creation of the necessary framework so that rules can be applied in the first place. For a particular place, a particular client, a particular brief: Which requirements apply? Which of them are essential? Which contradict each other? Which foundations are missing? Which decision ought to be taken now and which may remain open for later?

And above all: does our carefully balanced structure of decisions still correspond to the original task?

Designing is concerned with defining target coordinates

Architecture is not produced by lining up rule-based decisions. Rather, we establish the conditions under which rules can be applied in a meaningfully way. Architects work out the algorithm that is necessary for the construction of a building that meets a given set of requirements. And alongside that, architects reconcile this algorithm with the interpersonal process by which all project participants come to a shared understanding and are enabled to provide their contribution to the project. Designing a house is not a personalised digital service; it is a collective effort of transforming our physical reality.

Artificial Intelligence is not a catalogue of set design solutions

It is a widespread misconception that AI already contains all the answers that a design process requires and that these merely need to be extracted by clever prompting. By now the top tier LLM‘s almost certainly command the entire volume of specialist engineering knowledge. What they do not have at hand is specific knowledge about your projects site constraints, the context of the project‘s history, the decisions of recent months, the individual contributions of various participants, the current state of design, and all those tacit determinations that have become self-evident consensus within a project team through years of professional experience.

To efficiently contribute artificial intelligence needs to be given a role and clearly defined, achievable tasks. "Design a house, don't make mistakes" won’t help here. AI is not a pre-determined „out-of-the-box“ solution. To turn it into an effective assistance system you will have to start by mapping its capabilities in consecutive small steps.

The absence of valid context leads to convincing hallucination

As you have developed a good feel for AI as new digital assistant and you have become good at identifying tasks that you can pass on to your chatbot for processing, two categories of information are becoming indispensable for generating more reliable contributions to your design project:

First, dependent on the given task, specific elements of the surrounding „project context“ might be relevant: characteristics of the location, legal requirements, specific performance requirements, etc. Your LLM’s training data as well as its access to the internet provides a lot of applicable information; other elements again are only available within the specifics of your project. Important is that your prompt is pointing at a valid source. If not, your chatbot is left to guessing (which it is very good at).

Second, also certain aspects of the projects present „planning results“ might be a necessary background for the LLM to include in the processing of the given task. Which decisions are fixed? And where have you identified open questions yet to be explored?

Both categories of project information are from a human perspective provided in the form of drawings and documents. To my experience however, the quality of data within those documents is rarely suitable for an LLM to interpret safely. To circumvent this I have developed the habit of extracting the relevant data from our design documents in a first step, before feeding this data as context information into the actual generation of the envisioned result.

As a long-term perspective, I expect that we will have to develop rather excessive strategies to prepare, maintain and validate a database of project context information to have the AI generating design documentation from this pool.

Design Documents are not a recipe for building a building

Planning documents, as a definition for the construction of a building are a strongly abstracted form of communication. A floor plan, a section or even a detail are not an extensive explanation of the process of building but a symbolic language whose power lies precisely in not having to explicitly represent large quantities of knowledge.

At 1:100, a floor construction is a line. Every professional knows that no millimetre-thick floor is envisaged. At 1:20 that line becomes two or three lines, a hatch, an abbreviation. At 1:5, six or seven layers with a few material specifications, thicknesses and selective technical terms. Even in the full construction documents our planning information remains a compression of the actual technical instruction.

This approach works in an effective manner, because the information is exchanged only among professionals. Whilst reading the recipient is required to add the aspects that are not explicit in the drawing: assemblies, material properties, junctions, execution principles, standards, empirical values, risks. Complete understanding arises only from the interplay of explicit drawn information and the implicit knowledge of those involved.

Sending Intent – express the what, not the how

In this form of communication, we do not consciously project every missing specification onto the drawing; the recipient derives selectively, according to their individual requirements or their area of responsibility. Also, the information is not absorbed in a linear fashion – as one would read a novel or a software runs through a piece of code – but by checking individual points of interest; the exact approach is dependent on individual project knowledge as well as general experience built up over years.

Humans do not need to absorb a set of drawings in totality to arrive at a first assessment. Planning documents imply instructions for a consecutive process without specifically naming those. The factual content lies not in the document but in the actions it precedes and the physical condition it anticipates.

For this reason, our design documents are always reduced to expressing the envisioned result of the plan but never the reasoning how we have reached at that specific decision.

Receiving Intent - the art of selective reading

This form of content requires the competence of the receiving party. The carpenter knows his trade; from the drawing he takes an outline and a dimension. How to join the timber he knows better than the planners do. The purpose of the document is not to explain to him how to handle his tools. In addition, we are accustomed to resolving finer details or open questions at an appropriate point later, during the further course of the project. The timing of which decisions become relevant when and what aspects are critical right now are judgements that are being trained in years of practical experience. Commercial chatbots, as far as they are currently available for our use are lacking that perspective; they exist only in the now of the given thread. The possibility of prioritizing and clarifying a matter later is an option currently unknown to them.

Planning is a gradual process, generating content is not

Without the ability to conduct planning as a gradual process, the AI lacks what is presumably a central level of perception. As a software it is trapped in the information currently available. Its task is fulfilled with formulating a singular output.

It is to my mind the central field of exploration, to devise an AI-System that can hold and maintain some form of a project memory and to derive from this a digital equivalent of anticipatory thinking:

What is the last design decision that we have taken?

Which portions of the project are affected by this decision?

What is the next task that follows this decision?

The line represents a continuous timber floor in a kitchen-living room. Which timber is hard-wearing enough? Can it be combined with underfloor heating? Does a hardwood fit our sustainability requirements? And the client's budget?

The AI can answer each of these questions in impressive detail. But formulate the questions unprompted, at the right point in time, on its own account? So far, unlikely. Of course, my chatbot can identify open questions. But until now it has no way of calling me and pressing for an answer.

Should we resist the temptation to go full detail?

If AI needs more context, then in future we will simply work with more extensive datasets. Maybe we let the AI generate content and steer from the passenger seat. As a step into AI-supported planning this almost certainly a valid route to take. As a new method for designing though, it deserves a closer look: the changeover might turn out not be quite that simple.

Our line at 1:100 is not necessarily an expression of insufficient planning. It corresponds exactly to the appropriate state of information of the related design phase. Everyone involved understands that there will be a floor here, how the floor will be built up we will settle later. This vagueness is not a deficiency; it is part of the process — the human way of keeping an overview of the project. Planning develops over time, and early precision can become an obstacle when it fixes matters before the basis for doing so has been established.

Planning quietly distinguishes the quality of decision-making

If we were to allow an LLM define every piece of the design as precisely as early as possible we might have achieved maximum context but also created an obstacle for us keeping an overview. Instead, we should aim for a distinction between what has been settled, what is currently assumed, and what is deliberately left open. One might call it controlled vagueness.

For human participants this temporal dimension is self-evident. An architect looks at a line in a preliminary design and knows not only roughly what it represents. He also knows that certain properties of this element are to be determined later. The drawing therefore not only documents the envisioned building. It also documents the current state of thinking about that building.

As far as I can tell, artificial intelligence has not given any indication that it could safely anticipate a future course of a design. For a human being, the reduced representation means: sufficient for this level of detail. The context of an active project indicates that there is work left to do, For the model on the other hand, what is present is all there is — unless we as the user explicitly communicate the information status and articulate what is to be done next.

Absence does not mean “of no importance”

The context provided to the AI must therefore contain more information than the documents we would conventionally refer to as planning information. An extended dataset would have to express: What do we not yet know? What is deliberately open? What is only provisionally assumed? What has already been decided? And which decision is to be taken only later?

This perspective substantially changes the demand for "more context". Our objective is not to feed the maximum quantity of set detail information of our design project, but to assemble an active matrix that reflects elements of full precision as well as deliberately preserved openness. In short: the absence of information must not be read as "not relevant".

When AI takes over the production, the designer is pressed with evaluation

Capable AI systems structure schedules of accommodation within minutes, articulate requirements, describe room typologies and derive material concepts from them - and every further prompt multiplies the volume of planning material generated a minute ago. Design data that conventionally required weeks of manual work is now generated on a Monday before lunch break. Employing Artificial Intelligence makes the process of production disappear, and with it the days-long internalisation of the subject matter.

Many early definitions of a planning process can be handled by a chatbot based on quite modest inputs. Validating those results however creates a cognitive strain, that we haven’t really prepared for. Referring to point of ordering your chatbot: A majority seems to expect the result they demanded in the form of a finished product, what most are not prepared for is an initial draft for them to review and comment.

The increase in Quality Assurance is a critical side effect that we will have to approach step by step. Our ability to professionally assess all these outputs and piece them together does not accelerate with our ability to have them generated. We remove a production bottleneck and create an evaluation bottleneck. What is scarce is no longer the availability of planning-relevant information. What becomes scarce is our capacity for attention, classification, judgement and decision-making.

Are architects not used to validate the design team’s contributions?

At first sight this is paradoxical. Planners are, after all, trained to keep an overview of complex matters; a larger building project consists of a large quantity of interconnected information. The contradiction dissolves once we distinguish between form of complexity. We do not master planning by absorbing all available information at once and holding all of it simultaneously in working memory. Our professional experience works with patterns, hierarchies, shortcuts, priorities and intuition. It does not treat every piece of information with equal intensity.

The overload therefore does not arise because AI-supported planning is fundamentally more complex. It arises because the complexity is structured differently: our competence is based on intelligent compression and now we are faced with a machine whose strength lies in the expansion and explication of information. Precisely where the system becomes particularly capable, we lose our accustomed command of the information.

Two aspects of this seem to me essential:

First - Planning with generative AI will require more and different context-data which again requires us to adjust our methodology of distributing the workload:

A new cognitive bottleneck arises not despite, but because of the successful provision of context. The better the context, the larger the problem-space the system can work on, and the more demanding it will become for us to keep a general overview. Better AI models will not eliminate this problem; they will intensify it.

Second - As a result of such redistribution we will aim to increase the use of AI systems to check our AI’s outputs. This will lead to a simple new objective to emerge: What is the smallest human input required to safely steer the largest possible volume of planning decisions through a generative process predominantly overlooked by AI Agents.

A conventional human design process limits the depth of investigation automatically – an intuitive measure formed out of the availability of experience and time — usually without noticing we adjust the degree to which we are „going into detail“. This means, we are used to abbreviating our output information in relation to the available resources. The model does not know this limit. Does the human form of abbreviated planning information thereby become an obstacle? Or is it also an achievement, a way of remaining master of the process? Experience means, among other things, knowing which elements of the design we do not have to articulate or check.

As much as we have been trained to interpret a simple line at scale 1:100 to represent the flooring of a building, in future we will have to learn that not all of the extensive machine-generated information is commending the same attention.

My take on three current convictions

I hope that this excursion is so far helpful as an indicator why employing AI within our current architectural planning processes might be no easy feat.

Let’s continue our journey by assessing some prominent fears that are related to the above-mentioned conviction that AI is generating unreliable results. The flip side of this belief is the open question of who has the necessary knowledge and work experience to verify the multitude of AI generated results to a point that they can be safely transformed into valid design documents:

a) Design responsibility is legally determined

For formal planning processes the rhetoric question who can take accountability for AI generated contents is legally resolved and by that no open question: Whoever is planning to erect a new building needs to file a planning application. For this, it is required to employ a listed architect, who by law will be held accountable for all documentations submitted as part of the said application. Any aspects that the architect cannot cover with his own qualifications specialists are to be employed.

As required from the architect, also the structural engineer or the fire safety engineer need to hold proof of their qualification. In addition, critical parts of the design may further be validated by independent specialists who again need to document their appropriate qualification. In short: within a planning approval process no document is accepted unless it can be connected to certified individuals.

A client ignoring this base requirement in contracting a design team is acting in gross negligence, risking the rejections of the building application and in worst case demolition of illegally erected parts the project.

Software systems will not obtain the necessary professional qualifications. The responsibility remains with the individuals filing the application. Any shortfalls or mistakes remain with those authors, irrespective of these having been caused by an unchecked work student or an AI system.

b) We’re focussed on checking results not inputs

The above conviction is always being met with the need to check the AI’s output and rarely with a need to review the human inputs. This learned habit of retroactive quality assurance is related to the structure and purpose of our current design documents, as we have analysed above: Their objective is only in one part to contain accurate information but also to sending the right message to the envisioned recipients. This judgement call is related to experience rather than a clean assembly process.

Our current form of communication leads us deep into the formatting and appearance of our documents: the author needs to be evident, so we place a logo; the related project is key, so the name is placed in the headline on every page; recipients consume the information in manageable chunks, so we devise named chapters in bold and sub-chapters in a slightly less imposing font. All needs to be structured with a numbering system to give overview – even if many functions of the design intent are interrelated and repeated throughout the document.

In future we will have to learn to focus on the contents first and the structure second. The printable document will become a byproduct generated by AI out of a centralised set of planning data as a concluding step and not the foundation from which we extract the desired content in the first place.

Thus, our new objective shall be to validate singular design aspects as part of a centralised data pool once and then extracting them into ten different design documents – instead of checking ten design documents in detail to ensure the singular design aspects are represented accordingly.

c) Younger Generations will be unable to adopt the necessary competences.

I have learned my trade as an Architect in production; effectively by years of drafting plans. In the not-so-distant future generative AI will greatly reduce our production cycles and by that the opportunity to for younger Architects to participate and learn.

I fully align with the fears connected to this future vision.

In reverse however the authors of that claim fail to indicate that when it comes to utilising the potentials of generative AI we all are pupils once again. More so, we must admit that the elder generations – those with the experience to check the AI generated results (!) - have the disadvantage when it comes to adopting AI as a new practical skill set.

To erect a building is in most parts no elaborate magic. Every element is based on requirements that are easy to define, and most of these requirements are well documented on the internet - child’s play for any reasonably trained common purpose LLM.

The complexity of design project lies within the network of decision making, so the how and why we have placed our decisions in this precise manner and no other constellation?

The AI wouldn’t know. Even worse, it almost certainly will start hallucinating and by that missing some essential point of the design that all too often is crystal clear to all human participants.

My conviction in short

Architects are problem solvers. AI is a system to solve problems. Generative AI has an unparalleled capability for producing convincing images and persuasive text - and much of what we do as architects is to offer a group of people a credible account of a future building worth building.

To employ Artificial Intelligence to its full potential we will need match our methods to the prerequisites of this technology. This means, those who know how to plan are possessing the initiative to utilize the largest potential of this new technology.

To formulate an endpoint, I want to lead back to the core of our work: why do we plan the way we plan? Is it a form of structured decision-making that can be emulated by a probabilistic algorithm? Which aspects of our work methodology need to remain, and which must be revised?

There are no established findings we can draw on. We are looking at a new field of investigation, one the whole industry - from developers to planners to software startups to construction companies - will have to take part in.

One distinction runs through everything that follows: Data is the line on our drawing. Context is what we expect everyone else to know so that they may read our intent correctly - what the line stands for, what has already been decided and what is still open. Our documents carry the first and assume the second. That assumption holds between professionals I the best of cases. But it certainly does not hold for data driven design executed by a machine.

Fields of Practice

Integrating AI into planning scales gradually, across three fields with different responsibilities.

The first field is yours personally. It is the prompt reflex: individual tasks in the course of the day, handed over immediately instead of postponing them until later. It costs little beyond attention and changes your working routines only in small steps.

The second field belongs to the office. Here the objective is to gradually establish new methodologies. These will mainly evolve around practicing new forms of data management. This field will require you to deeply venture into active knowledge management systems, all of which is still a vast terrain of research and experiment.

The third field belongs to architects and planners as a combined profession. Those new methodologies of data driven design will be meaningless if practiced in isolation. Planning and building is a collective undertaking; a new digital working culture does not arise from the innovation of an individual but from jointly developed conventions.

All three fields will require your initiative and investment. As the workshop in Weimar has shown: Sharing what worked and what did not is increasing the entire groups AI-knowledge overall.

Unsteady Terrain

Whichever field you start in, expect the ground to stay unsteady. The technology still develops faster than we can adapt to it. Anyone willing to invest in AI integration should be prepared to venture into an unknown mountain range for some time yet. One sees more from an altitude reached than one has actually walked. The ridges can be named without having been crossed. What one sees from up there is terrain, not a path, and the difference between a view and a route is learned only by further exploration on foot.

Nor will it get easier with practice. To stay with the image of a foreign language spoken fluently: as soon as the people around you notice that you speak their language, the pace changes. The vocabulary grows, the topics get harder. And before you know it you are confronted with regional dialects and cultural references you did not know existed yesterday. Practice does not make the thing simpler; it increases the depth at which you can move.

Where to Next?

Four points remain open for further definition:

The first concerns the practical substrate. We do not yet know enough to say precisely how AI is to be integrated into our planning processes, but evidence of a new way of working turns up every day. It sits in filing structures, in who on the team maintains which context, and in the handover points between participants. None of this is a question of better models. It is a question of what we do.

The second concerns experience. Our capacity for judgement has so far arisen as a by-product of producing planning documents. The days-long internalisation of the subject matter was at the same time the training. If that process falls away, where does the ability to assess machine-generated results come from — and what does that mean for those entering the profession, for the structure of offices, for teaching?

The third concerns responsibility. Work can be handed over, responsibility cannot. If production accelerates dramatically while liability remains unchanged, what we are actually paid for shifts. Schedules of services and fee structures do not yet acknowledge that shift.

The fourth concerns the recipients. Until now a planning statement has been bound to the document in which it is set down. In future every participant could interrogate the project context for whatever is relevant to them at that particular moment. What this means for binding force, design status and responsibility remains to be clarified.

Ready for Handover?

One shift is worth naming, even though it is not yet in reach: Producing design content is our means of internalising it; the days spent drafting were also the days spent understanding. The more AI produces, the more project knowledge is being externalized – I have grown accustomed to asking my system where we stand. The trade is real: the machine is faster and holds more information, more accurately, than I can. The question is whether everyone is willing to accept that handover.

Before getting on the barricades, it is worth admitting that we already practise that pattern. As soon as a piece of information carries the approval of the highest in the food-chain, most in the team stop questioning it. We do not verify; we rely. What changes with AI is not the habit, but where we direct it — and that the machine, unlike the partner who signed off, can always be asked why.

There is, as you can see, still a good deal to do. What matters is this:

AI does not do our thinking for us. It forces us to look more closely at how we think, plan and decide. That is more strenuous than hoped — but considerably more interesting.