TimeArch: why AI-built software needs a paper trail
A 2026 paper adds four steps and human sign-offs to AI software design. Then it tests itself.
vizmaya desk, 6 Nov 2026 · Paper: Waseem et al., ECSA 2026 (arXiv:2611.06921)
Same input. Run it twice. Two different scores.
That is what the authors of a tool built to make AI design trustworthy found when they tested it.
So why would anyone build it?
Source: paper p10. Diagram only. The paper says scores and risk levels varied. It does not print them.
Before the walls, there is a plan.
Software has one too. It is called the architecture.
It decides how the parts fit and which qualities matter most.
What happens when the code comes first?
Source: paper p2, sec 1.
AI jumps from a prompt straight to code.
The reasons behind the design stay vague, or sit outside the tool. The paper says the plan and the real system can drift apart over time. It calls that architectural erosion.
Who keeps the plan honest?
Source: paper p1 (abstract), p2 (sec 1). Diagram is ours.
The recipe is old. The AI part is new.
TimeArch builds on established architecture methods and standards (p3).
Of its 27 references, 13 are from 2023 or later. 7 are from 2011 or earlier.
So what does it add?
Source: paper pp15-16, reference list. Counts are computed by us from the list.
Split the job into four steps.
Each step produces something you can read. The next step starts from it.
Who checks each step?
Source: paper p3, Fig 1 (p4).
One agent makes. One checks. A person decides.
The human architect keeps the decision power. The agents assist.
What stops a weak step from moving on?
Source: paper p4, sec 2.1.
A step moves on only if four things are true.
What does the trail left behind look like?
Source: paper p4, sec 2.1. The same text lists these four conditions as the gate rule.
Every choice points back to a reason.
One check asks: does each design driver trace to at least one requirement?
Another asks: does each written decision cite at least one driver?
Does any of it work?
Source: paper p8, sec 3.4.
The test was small, and the builders ran it.
Cases: transport systems, IoT monitoring, and mobile apps. The project team did the judging.
It looked at 5 things. It ran 0 statistical tests.
So what did it find?
Source: paper p9 (sec 4), p12 (internal validity), p13 (qualitative, not statistical). "5 vs 0" is our comparison.
11 problems listed. 0 measured gains.
The authors report what broke in every phase. They report no numbers for time saved or errors caught.
Which problem matters most?
Source: paper pp10-11. The counts come from our grouping of the authors' prose. They do not number them. Contested as a count, clear as a pattern.
The judge gave two different verdicts.
In the validation step, repeat runs on the same input gave different quality scores and risk levels.
Some checks also spot missing pieces better than they judge whether a design is sound. The authors say stable scoring still needs work.
If the judge wobbles, who can you trust?
Source: paper p10 (validation and assurance). The authors' own findings.
Three questions for any AI that hands you a design.
Our reading, not the paper's The authors' lessons lean the same way: stage structure, review and approval gates help keep work consistent and traceable (p12).
Where does this tool still fall short?
Source: paper pp4, 8, 10, 12. The three questions are our interpretation.
This is early evidence, and the authors say so.
- No comparison against a skilled architect using a plain AI chat (p11).
- A few cases, in a controlled setting, not live company projects (pp12-13).
- Prompts may be seen by the AI model providers (p13).
- The claim that it can run the full lifecycle rests on a small test the team ran itself Contested (p11).
What came after? We did not look for replications or follow-ups.
Will a real company test it next?
Source: paper pp11-13, 15 (future work).
Credit and sources
Paper: "TimeArch: A Multi-Agent Approach for Software Architecture Design" by Muhammad Waseem, Mateen Abbasi, Viljami Järvinen, Petrus Lipsanen, Navneet Arora, Kalle Kulonen, Kalle Mäkelä, Tommi Mikkonen and Pekka Abrahamsson. Tampere University, University of Jyväskylä, Aimbition Oy. ECSA 2026 Industry Track, arXiv:2611.06921. Funded by Business Finland (project ANSE). Our gaps: we read the text of all 16 pages but did not open the demo or the authors' data package, and we did not look up citations. Yes, that is a hole in our homework.
- Waseem et al., TimeArch, arXiv:2611.06921v1 [cs.SE]. Pages cited as pN above.
- Authors' replication package: doi.org/10.5281/zenodo.20090303 (not opened by us).
- Photo, leaning tower: Paestum, Wikimedia Commons, CC BY 4.0.
- Drawing, art gallery front elevation, 1920: Lyme Art Association, Wikimedia Commons, public domain.
- Photo, postal savings book: Pocztowa Kasa Oszczędności, Wikimedia Commons, public domain.
- Computed by us: reference counts by year (pp15-16), problems by phase (pp10-11), "5 vs 0" (pp9, 13).
vizmaya desk, 6 Nov 2026.