AI for Programming & Space Analysis

The first task of programming is a schedule of accommodation: a list of every space, with its function, quantity, area, and occupancy. Building this from scratch is tedious - you are pulling functions from the brief, assigning reasonable areas, and totalling. AI drafts a solid first version fast. Give it the brief and ask for a structured schedule, and it returns a table you can react to and correct.

A useful prompt keeps you in control of the assumptions:

From this brief, draft a schedule of accommodation as a table:
  space | qty | area each (sqm) | subtotal | occupancy | notes/assumptions
Use typical area standards for each space TYPE and state the assumption
in the notes column so I can check it. Add a NET subtotal, then a
gross-up factor line (circulation, walls, services) and a GROSS total.
List any space the brief implies but does not name as a separate
'possible omissions' section.

Two things make this safe and useful. First, forcing the model to state its area assumptions means you can check each one against your own standards or a real precedent, rather than absorbing a guessed number invisibly - and its area figures are conventions to verify, not authoritative standards. Second, asking it to distinguish net from gross area (adding a grossing factor for circulation, walls and services) is exactly the step beginners forget and clients are shocked by later. The AI will not know your local conventions or the client's real expectations, so you edit every figure - but you edit a structured draft instead of building one, and you start from a checklist that is unlikely to omit a whole category of space.

Two refinements make the drafted schedule more trustworthy. Ask the model to give a range rather than a single figure for each area - "typical 12-16 sqm" - which honestly signals that these are conventions with spread, not fixed truths, and nudges you to decide the actual number. And ask it to tie each space back to the brief item that justifies it, so a reviewer can see that nothing crept in the client never asked for and nothing the client wanted got dropped. That traceability, from brief item to scheduled space, is the same discipline that made the research and code workflows safe - and it turns the schedule into something you can defend line by line.

A schedule says how much; the next question is what goes near what. Some spaces must be adjacent (a kitchen and a dining room), some must be separated (a bedroom and a plant room), some prefer proximity, and some need direct access, daylight, or a particular outlook. Capturing these relationships is what turns a list into the beginnings of a plan.

AI can help draft this too. Give it your space list and ask it to propose an adjacency matrix - each space against every other, marked for the strength of the desired relationship (essential, desirable, neutral, avoid) - with a short reason for the strong ones. It can also translate that matrix into a described bubble diagram: clusters of related spaces, the key links between them, and the likely circulation spine. These are genuinely useful starting artefacts, because the model has seen countless typical arrangements and will rarely miss an obvious relationship.

But adjacency is where your project's specifics matter most, and generic logic misleads. The AI does not know that this client works from home and needs the study acoustically isolated, or that the site's only good view faces the noisy road, forcing a trade-off between outlook and quiet. So treat its matrix as a first hypothesis: correct the relationships it got generically wrong, add the ones peculiar to this brief and site, and resolve the conflicts it surfaces. A programmed adjacency diagram you have argued with is a strong bridge into planning; one you accepted uncritically will quietly impose a generic layout on a specific problem.

A good way to stress the matrix is to ask the AI to justify its strong calls and then argue against them. "You marked kitchen and living as essential-adjacent - when would that be wrong?" surfaces the cases (a formal household, a catering kitchen) where the default does not hold. The point is not that the model knows your project; it is that forcing it to reason exposes where the generic pattern and your reality diverge, and those divergences are exactly the relationships worth deciding deliberately rather than inheriting by default.

Programming is also a reality check, and AI is a fast calculator for it. The core question - does it fit? - has three forms. Against the site: does the gross area fit the buildable footprint at a sensible number of storeys, given coverage and height limits? Against the budget: does the gross area times a realistic cost rate land near the client's figure? Against the brief's ambitions: can every wished-for space actually be accommodated, or must something give?

AI helps you run these quickly and, crucially, run options. Ask it to compute the site fit at two and three storeys, to flag by how much the programme overshoots the budget at a given rate, or to propose three ways to close a 15% area gap - trimming areas, cutting a space, or increasing storeys - with the trade-offs of each. For multi-storey schemes, ask it to draft a stacking diagram: which functions on which floor, honouring the adjacencies, the public-to-private gradient, and structural and servicing logic (heavy or wet spaces low, quiet spaces high, public spaces near entry).

The danger here is false precision. AI will produce confident numbers from the cost rates and area standards you or it supplied - and if those inputs are wrong or generic, the tidy output is wrong too. So own the inputs: use real local cost rates and real site limits, sanity-check every total against a precedent or a quick manual estimate, and treat the AI's stacking as one logical option among several to evaluate, not a decision. The value is speed of optioneering - testing many fits fast - so you arrive at design already knowing what is feasible and where the pressure lies.

It is worth internalising that optioneering, not any single answer, is the real gift here. The value of an AI that can re-run the fit in seconds is that you stop treating the first feasible programme as the programme and start comparing several - fewer larger spaces against more smaller ones, a tighter footprint against an extra storey, a trimmed wish-list against a raised budget. Seeing the trade-offs side by side, before a line is drawn, is what lets you bring the client a real choice rather than a fait accompli - and it is exactly the kind of fast, structured comparison that is tedious by hand and quick with AI.

Beyond drafting, AI is a good analyst of a programme you have built - a second set of eyes on the numbers and relationships. Feed it your schedule and adjacency matrix and ask pointed questions: which spaces dominate the area and is that proportion right for this building type; is the circulation allowance realistic; are there orphaned spaces with no strong adjacency; does the public-to-private sequence make sense; what has the brief asked for that the programme has quietly dropped? It can compare your area distribution against typical ratios for the type and flag where you are unusually high or low - useful provided you treat "typical" as a prompt to think, not a rule to obey.

You can also use it to keep the programme honest as the brief evolves. When the client adds a room or cuts the budget, the programme must flex, and AI can quickly re-run the fit and show what the change costs elsewhere - the kind of fast what-if that makes trade-offs visible in the meeting rather than weeks later.

Throughout, the division of labour is the same one this whole module teaches. AI does the structured, repetitive, numerical work - drafting schedules, building matrices, tallying budgets, running options - fast and tirelessly. You supply the real inputs, the local knowledge, the client's true priorities and the site's real constraints; you check every number that carries weight; and you make every decision about what the programme actually is. Done this way, programming stops being a spreadsheet chore and becomes what it should be: a fast, rigorous, well-tested bridge from a sharp brief to a design that was feasible from its first line.