Software development / New methods and models
ConTechLabs explores how AI can help AEC professionals understand requirements, resolve constraints, reduce avoidable cost, communicate decisions, and learn from completed work. The Software Factory examines how we build and improve the applications that support that work.
We’re investigating a development process in which AI performs much of the analysis, implementation, testing, and review preparation. People define the purpose, apply construction and engineering judgment, assess trade-offs, and decide which changes should proceed.
A Software Factory brings those activities into a repeatable workflow: a useful signal becomes a defined task, a reviewable change, a verified release, and evidence for the next improvement. We want to learn which methods and model configurations improve the complete process, including the effort required to supervise and correct the work.
The questionCan we turn valid and early signal into useful construction software improvements with less delivery time and total effort, while maintaining quality, traceability, and human control?
01 / The lab experiments on its own methods
Our construction experiments investigate blockers, lead times, cost, communication, and learning. Their findings should help define concrete software behavior: which records to connect, which questions to investigate, which decisions to prepare, and how to establish whether the result helped.
For an AEC professional, the outcome should be a useful application that understands the work and produces a result they can inspect and act on.
The Software Factory tests the development approach behind those applications. We would examine how agents receive context, prepare changes, work with people, verify behavior, and respond to production feedback.
The two loops inform each other: construction experience improves the product requirements, and delivery evidence improves the methods used to implement them.
Valid and early signal applies here too. A user report, test failure, or production error should arrive with enough evidence and context for the team to decide what to investigate or change while the response is still useful.
02 / What we are exploring
We would evaluate the whole development workflow, from understanding the request through observing the released software. A model’s output is one part of that result. Context, tools, task definition, coordination, and verification also need to be assessed.
Describe the user need, construction context, expected behavior, and acceptance criteria before implementation. Keep the originating evidence linked to the task.
Provide repository instructions, relevant specifications, test data, and permitted tools. The harness is the working environment that coordinates context, model calls, tools, and execution.
Compare model-and-harness configurations on representative development tasks. Record the model, instructions, tools, cost, and review effort so results can be interpreted.
Explore individual sessions, planned missions, and coordinated agent work for tasks that benefit from them. Make ownership, dependencies, and integration work visible.
Check actual behavior with tests, code review, security review, and preview QA. Compare the result with the accepted task and evaluate effects on existing functionality.
Connect released changes to user feedback, errors, and observed behavior. Use verified results to propose improvements to the software, instructions, skills, and evaluations.
03 / Software experiment 01
Our first experiment will use Factory to provide the environment in which AI agents work with code, repository context, models, and connected tools. Factory’s development agents are called Droids.
We plan to evaluate work started by a person alongside work proposed in response to incoming signals. Both paths should produce a defined scope, traceable changes, and evidence that the result meets the agreed requirements.
Experiment design: The workflow below describes what we intend to evaluate. The listed sources are in scope; the diagram does not establish that connections or automations are already configured. People approve scope, plans, pull requests, and releases.
Development discussions, reported problems, and clarification.
Tasks, ownership, requirements, and acceptance criteria.
Code, issues, pull requests, reviews, and change history.
Reported errors and diagnostic context.
Specifications, decisions, and working documentation.
Relevant feedback and requests shared with the workflow.
Automated build results, tests, and failing checks.
Goals, ideas, domain expertise, judgment, and approval.
People-initiated work
A ticket, conversation, reported problem, or idea becomes a concrete task. Factory Droid uses the relevant context to prepare a plan, implement the approved work, and produce a pull request for review.
Signal-initiated work
An agent assesses incoming evidence, connects related records, and prepares a proposed task or clarification. Following scope and plan approval, Droids prepare the implementation and linked pull request.
04 / From signal to production feedback
This diagram uses Claude Code as the harness. Other options, such as Factory Droid, Warp, or Codex, could also be used. We may experiment with different harnesses and models as the lab progresses, comparing their delivery time, total effort, quality, and observed results.
People set the sources, goals, ownership, tools, review requirements, and permitted autonomy for each task. Both development paths pass through code and security review, behavior-change review, independent risk review, tests, CI checks, and preview QA before release approval.
People-initiated work
A ticket, thread, alert, or idea becomes a defined task.
Use repository context and connected tools. Prepare a reviewable pull request.
People provide goals, context, and judgment.
Signal-initiated work
Check evidence, relevance, duplication, and the next useful action.
Prepare the plan, implement the approved scope, and open a linked pull request.
A person approves scope, the plan, and the pull request.
A person approves.
↻ What production shows becomes the next signal.
Gather permitted records and observations. Retain the source, date, affected application, and uncertainty.
Check relevance, duplicates, and evidence. Prepare a task, a targeted question, or a finding that no change is needed.
Use a Claude Code session to prepare a plan and implement the approved scope. Keep the task, code changes, and pull request connected.
Review code, security, behavior changes, and risk. Run tests and CI checks, exercise the preview, and obtain the responsible person’s approval.
Merge after review, validate the release, and publish when approved. Investigate production evidence and trace it to relevant changes.
A passing build, an AI review, a human approval, and a verified production outcome are separate events. Preserve the evidence for each one. Production findings inform the next task; an agent’s proposed explanation remains open to investigation.
05 / An illustrative lab task
A user reports that an experimental application included an older drawing reference in its coordination summary. The report becomes a signal to investigate the document selection and source references.
An agent assembles the report, relevant requirements, source revisions, and code history. It prepares a proposed change and a regression test using the revised drawing input.
Following approval, Factory Droid implements the change. Reviewers inspect the behavior change, test results, and preview output. An authorized release is then checked against the reported problem.
The result informs the application’s document-handling rules and future tests. The software change does not authorize a construction design change or issue project direction.
06 / Evidence of value
We would compare representative tasks with similar scope and acceptance criteria, retaining the model, harness configuration, instructions, and tool versions used. Where practical, change one major variable at a time and examine the resulting differences.
Include failed attempts, review effort, and post-release corrections. Faster code generation is useful when it contributes to a better overall delivery result.
Factory documents connected tools, event- and schedule-triggered automations, and structured agent workflows. The review sequence and operating practices described on this page are ConTechLabs’ proposed experiment. Feature availability and connections must be checked during setup.