Introduction

Discussion about artificial intelligence and work often begins with exposure: which occupations are most likely to be automated, augmented or displaced? That framing is useful but incomplete. It treats workers primarily as recipients of technology built elsewhere. Generative AI introduces another possibility. Workers with deep knowledge of an occupation may increasingly be able to describe, prototype and refine their own software, even when they have little conventional programming experience.

Trades and construction provide a particularly revealing setting. Work is physical, local and variable, but the surrounding administrative burden is substantial: messages, photos, diaries, quotes, schedules, variations, invoices, safety records and customer follow-up. Many of these workflows are poorly connected. The person who understands the problem most intimately is often the person on site, not the software vendor. Until recently, turning that understanding into working software required significant capital, technical intermediaries or both.

This working paper studies a small community in which that boundary has begun to move. Across two WhatsApp groups, participants progressed from asking where to start with AI to sharing products built with Claude Code, Claude Cowork, Grok and related tools. They discussed ideal customers, minimum viable products, integrations, testers, pricing and sales. The exchanges do not prove a sector-wide transformation. They do, however, provide a useful early record of tradespeople becoming active builders of digital tools.

1.1 Three Propositions

The paper advances three propositions. First, that domain expertise is becoming executable — generative AI allows practitioners to translate tacit workflow knowledge into prototypes with less dependence on conventional software-development pathways. Second, that AI adoption is social as well as technical — peer examples, demonstrations and informal critique help participants move from curiosity to action. Third, that the bottleneck moves rather than disappears. Once prototype production becomes cheap, problem selection, evidence, integration, trust, security and distribution become more visible constraints.

This is the empirical companion to Revenge of the Tradie. That paper argued that AI removes the wall between knowing what needs to be built and being able to build it. This one goes and looks at what happened on the other side of the wall.

Research Questions and conceptual background

Five questions organise the analysis. How do tradespeople and construction professionals describe the problems they choose to solve with generative AI? What pathways take participants from AI curiosity to building a prototype or product? What forms of occupational knowledge substitute for, or complement, conventional software expertise? Which constraints remain after the cost and difficulty of initial software production fall? And what roles do peer communities play in learning, validation and commercialisation?

2.1 From AI Exposure to AI Agency

Labour-market analysis commonly evaluates whether AI can perform tasks within an occupation. This paper adds an agency-oriented question: can workers use AI to redesign the systems around their own work? The distinction matters. A construction project manager using a language model to create a site-records tool is not being displaced by AI. He is using it to build the thing the market never bothered to build for him.

Recent work supports treating this as a real category rather than an anecdote. Esnaola and colleaguesEsnaola, L.M., Ramón, H.D., & Lanzarini, L.C. (2026). Can generative AI bridge the gap? A quasi-experimental study of non-programmers with AI vs. programmers without AI. Empirical Software Engineering, 31, Article 75. examined non-programmers working with AI against programmers working without it, and SarkarSarkar, A. (2023). Will code remain a relevant user interface for end-user programming with generative AI models? Proceedings of the 2023 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software, 153–167. has questioned whether code remains the relevant interface for end-user programming at all. The OECD's recent work on AI and the SME workforceOECD (2025). Generative AI and the SME Workforce. OECD Publishing. See also OECD (2025), AI Adoption by Small and Medium-Sized Enterprises: Discussion Paper for the G7. approaches the same territory from the policy side.

What the literature has less of is field observation of practitioners doing this to themselves, in their own words, without a researcher in the room. That is what the corpus below offers.

Method

The study is an exploratory observational case study of two trades-focused WhatsApp communities, drawn from two complete text exports supplied by a group participant. The unit of analysis is the discussion episode or identifiable build, not the individual message.

Table 1: The two groups. *Group names are pseudonyms.

Both groups were founded and organised by Maxwell Semmons-Russell, a New Zealand tradesman-turned-builder and founder of Elastic Admin, an AI-native bookkeeping and administration service for the trades and construction industry. He has consented to being identified by name and business in this paper. Group names remain pseudonyms and ordinary participants are not identified.

Across both exports, the corpus contains 1,711 authored messages from 57 distinct visible sender labels, 215 system events and 146 posts whose only available content was "Media omitted". Media-only posts were excluded rather than inferred. The visible-sender figure is not a membership count and does not establish participant identity or country.

Participants appeared to include trades-business owners, builders, construction project managers, automation practitioners and technology-oriented community members. Messages referenced activity in New Zealand, Australia, the United Kingdom and Europe, with additional international participation. Roles and locations are treated as participant descriptions unless separately confirmed.

3.1 Analytical Procedure

The two complete exports were parsed as dated message records. System notices, deleted messages, spam, duplicated links without discussion and media-only posts were excluded from substantive coding. Repeated messages about one product or topic were consolidated into discussion episodes to avoid treating an extended conversation as multiple examples. Episodes were coded for build-for-self, domain knowledge, reduced build barrier, peer learning, validation, commercialisation, integration, security and reliability, pragmatic tool choice, and community infrastructure.

A conservative build inventory required enough visible text to identify an artefact, its intended function and a builder or use context. The audit identified 14 distinct applications, prototypes or substantial automations. Ten were explicitly tied to the builder's own workflow or business problem. Eight were reported as deployed, used internally, in beta or used by customers. These are transcript-confirmed statements, not independent verification of functionality, usage, savings, customers or commercial success.

3.2 Ethics, Privacy and Researcher Position

WhatsApp groups are socially bounded spaces even when membership links are widely shared. Their messages should not be treated as automatically public. This draft therefore removes phone numbers and does not identify ordinary participants. The groups' founder and organiser has consented, via direct correspondence, to the use of the group conversations as research material and to being identified by name and business; group names remain pseudonymous so that build descriptions are not attributable to individuals. Searchable verbatim quotations are avoided in favour of paraphrase.

The author was a member of and contributor to both groups during the study period, and took part in community activity beyond the chat itself, including one or more group Zoom sessions and an in-person coffee meet-up. He is not a neutral outsider: he is the founder of Node Labs, whose broader research programme argues that AI amplifies domain expertise, and the preceding paper in this track — Revenge of the Tradie — was shared into the groups by the organiser on several occasions during the study period, and shared by him on LinkedIn. The community being studied was therefore aware of, and to some degree exposed to, the thesis this paper examines. This participant-observer position provides interpretive access but creates real risks of selection and confirmation bias — the researcher had reasons to find what he found. Reflexive notes, transparent coding, the independent second-coder check and challenge review recorded in the supplement, and participant review are the safeguards applied against this.

Findings

4.1 Problems Begin in Lived Workflow, Not Technology

The strongest product ideas began with recurring friction that participants experienced directly. One UK construction project manager described sites as being unofficially run through WhatsApp: the tool was familiar and frictionless, but photos, decisions and records became difficult to retrieve. His prototype sought to convert conversational material into structured site diaries and project records. Another participant described a project-management application intended to replace several disconnected systems for scheduling, tasks, files and time logging.

This pattern differs from technology-first ideation. Participants did not begin by asking where a language model could be inserted. They began with information loss, duplicated entry, platform switching, poor record keeping and unpopular administrative tasks. AI became useful because it could interpret unstructured messages, photos, voice notes or files and turn them into the structure required by the business.

In the conservative inventory, ten of fourteen builds were explicitly connected to the builder's own work or business. Examples included job-cost visibility, site records, solar estimation, gas certification, accounting visibility, plan extraction for quoting and company-specific estimating. The inventory spans a range of maturity — from deployed products to substantial automations and scaffolds — and the count describes this corpus only; it is not a population estimate.

4.2 The First Customer Is Often the Builder

A recurring pathway was to build for oneself, produce immediate operational savings and only then consider external customers. One New Zealand participant described himself as the ideal customer and estimated that replacing several subscriptions could save thousands of dollars per year — a participant estimate, not an audited saving. This is a form of founder–problem fit grounded in occupational practice. The prototype can create value before it becomes a scalable company.

Self-use also changes validation. The builder has direct access to the workflow and can iterate frequently. However, it can create a second challenge: a system optimised for one practitioner's idiosyncratic process may not generalise. Moving from useful personal tool to dependable market product requires observation of other firms, clearer segmentation and evidence that the problem recurs.

4.3 Domain Expertise Becomes Product-Development Capital

Participants supplied much of the analysis that a conventional software project might obtain from product managers, business analysts and discovery consultants. They knew which records disappear, which applications workers refuse to open, when a task should become unavailable for time logging, why a familiar messaging interface matters and where switching between systems creates friction.

This suggests that occupational expertise may become a more liquid form of innovation capital. A practitioner who can explain a workflow, test output and recognise failure may be able to build useful software without first translating every requirement through a separate technical team. Technical expertise remains necessary for architecture, security and scale, but it enters at a different point in the process.

4.4 Prototype Economics Have Changed Dramatically

Participants repeatedly contrasted current build speed and cost with conventional development. One builder said that work quoted at approximately £15,000 a year earlier could now be prototyped with Claude Code in hours and refined over subsequent weeks. Another described a globally launched product produced through extensive 'vibe' development over roughly seven months. These are self-reported comparisons rather than audited cost studies, but they reveal a meaningful shift in perceived feasibility.

The relevant change is not that software becomes free. Time, API usage, hosting, testing and rework remain.

That expands experimentation and increases the number of niche products that can be attempted — including the ones no vendor would ever have found worth building.

4.5 Learning Is Peer-Led, Demonstrative and Tool-Agnostic

Community interaction was practical. Members shared websites, screenshots and videos; asked what problem a product solved; challenged one another to define an ideal customer; offered demonstrations; and discussed how builds were assembled. The group organiser proposed recurring show-and-tell sessions across time zones and a page that would archive products and builders. This is closer to a workshop or community of practice than a conventional course.

The coded corpus contained twelve consolidated peer-learning episodes, including implementation advice, positioning critique, tester matching, product demonstrations, Zoom sessions, coffee meetings and hackathon planning. This episode count is intentionally conservative and does not count every answer or shared link.

Participants also selected models pragmatically. One reported using Grok for rapid first versions and Claude to refine the same project. Others referenced Claude Code, Cowork, ChatGPT and connected tools. Loyalty mattered less than the fit between a tool and a stage of work. This fluidity suggests that durable training should focus on workflow, evaluation and problem-solving rather than a single vendor interface.

4.6 The Bottleneck Moves from Production to Reality

As prototype creation became easier, participants encountered constraints that language models could not remove. They struggled to recruit genuine users, worried about sales and conflicts of interest, debated whether the problem was painful enough, and confronted restrictions around WhatsApp automation. Community members recognised that architecture and security still matter, even if they can be deferred during early validation.

The evidence matrix records six validation episodes, seven integration-barrier episodes and four security or reliability episodes. The boundaries overlap: WhatsApp restrictions simultaneously affected lawful access, beta testing and product viability, while estimating discussions joined accuracy, liability and firm-specific data configuration.

Table 2: What fell, and what didn't

The phrase reality barrier names this residual constraint set. It is not a single stage after development; it is the continuous requirement that a system fit real work, survive contact with users and operate responsibly.

4.7 Open Communities Require Governance

The builders group also experienced unsolicited promotion, repeated lead-generation posts and bot-like behaviour. Members reported spam and removed at least one account. This is analytically relevant: peer infrastructure does not remain useful automatically. Clear boundaries, active moderation and norms distinguishing legitimate project sharing from extractive advertising are part of the capability system, not an administrative afterthought.

Discussion

5.1 A New Innovation Pathway

The case suggests a pathway that begins inside work rather than inside a software company: experience a recurring problem; describe the workflow to an AI system; scaffold a prototype; use it personally; show peers; refine the problem and customer; then seek technical hardening and distribution. Conventional startup stages remain, but their order and accessibility change. A domain practitioner can reach a credible demonstration before recruiting a technical co-founder or raising capital.

5.2 Revenge of the Tradie, Tested

The broader Revenge of the Tradie thesis is that embodied, contextual and relationship-based work may prove more resilient to AI than many screen-based occupations, while tradespeople gain access to increasingly powerful cognitive tools. This case adds an empirical extension.

The combination of physical competence, customer access and AI-assisted software creation may create an unexpectedly strong entrepreneurial position. The electrician who built a solar estimator has something a SaaS founder cannot buy: the enquiries, the jobs, the customers and the reason the tool exists.

5.3 A Provisional Reality Barrier Model

The reality barrier is not a single obstacle. Reading across the coded episodes, the downstream constraints cluster into five recurring questions that a prototype must answer before it becomes a product. The following is offered as interpretation, not as a finding: it is a provisional model emerging from one small corpus, and it should be read with the same discipline the rest of this paper applies to participant reports.

Table 3: A provisional five-part model of the reality barrier

Each barrier is visible in the corpus. Problem intensity surfaced in the "hair on fire" debates; access in the WhatsApp and Simpro API restrictions; proof in the repeated struggle to recruit committed testers; dependability in the estimating-accuracy and quote-liability discussions; and market in the anxieties around sales, positioning and conflicts of interest. What no episode showed was a language model removing any of the five.

One honest challenge deserves stating plainly: none of these barriers is new. They are the classic constraints every early-stage founder encounters. The distinctive claim of this paper is narrower — not that the reality barrier is novel, but that domain practitioners are now reaching it far sooner and in far greater numbers, because the development step that used to filter them out has collapsed. The barrier hasn't changed. Who arrives at it has.

If the model holds, it should generalise well beyond the trades — to educators, small businesses and community organisations attempting the same journey from domain knowledge to working product. Testing that generalisation, and validating the model against which of this corpus's builds survive, is planned future research in this track, including the six- and twelve-month follow-up described in Section 7.

5.4 Complementarity, Not the Disappearance of Developers

Some participants framed the change as the removal of the development barrier and expressed sympathy for professional developers. The evidence supports a narrower conclusion. Generative AI reduces dependence on developers for early prototypes and routine implementation. It does not eliminate the value of software engineering when systems handle sensitive data, integrate with critical platforms or serve many customers.

The emerging opportunity is complementarity: practitioners lead problem discovery and rapid prototyping; engineers help convert validated prototypes into secure, maintainable systems.

Implications

6.1 For Tradespeople and Small Businesses

• Start with one repeated, expensive or risky workflow — not with a desire to "use AI".
• Build a narrow personal tool first, but test whether the problem and workflow are shared by other firms.
• Treat a convincing interface as a hypothesis, not proof of a working product.
• Design data access, privacy and human review before automating consequential actions.
• Use peer demonstrations to accelerate learning, while seeking engineering review before scale.

6.2 For Educators and Community Organisations

Generic prompting classes are unlikely to be sufficient. Capability programmes should combine occupational problem discovery, rapid prototyping, evaluation, workflow mapping, data governance and opportunities to demonstrate work. A useful structure is Connect. Learn. Build. — bring practitioners together around common problems; teach tools in context; then support creation, testing and reflection.

6.3 For Policy and AI-Readiness Programmes

Public programmes should recognise practitioners as potential creators, not only trainees or technology adopters. Small grants, shared technical clinics, safe testing environments and sector-specific communities could help viable experiments cross the reality barrier. Support should be staged: broad fluency first, then workflow discovery, prototype assistance, technical assurance and commercial validation.

6.4 For Software Professionals

The opportunity is to work closer to validated domain insight. Instead of charging heavily to discover whether an idea can be built, engineers can focus on architecture, integration, assurance and scale after practitioners have demonstrated value. This changes the boundary of professional work without making the profession irrelevant.

Limitations and next research stage

The findings are non-representative and should be read as an early record rather than a measurement.

• The groups are small, self-selecting and unusually enthusiastic about AI, and the organiser is himself an active builder who shapes the community's tone. What is documented here is what is happening among the already-converted; findings cannot be generalised to all tradespeople.
• Media was not downloaded, and this is a larger limitation than it may appear: the 146 excluded media-only posts include the screenshots, demonstrations and voice messages in which working tools — and their failures — were most likely to be shown. The text-only view under-represents both progress and friction.
• Participant roles, business sizes, countries and prior technical experience have not yet been systematically verified.
• Claims about build time, prior development quotes, customers and savings are participant reports, not independently audited outcomes.
• The current draft was developed by a researcher connected to the surrounding community and is vulnerable to selection and confirmation bias; see the positionality statement in Section 3.2.
• The observation window is under eight weeks. It captures enthusiasm, prototypes and intentions far more readily than long-term adoption, reliability or business survival — and a corpus of active builders sharing progress contains few abandonment stories by construction.

7.1 Next Research Stage

The combined first pass is complete. The next stage is designed to increase confidence rather than fill a missing corpus: invite a second coder to independently classify a sample and refine ambiguous code boundaries; invite recognisable product owners to confirm descriptions, stage labels and participant-reported outcomes; maintain anonymous participant IDs; conduct a structured challenge review focused on negative cases and alternative explanations; seek consent for any direct quotation or attributable product case study; interview four to eight builders about prior technical experience, build process, tool costs, validation, security and commercial outcomes; and revisit the products after six and twelve months to distinguish prototypes from sustained use and viable businesses.

Conclusion

The conversations examined here capture an early but important change. Tradespeople and construction professionals are beginning to use generative AI not only to write emails or summarise documents, but to build the systems around their own work. Their advantage is not simply access to better models. It is the combination of occupational knowledge, direct exposure to business problems and new tools that can convert natural-language instruction into software.

That combination lowers the development barrier, but it exposes a harder one. Products must still solve urgent problems, connect to real data, earn user trust, operate safely and find a market. The future is therefore unlikely to be a simple contest between tradies and developers. It may be a new division of labour in which practitioners can explore and validate far more of the solution themselves, while technical specialists concentrate on making successful experiments dependable.

That is the practical lesson for AI-readiness efforts, and it is the reason this paper exists. The builders in this corpus found their way here on their own. The question Node keeps returning to is what happens to everyone who won't.

References

• Esnaola, L. M., Ramón, H. D., & Lanzarini, L. C. (2026). Can generative AI bridge the gap? A quasi-experimental study of non-programmers with AI vs. programmers without AI. Empirical Software Engineering, 31, Article 75. https://doi.org/10.1007/s10664-026-10813-7
• Sarkar, A. (2023). Will code remain a relevant user interface for end-user programming with generative AI models? Proceedings of the 2023 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software, 153–167. https://doi.org/10.1145/3622758.3622882
• OECD. (2023). OECD Employment Outlook 2023: Artificial Intelligence and the Labour Market. OECD Publishing. https://doi.org/10.1787/08785bba-en
• OECD. (2025). Generative AI and the SME Workforce. OECD Publishing. https://doi.org/10.1787/2d08b99d-en
• OECD. (2025). AI Adoption by Small and Medium-Sized Enterprises: OECD Discussion Paper for the G7. OECD Publishing. https://doi.org/10.1787/426399c1-en
• OECD. (2026). AI and Skills. OECD Publishing. https://doi.org/10.1787/f843b352-en
• Trades AI Exchange. (2026). General community WhatsApp export [Unpublished community dataset; pseudonym]. Community founded and organised by Maxwell Semmons-Russell.
• Trade AI Builders Circle. (2026). Builder community WhatsApp export [Unpublished community dataset; pseudonym]. Community founded and organised by Maxwell Semmons-Russell.