AI is a bullshit machine, and construction is feeding it

On a major cost-reimbursable programme, I have been trying to obtain something far less exciting than an artificial intelligence strategy: a usable activity budget. I am not asking for a predictive digital twin, an autonomous commercial manager or a chatbot that can explain the contract. I am asking for a budget showing the labour, staff, plant, materials and subcontract resources needed to complete each activity, linked to the programme and capable of being checked against what actually happens on site.

The contractor has a programme, accounting records, payroll, purchase orders, plant returns, timesheets, daily reports and enough Excel files to keep several commercial teams occupied for years. What it does not have is a dependable connection between the work, the resources, the output and the cost. Activities change name between departments, cost codes are too broad or applied after the event, labour records show attendance without production, and material costs arrive in the ledger long after the work. Nobody can point to one record and say, with much confidence, that this was the budget for the activity, these were the resources used, this was the quantity completed and this was the cost incurred.

This is exactly the sort of problem that now attracts an AI demonstration. Load the programme, cost report, daily records and correspondence into a platform, ask why an activity is late, and within seconds the system produces a neat explanation. Productivity is below plan, a material approval remains outstanding and another crew may be required. A coloured chart shows the risk, while a short narrative is prepared for senior management. The result looks far more complete than the records from which it was produced.

The demonstration becomes less impressive when somebody asks which programme revision was used, whether the planned quantities were ever agreed, what the ledger date represents, whether the daily report recorded output or only attendance, and why the same excavator appears under three different descriptions. The system may still answer, because answering is what it has been designed to do. The question is whether anybody in the room can tell when it has moved from reading the evidence to inventing the missing parts.

Bullshit, now automated

A lie is intended to conceal the truth. Bullshit is different because the person producing it is not chiefly concerned with whether the statement is true or false. The aim is to create the desired impression, win approval, avoid a difficult question or keep the meeting moving. That is an uncomfortable but useful way to think about generative AI, because a language model is trained to produce a likely and convincing response rather than to carry a professional duty to establish the facts.

The model does not know that a payment recommendation may be audited five years later, that a programme assessment may decide millions of riyals, or that the wrong drawing revision may place people at risk. It does not feel embarrassment when it joins two unrelated facts, treats a draft as final or states an assumption as though it were proven. Tools connected to search, databases, calculators and written rules can improve its work, but the fluency remains. A correct answer, a partly correct answer and complete nonsense can all arrive in the same calm tone.

Construction is unusually exposed to this because so much of its output takes the form of formal language. The industry produces letters, notices, meeting minutes, risk registers, method statements, technical submissions, progress reports, valuations and claims in vast numbers. Much of that writing follows familiar patterns, so AI can prepare a credible first draft with very little effort. It can also write a beautiful explanation for a number that should never have been trusted, or produce a detailed summary of a project position that nobody has properly established.

This does not make the technology useless. It is already very good at reading, drafting, comparing, translating, classifying and finding patterns across large volumes of text. It can identify that several descriptions may refer to the same material, extract fields from old records, compare a submission with a checklist and flag that a document appears to be missing. The mistake is to treat those abilities as proof that the system understands the commercial, technical or contractual meaning of what it has found.

The most useful comparison is a very fast junior assistant with wide reading, no fear of embarrassment and an unfortunate habit of filling every silence. Such a person could save a capable team a great deal of time. Nobody sensible would give them final authority over a payment, programme assessment, design approval or contractual notice without checking the work, yet that is close to what some AI sales pitches now imply.

The data is not simply bad

“Bad data in, bad data out” is no longer a strong enough description of the construction problem. Dirty data suggests that a correct record exists and merely needs cleaning. Much construction information is missing, disputed, late, incomplete, duplicated or created for a different purpose. A system cannot clean a fact that was never recorded, and it cannot settle a disagreement between parties by selecting the version that sounds most likely.

A programme activity may say “install drainage” without identifying the road, chainage, pipe size, depth or work front. A labour return may show 40 workers without recording what they produced. A plant sheet may record ten operating hours without stating whether the excavator was digging, waiting, moving materials or attending rectification works. A ledger entry may show “site materials” under the supplier's name three months after the goods were used. A progress photograph may have no reliable location, drawing reference or link to an inspection. Each record exists, yet none provides enough information to answer the questions later asked of it.

AI can standardise “RC”, “R.C.” and “reinforced concrete”. It can suggest that “MH-04”, “Manhole 4” and “Drainage Chamber 04” may refer to the same asset. It cannot know whether the concrete was used for a base, chamber, thrust block, encasement or repair when nobody recorded that fact. It may infer the answer from nearby text or common practice, but an inference is not evidence, particularly when the result is being used to approve payment, forecast cost or allocate responsibility.

Construction projects make this harder because they are temporary groups of organisations rather than one business with one settled record. The employer, designer, consultant, contractor, subcontractor and supplier each create information for different reasons, at different times and under different duties. The contractor's daily report, the consultant's site record, the designer's response and the supplier's invoice may all be internally consistent while describing different parts of the same event. Even where the facts are broadly agreed, the parties may disagree about status, cause, authority or contractual effect.

This is why placing every PDF in a search system does not create project intelligence. A searchable document is still only a document. The system must know whether it is current, approved, superseded, rejected, draft, confidential or incomplete, and it must preserve the source from which each answer was drawn. Without that structure, it can retrieve a sentence from a rejected method statement as quickly as it can retrieve the accepted version, then present the result in language that makes the distinction easy to miss.

The same issue appears in almost every proposed construction use of AI. A scheduling model needs honest progress records and stable activity definitions, but programmes are regularly revised, activities are renamed and actual dates are entered late. A cost model needs expenditure linked to quantities, locations and the period in which the resources were used, while the general ledger may show only the supplier, nominal account and posting date. A computer-vision system may identify a pipe or item of plant, but it cannot know whether the pipe is approved, tested, damaged or part of rectification work unless those facts sit elsewhere and can be linked to the image.

None of this means AI cannot assist. It means that construction has been pretending a document-management problem, an accounting problem, a planning problem and a records problem are all one AI problem. They are not. The model is the visible part, but the hard work lies in deciding what the records mean and how they connect.

The scoreboard is already lying

Construction has always been good at measuring activity and calling it progress. A manpower histogram shows how many people are present, but not whether the right work is ready or what those people produced. A procurement report counts enquiries, quotations and purchase orders, but may say little about whether the material will arrive before it is needed. An RFI log records how many questions have been closed, even where the answer has moved the problem into another document. A cost report shows expenditure by accounting period, although the work may have taken place months earlier.

AI can make these scoreboards more attractive without making them more honest. It can generate commentary beside every graph, explain every variance and predict a completion date to the nearest day. Senior managers may receive more information, more often and in a cleaner format, while remaining no closer to understanding what is happening on the project. The danger is not merely that one figure is wrong. It is that the system gives weak measures a stronger air of authority.

A simple example is labour productivity. If a contractor doubles the workforce and completes the same daily quantity, production has been maintained but productivity has fallen sharply. A dashboard that celebrates the increased headcount or the achievement of the daily target may hide the commercial position. The same problem arises where a project reports 95 per cent design completion based on drawings issued, even though the remaining 5 per cent contains the decisions preventing construction. The number is not necessarily false, but it is answering a much easier question than the one management thinks it asked.

This matters because AI systems are often judged using similarly convenient measures. A pilot may report that the model found documents faster, reduced drafting time or answered a prepared set of questions with high accuracy. Those are useful results, but they do not show whether the system improved a real decision, reduced commercial risk or prevented an error. The pilot can succeed on its own scoreboard while the business problem remains untouched.

Construction therefore faces a familiar risk in a new form. It may automate the production of reports, explanations and indicators without improving the records or decisions behind them. The organisation becomes faster at describing the project while remaining just as slow at understanding it.

The performance of innovation

The person who launches an AI pilot may receive a conference slot, an award nomination and a photograph beside a large screen. The person who spends six months correcting cost codes, agreeing naming rules and repairing the route from purchase order to final cost report receives another spreadsheet to complete. The incentives are not difficult to understand, and they explain why so many AI programmes begin with the visible product rather than the information on which it depends.

A typical exercise buys licences, forms a working group and selects a controlled sample. Somebody asks the project chatbot a question it has already been prepared to answer, the response appears in seconds and the demonstration is recorded for senior management. Meanwhile, purchase orders still lack activity codes, drawings sit under inconsistent names, site events are recorded through messages, programme logic is weak and the general ledger contains descriptions such as “miscellaneous works”. The pilot may succeed as a presentation while failing as project control.

Clients, consultants and software companies all contribute to this. The client wants to show that it is adopting AI, the consultant wants to appear ahead of the market, and the software company wants to sell another annual licence. Nobody wants to begin the meeting by explaining that the organisation first needs to agree how it names roads, assets, work fronts, activities, cost items, drawings and changes. That work is difficult to present as innovation, although most of the promised benefits depend on it.

The language used in sales pitches does not help. Systems are said to “understand the project”, create a “single source of truth” or provide “real-time intelligence” when they are often searching documents, applying rules and generating text over records that remain divided across several systems. A chat window placed over a folder structure does not create a controlled project record. It creates a more convenient way to ask questions of the same uncertain material.

A serious test should therefore begin with the client's worst files rather than the vendor's best sample. The system should be given duplicate documents, conflicting dates, missing fields, superseded drawings, poor descriptions and inconsistent coding. The supplier should show which source was used, how the current version was selected, how uncertainty is displayed, how human approval is kept, how errors are corrected and whether the client can export its own information. A product that cannot explain how a wrong answer will be found and corrected is not a project-control system. It is a demonstration.

The answer is not a two-year clean-up

There is an equally unhelpful response at the other end of the argument: stop all practical AI use until every historic document has been cleaned, every code agreed and every system rebuilt. Construction cannot wait for perfect data, partly because perfect data does not exist and partly because a large clean-up programme can become its own form of corporate theatre. It produces policies, workshops and diagrams while the daily work continues through the same spreadsheets and messages.

The better route is to use live problems to improve the information as it is created. The data does not need to be perfect, but it does need to exist, carry enough context and preserve where it came from. AI can then help read old documents, match descriptions, extract fields, identify gaps and propose codes, while people decide the meaning and authority of the result.

Daily labour provides a practical example. A useful process would capture a worker identifier, employer, trade, work order, activity, location, ordinary hours, overtime, rectification status, supervisor, consultant adjustment, reason and approval. It would retain both the contractor's original submission and the verified record, then apply a controlled rate table to calculate cost by trade, activity, location and period. AI could read existing sheets, suggest mappings, detect duplicate names, flag unusual hours and prepare the final document, but it would not decide whether the consultant was entitled to reduce the time or whether rectification cost was recoverable. Those decisions come from the contract and the agreed work process.

The same approach can be applied to procurement. Rather than asking AI to summarise a folder of quotations, the organisation should first decide which fields are needed to compare the offers: system, specification, manufacturer, supplier, unit, quantity, coverage, lead time, delivery terms, exclusions, validity, warranty and approval status. AI can extract and compare those fields, but the commercial value comes from the comparison structure and the rule that missing information remains missing rather than being politely invented.

This is what data engineering means in practical construction terms. It means giving the same item the same identifier across the estimate, bill, programme, purchase order, daily record, invoice and asset register. It means separating the date of work from the date of posting, retaining invoice lines rather than only the total, recording the drawing revision used, limiting values to agreed options where appropriate and keeping a trace of every change. It also means accepting that old descriptions will need mapping, different systems will need reliable connections and somebody must be responsible for the definitions.

Most of this work is dull, but it is where the lasting value sits. The AI model may change next year, and the software vendor may be replaced, but a dependable record of the work, cost, time and authority remains useful. Construction has spent years treating this as administrative overhead. In a world of cheap AI, it becomes the thing that decides whether the output is useful or merely persuasive.

What happens next

The models will become cheaper, faster and easier to obtain. Several products will be able to draft a letter, summarise a report, classify a description, compare documents or answer questions over a project file. Those abilities will stop being unusual, which means the model itself will not be the scarce asset. The scarce asset will be a trusted body of project information and people who understand enough about construction to test what the system produces.

The first wave will mainly improve individual tasks. Quantity surveyors will draft correspondence faster, planners will compare programme updates, engineers will search technical records and commercial teams will extract information from quotations and invoices. This will save time, but much of it will sit above existing work processes. The business will remain dependent on the same folders, spreadsheets and personal knowledge, only with a faster route through them.

The more important change will come when firms begin to link the estimate, bill, programme, procurement, cost, progress and asset records through permanent identifiers and agreed definitions. At that point, an AI system will no longer be asked to guess whether two rows describe the same work. It will be able to follow the item from the original budget through purchase, installation, inspection, payment and final handover. Forecasting, benchmarking and commercial review will improve because the records describe the same work in a consistent way.

This will also change what clients buy. Data requirements will move from an appendix nobody reads to a defined project deliverable. Contracts and appointments will need to state which fields are required, who owns them, who may change them, how revisions are kept and what must be handed over. A pile of PDFs labelled “project records” will no longer be enough where the client expects future systems to use the information.

The professional roles will change with it. The valuable quantity surveyor will not merely know how to measure, price and administer a contract, but also how to define a work item, test a coding structure, trace a cost to its source and challenge an automated answer. Planners, engineers and commercial managers will need similar skills. They do not all need to become software developers, but they do need to understand how their decisions become data and what is lost when the record is reduced to free text.

Some firms will place copilots over existing disorder and report the hours saved in drafting. Others will use the same models while rebuilding how information is captured and connected. The first group will produce better-looking reports. The second will be able to make better decisions, train useful systems on its own work and carry knowledge from one project to the next.

AI may still change construction more than many current buyers expect. It can reduce the cost of reading, drafting, matching, checking and monitoring across huge project records, and it can allow smaller teams to carry out work that once needed large support functions. It can help repair old information and make better standards practical to apply. What it cannot do is create truth from facts that were never recorded, settle authority that the parties never agreed or turn a ledger description called “miscellaneous” into a reliable forecast.

The old warning was that bad data produced bad output. Generative AI creates a more dangerous result: bad data goes in and a confident explanation comes out. The error no longer looks like an error. It looks like a completed piece of professional work, ready to be placed in a report, presented to a client and repeated at the next meeting.

Construction should use AI, but it should stop pretending that buying the model is the difficult part. The difficult part is deciding what the information means, recording it while the work is happening and keeping enough evidence for a competent person to challenge the answer. Until that happens, the industry will not be automating intelligence. It will be automating the bullshit.