Pith. sign in

REVIEW 4 major objections 6 minor 39 references

What You See Is What It Does: A Structural Pattern for Legible Software

T0 review · 4 major / 6 minor · reviewed 2026-08-05 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read This paper proposes a structural pattern—independent concepts coordinated by granular, event-based synchronizations—that makes software behavior legible and lets large language models generate and modify web application backends.

desk verdict A promising structural pattern for LLM-friendly modularity, with a real case study; but the load-bearing composition guarantees are asserted rather than shown, and the LLM evaluation is partly self-referential. read the letter →

arxiv 2508.14511 v2 pith:54KLPIVK submitted 2025-08-20 cs.SE

Eagon Meng , Daniel Jackson This is my paper · ORCID
classification cs.SE
keywords softwarearchitecturemodularitylegibilityevent-basedsynchronizationconceptdesignLLMcodegenerationwebapplicationbackendprovenance
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper is trying to establish that the main obstacle to reliable LLM-assisted coding is not the model but the shape of the code: when modules do not correspond to user-visible behavior, small changes require editing many places and previous behavior gets broken. It proposes a structural pattern in which a backend is decomposed into concepts—fully independent services with their own state and actions—and synchronizations, small event-based rules that connect actions across concepts. This makes behavior a local, declarative artifact: adding a feature means adding or replacing one rule, and the engine automatically records every action with causal provenance. The authors claim this 'what you see is what it does' structure delivers incrementality, integrity, and transparency, and they support it with a RealWorld blog-app case study where the concept specs and code were generated by an LLM and the synchronizations were generated with iterative prompting.

What carries the argument

The central mechanism is the synchronization engine, a reactive database that stores every action invocation and completion as data, matches completion records against declarative when/where/then rules, scopes each cascade of actions with a shared flow token, and writes provenance edges labeled by the synchronization that fired. Concepts are the other half: services with their own state, no getters, and no references to other concepts' schema; state is exposed to synchronizations only through named queries. The where clause of a rule is evaluated as a function from one binding to a set of bindings, which is what lets a single rule say 'delete every comment whose target is this post' without

What would settle it

Construct two concepts, A and B, and one synchronization that fires on an A action and invokes a B action whose local preconditions are violated by the current interleaving; if the combined system can reach a state that no single concept's specification permits, the paper's preservation claim is false. An empirical counterpart is adding such a synchronization deliberately to the RealWorld app and observing a state or action sequence outside every concept's traces.

Watch

Extended reading notes

Core claim

The paper claims that software legibility and modularity can be achieved by a stricter separation than usual: concepts are independent services whose actions never call or inspect one another, and all data and control flow between them lives in synchronizations, event-driven rules of the form 'when these action completions occur, under these state conditions, invoke these actions.' The incoming HTTP request is itself an action of a bootstrap concept, so the same rule mechanism handles request handling, authentication, error handling, cascading effects, and response packaging. Because system traces are interleavings of concept traces, local concept properties are supposed to be preserved, whi

Load-bearing premise

The load-bearing premise is that synchronizations only combine actions that each concept already allows on its own, so the whole system's behavior is just the sum of the concepts' behaviors; if a rule can force an action into circumstances its concept was not designed for, the modularity story collapses.

Editorial extensions

If this is right

  • New features become new rules: a behavior is added, deleted, or edited by adding, deleting, or replacing one synchronization, leaving concept services untouched.
  • LLM code generation can be decomposed into small independent contexts: concept specs and code are generated per concept from a one-line prompt, and synchronizations are generated from specs alone, which dramatically reduces what the model needs to know.
  • Runtime transparency is built in: the engine's action records with flow tokens let a developer debug by querying 'everything that happened in this request,' then jump to the exact synchronization responsible.
  • Cross-cutting policies—error handling, authorization, cascade deletes, notifications, response packaging—can be factored out of the services into granular rules, so the same concepts can be reused under different policies.
  • Because every state and action record can carry a version identifier, staging and production environments can share one storage layer cleanly, and records stay causally tied to the code version that produced them.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The provenance design implies a beyond-the-paper workflow: after a user reports an undesirable action, the system could automatically mark the whole flow, hand the responsible synchronizations to an LLM, fork the action graph, replay the original inputs against the proposed patch, and only then merge. The paper lists this as future instrumentation; it follows directly from the recorded provenance
  • The unit of reuse may eventually be rule-level 'synchronization patterns'—for example, cascade-delete, authorize-before-act, notify-on-event—rather than concepts alone: a catalog of policies that can be dropped onto any set of concept specs. The paper's future-prospects section speaks only of concept catalogs.
  • The case study suggests a sharper empirical test than the paper ran: hold concepts fixed, add a feature by editing only synchronizations, and count whether the existing Postman suite still passes. Such a test would isolate the pattern's incrementality claim from the LLM's luck.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. The paper proposes a structural pattern for organizing web-application backends around two elements: concepts—independent services with their own state, actions, and user-facing purpose—and synchronizations—declarative event-condition-action rules that mediate all data and control flow between concepts. It introduces a DSL for synchronizations, an architecture with flow tokens, provenance edges, and a bootstrap Web concept, and it reports a RealWorld case study in which both a hand-written and an LLM-generated backend pass the standard Postman suite. The paper argues that this structure yields legibility, modularity, incrementality, integrity, and transparency, and it includes a bug-fixing episode as evidence of the debugging benefits of provenance.

Significance. If the claims were established, the pattern would be a useful contribution to both modular web architecture and LLM-based code generation. The paper's concrete assets—a worked synchronization DSL, a running RealWorld implementation, a provenance mechanism, and a documented LLM generation workflow—are valuable and suggest a promising research direction. However, the central advertised benefits are not yet supported by the evidence: the composition argument in Section 2 is only a projection argument, the evaluation is explicitly non-systematic (Section 7.2), one part of the LLM evaluation is self-referential (Section 7.3), and the paper itself reports a legibility drawback of extreme granularity (Section 7.3). The paper does not provide machine-checked proofs, a formal semantics for synchronizations, or a comparative evaluation against conventional RealWorld implementations. The result is a credible design study whose strong claims need either additional verification or deliberate moderation.

major comments (4)
  1. [Section 2] The claim that composing concepts preserves their properties 'by definition' is only a projection argument: every system trace projects to valid traces of the component concepts. It does not establish the paper's central incrementality and integrity claims—that adding or modifying a synchronization never breaks existing behavior. A new synchronization can fire on an existing action completion and invoke an action that fails, or interact with other rules to change the outcome of a previously successful flow. Sections 3 and 6 give no confluence, termination, or non-interference theorem for sets of synchronizations; Section 6.6 addresses idempotency and recovery, not semantic preservation. Given that incrementality and integrity are core advertised benefits (Section 1), this is load-bearing. I ask for a formal semantics with preservation theorems, or a systematic verification/analysis of th
  2. [Section 7.3] The LLM synchronization generation used '(an earlier version) of Section 5 as the system prompt.' This makes the generation experiment partially self-referential: the model was given the paper's own exposition of the DSL before producing synchronizations. The success therefore demonstrates that the tutorial is usable as a prompt, but it does not provide an independent test of whether the structural pattern is naturally learned or used by LLMs, nor does it rule out that the generated code is aligned to the paper's own DSL by construction. Please rerun at least a subset of the generation without the Section 5 prompt (or with a neutral, independently written DSL reference), report the differences, and state the limitation explicitly if this is not done.
  3. [Sections 7.2 and 7.3] The paper explicitly states 'We have yet to conduct a systematic comparison of the existing benchmark implementations with ours' (Section 7.2) and concedes that 'the extreme granularity of synchronizations... made it harder to understand the full context of a series of actions at a glance' (Section 7.3). These admissions undercut the general 'improved legibility and modularity' claim in the abstract. The current evidence is one hand-built backend, one LLM-generated backend that passes the Postman suite, and one bug-fix anecdote (Section 7.4). To support the claimed improvement, I recommend a small comparative study with measurable criteria: change localization (files or synchronizations touched per feature), context size needed by an LLM, time to locate a defect, or number of broken tests after a feature addition, compared against at least one conventional RealWorld implementation. Witho
  4. [Sections 3 and 6] The operational semantics of synchronizations is left informal. The paper explains examples intuitively but does not specify what happens when several synchronizations match the same action completion, whether rule evaluation is sequential or parallel, how the flow token interacts with concurrently interleaved requests, or what guarantee replaces the transactional semantics explicitly removed in Section 3. The provenance-edge mechanism in Section 6.6 prevents duplicate invocations of a single rule, but it does not define global properties of a synchronization set. This matters because integrity claims depend on the execution model. I recommend adding a precise semantics (or at least well-formedness conditions such as acyclicity and disjoint firing patterns) and verifying that the RealWorld synchronization set satisfies them.
minor comments (6)
  1. [Section 7.4] The text refers to 'the user registration flow presented in Section 7,' but the registration flow is introduced in Section 5.1 and revisited in Section 7.1; the cross-reference should be corrected.
  2. [Section 4] The 'operational principle' and 'archetypal scenario' are mentioned but never defined or exemplified; a short concrete example would help readers understand what role they play in concept specifications.
  3. [Section 6.4] The claim that reads and writes are 'strictly separated' is immediately qualified by the use of federated SPARQL queries into concept states. Consider clarifying what 'strictly' means: actions are the only write path, but reads are open queries.
  4. [Throughout] The submitted text contains many replacement characters where concept names, keywords, and identifiers should appear (e.g., Sections 2, 4, 5, and Appendix B). If this is a font-embedding artifact in the PDF, please regenerate the submission; if not, the code listings and specifications are illegible as submitted.
  5. [Section 9] The statement that the authors 'have successfully prototyped' the persistent-storage factoring is unsupported in the paper; either provide details or mark it clearly as a future/ongoing experiment.
  6. [References] Several bibliographic entries, e.g., [24], contain garbled title or author fields. Please check the rendered references against the actual sources.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation: the paper is a design proposal with a transparent, externally anchored case study; self-citation and self-referential LLM prompting are acknowledged and do not constitute fitted predictions or definitional reductions.

full rationale

The paper does not claim a formal derivation from first principles; it proposes a structural pattern (concepts + synchronizations), specifies a DSL and engine, and evaluates via the RealWorld benchmark and the Postman test suite. Section 2's statement that concept properties 'are thus preserved by definition' under interleaving is an analytic consequence of the composition model, explicitly scoped to 'many (but not all)' system properties, so it is not a circular reduction. The main self-citation is to Jackson's book [22], which supplies the concept idea; the paper's own contribution (the synchronization language, flow scoping, provenance, and engine) is presented with independent examples and implementation details. The LLM-generation part of Section 7 is admittedly self-referential: 'To generate the synchronizations... we used (an earlier version) of Section 5 as the system prompt' (Section 7.3; see also Appendix C). This is transparent and tests the clarity of the paper's own documentation rather than an independent capability, but it is not a fitted parameter renamed as a prediction or an equivalence-by-construction; the generated code is checked against the external Postman suite. The paper also explicitly flags limitations—'We have yet to conduct a systematic comparison' (Section 7.2) and 'extreme granularity... made it harder to understand the full context' (Section 7.3)—which reduce evidentiary strength but are not circularity. No step in the paper's claimed derivation chain reduces to its own inputs by construction.

Assumptions & free parameters 0 free parameters · 3 assumptions · 3 invented entities

The paper introduces no numerical free parameters and no mathematical derivation. The load-bearing assumptions are about composition semantics, test-suite adequacy, and engine reliability, all of which are asserted rather than formally proven. The invented entities are software abstractions used in the implementation, with within-paper evidence of operation.

assumptions (3)
  • domain assumption Concepts are independent state machines, and composing them by interleaving their traces preserves each concept's local properties by definition.
    Invoked in Section 2 to justify that system-level properties can be localized within concepts; this is load-bearing for the modularity and integrity claims.
  • domain assumption The RealWorld Postman test suite is an adequate oracle for correctness of the backend.
    Section 7.1 uses passing the Postman suite as the measure of success, but the suite is documented as minimal and the authors supplemented it with ad hoc tests.
  • domain assumption The synchronization engine can provide atomicity and idempotency through provenance edges without transactional semantics.
    Section 6.6 relies on durably recorded synchronization edges to prevent duplicate invocations, but the failure-recovery behavior is not formally verified.
invented entities (3)
  • Bootstrap concept (Web concept) independent evidence
    purpose: Models external HTTP requests as root actions so synchronizations can react to the user as an entry point.
    Used in the case study implementation (Section 6.7, Appendix A), so it has operational evidence within the paper.
  • Flow token independent evidence
    purpose: Scopes causally related actions to a single request, replacing explicit route handlers.
    Implemented and used in the case study, and exploited in the bug-fixing example (Section 7.4).
  • Synchronization provenance edge independent evidence
    purpose: Durably records which synchronization fired from which action completion, enabling idempotent replay and debugging.
    Described in Appendix A.3.2 and used in the debugging workflow.

how reviews work

0 comments
Cite this review

Pith. "Pith review of What You See Is What It Does: A Structural Pattern for Legible Software." pith.science (2026). https://pith.science/paper/54KLPIVK

@misc{pith2026250814511,
  author       = {Pith},
  title        = {Pith review of: What You See Is What It Does: A Structural Pattern for Legible Software},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/54KLPIVK}},
  note         = {Machine review of arXiv:2508.14511}
}
read the original abstract

The opportunities offered by LLM coders (and their current limitations) demand a reevaluation of how software is structured. Software today is often "illegible" - lacking a direct correspondence between code and observed behavior - and insufficiently modular, leading to a failure of three key requirements of robust coding: incrementality (the ability to deliver small increments by making localized changes), integrity (avoiding breaking prior increments) and transparency (making clear what has changed at build time, and what actions have happened at runtime). A new structural pattern offers improved legibility and modularity. Its elements are concepts and synchronizations: fully independent services and event-based rules that mediate between them. A domain-specific language for synchronizations allows behavioral features to be expressed in a granular and declarative way (and thus readily generated by an LLM). A case study of the RealWorld benchmark is used to illustrate and evaluate the approach.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

39 extracted references · 32 canonical work pages

  1. [1]

    Ainsworth, A

    M. Ainsworth, A. H. Cktumcsmmm, L. J. Groves, and P. J. L. Wallis. 1994. Viewpoint Specification and Z. ����������� ��� �������� ���������� 36, 1 (1994), 43–51. doi:10.1016/0950-5849(94)90007-8

    doi:10.1016/0950-5849(94)90007-8 1994

  2. [2]

    Reem Aleithan, Haoran Xue, Mohammad Mahdi Mohajer, Elijah Nnorom, Gias Uddin, and Song Wang. 2024. SWE-Bench+: En- hanced Coding Benchmark for LLMs. doi:10.48550/arXiv.2410.06992 arXiv:2410.06992 [cs.SE]

    arXiv doi:10.48550/arxiv.2410.06992 2024

  3. [3]

    Carliss Baldwin and Kim B. Clark. 2000. ������ ������ ���� �� ��� ����� �� ����������. MIT Press. doi: 10.7551/mitpress/2366.001.0001

    work page doi:10.7551/mitpress/2366.001.0001 2000

  4. [4]

    David Beckett, Tim Berners-Lee, Eric Prud’hommeaux, and Gavin Carothers. 2014. ��� ��� ������� ����� ��� ������ ��������. W3C Recommendation. World Wide Web Consortium (W3C). https://www. w3.org/TR/turtle/

    work page 2014

  5. [5]

    Tim Berners-Lee. 2006. Linked Data. Design Issues, W3C. https: //www.w3.org/DesignIssues/LinkedData.html Updated 2009

    work page 2006

  6. [6]

    Tim Berners-Lee, James Hendler, and Ora Lassila. 2001. The Seman- tic Web. ��������� ��������284, 5 (May 2001), 34–43. doi: 10.1038/ scientificamerican0501-34

    work page 2001

  7. [7]

    Richard Cyganiak, David Wood, and Markus Lanthaler. 2014. ��� ��� �������� ��� �������� ������. W3C Recommendation. World Wide Web Consortium (W3C). https://www.w3.org/TR/rdf11-concepts/

    work page 2014

  8. [8]

    Derrick, H

    J. Derrick, H. Bowman, and M. Stetsen. 1995. Maintaining cross- viewpoint consistency using Z. In���� ������������� ���������� �� ���� ����������� ����������. Chapman and Hall, 395–406. doi:10.1007/978- 0-387-34882-7_32

    doi:10.1007/978- 1995

Show all 39 references
  1. [9]

    Dijkstra

    Edsger W. Dijkstra. 1974. On the role of scientific thought (EWD 447). http://www.cs.utexas.edu/users/EWD/ewd04xx/EWD447.PDF

    1974

  2. [10]

    Eppinger and Tyson R

    Steven D. Eppinger and Tyson R. Browning. 2012. ������ ��������� ������ ������� ��� ������������. MIT Press. doi: 10.7551/mitpress/ 8896.001.0001

    2012 doi

  3. [11]

    Eric Evans. 2003. ������������� ������� �������� ���������� �� ��� ����� �� ��������. Addison-Wesley

    2003

  4. [12]

    Finkelstein, J

    A. Finkelstein, J. Kramer, B. Nuseibeh, L. Finkelstein, and M. Goedicke

  5. [13]

    Martin Fowler. [n. d.]. Microservices. https://martinfowler.com/ articles/microservices.html. Accessed: 2025-04-24

    2025

  6. [14]

    Gothinkster. 2023. RealWorld: The mother of all demo apps. https: //github.com/gothinkster/realworld. Accessed: 2025-04-24

    2023

  7. [15]

    GraphQL Foundation. 2021. GraphQL Specification. GraphQL Spec- ification. https://spec.graphql.org/October2021/ Version: October 2021

    2021

  8. [16]

    Steve Harris and Andy Seaborne. 2013. ������ ��� ����� ��������. W3C Recommendation. World Wide Web Consortium (W3C). https: //www.w3.org/TR/sparql11-query/

    2013

  9. [17]

    William Harrison and Harold Ossher. 1993. Subject-Oriented Program- ming (A Critique of Pure Objects). In ����������� �� ��� ���������� �� ��������������� ����������� �������� ���������� ��� ������������ ��������. doi:10.1145/165854.165932

    1993

  10. [18]

    Carl Hewitt. 2015. Actor Model of Computation: Scalable Robust Infor- mation Systems. doi:10.48550/arXiv.1008.1459 arXiv:1008.1459 [cs.PL]

    2015 doi arXiv

  11. [19]

    C.A.R. Hoare. 1985. ������������� ���������� ���������. Prentice Hall. http://www.usingcsp.com/cspbook.pdf

    1985

  12. [20]

    Daniel Jackson. 1995. Structuring Z Specifications with Views. ��� ������������ �� �������� ����������� ��� �����������(1995). doi:10. 1145/226241.226249 TOSEM

    1995

  13. [21]

    Daniel Jackson. 2006. �������� ������������� ������ ��������� ��� ��������. MIT Press

    2006

  14. [22]

    Daniel Jackson. 2021. ��� ������� �� ��������� ��� �������� ������ ��� ����� ������. Princeton University Press. doi: 10.2307/j.ctv1nj340p What You See Is What It Does: A Structural Pattern for Legible Software Onward! ’25, October 12–18, 2025, Singapore, Singapore

    2021 doi

  15. [23]

    Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan

    Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan. 2024. SWE-bench: Can Language Models Resolve Real-World GitHub Issues? doi:10.48550/arXiv.2310. 06770 arXiv:2310.06770 [cs.CL]

    2024 doi arXiv

  16. [24]

    Elizabeth Barnes Joel Becker, Nate Rush and David Rein. 2025. Measur- ing the Impact of Early-2025 AI on Experienced Open-Source Devel- oper Productivity. ����� ��������(2025). doi:10.48550/arXiv.2507.09089 arXiv:2507.09089 [cs.SE]

    2025 doi arXiv

  17. [25]

    Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Videira Lopes, Jean-Marc Loingtier, and John Irwin. 1997. Aspect-Oriented Programming. In ����������� �� ��� �������� ���� ������� �� ��������������� ����������� �������. doi: 10.1007/ BFb0053381

    1997

  18. [26]

    David Parnas. 1972. On the criteria to be used in decomposing systems into modules. ������� ��� 15, 12 (1972), 1053–1058. doi:10.1145/ 361598.361623

    1972

  19. [27]

    David Parnas. 1979. Designing Software for Ease of Extension and Contraction. ���� ������������ �� �������� �����������SE-5, 2 (April 1979), 128–138. doi:10.1109/TSE.1979.234169

    1979

  20. [28]

    Michel Rauch and Immer.js contributors. 2023. Immer: Create the next immutable state by mutating the current one. https://github.com/ immerjs/immer. Accessed: 2025-04-21

    2023

  21. [29]

    1996.������� ���� �������� ��� ����� �������� ����������� ������

    Trygve Reenskaug, Per Wold, and Odd Arild Lehne. 1996.������� ���� �������� ��� ����� �������� ����������� ������. Manning/Prentice Hall. doi:10.17632/8tj2d5gh7b.1

    1996 doi

  22. [30]

    W. P. Stevens, G. J. Myers, and L. L. Constantine. 1999. Structured Design. ��� ������� �������38, 2&3 (1999). doi:10.1147/sj.132.0115

    1999 doi

  23. [31]

    Kevin Sullivan and David Notkin. 1992. Reconciling environment integration and software evolution. ��� ������������ �� �������� ����������� ��� �����������1, 4 (July 1992), 229–286. doi: 10.1145/ 131736.131744

    1992

  24. [32]

    Ruben Taelman, Joachim Van Herwegen, Miel Vander Sande, and Ruben Verborgh. 2018. Comunica: a Modular SPARQL Query Engine for the Web. In ����������� �� ��� ���� ������������� �������� ��� ����������. doi:10.1007/978-3-030-00668-6_15

    2018 doi

  25. [33]

    Ruben Verborgh and RubenVerborgh/N3.js contributors. 2023. N3.js: Lightning fast, spec-compliant, streaming RDF for JavaScript. https: //github.com/rdfjs/N3.js. Accessed: 2025-04-24

    2023

  26. [34]

    Edward Yourdon and Larry Constantine. 1979. ���������� ������� ������������ �� � ���������� �� �������� ������� ��� ������� ������. Prentice Hall. A Further Implementation Details A.1 Actions as State At the heart of the architecture is the idea that a system is composed of no...

    1979

  27. [36]

    SPARQL query engine to perform queries. A.3 Computational Agents Concepts and synchronizations alike are represented uni- formly in our implementation by ������������� ������(sim- ilar to actors [ 18], but simpler in that they cannot spawn other agents or pass messages to one ...

    2025

  28. [37]

    Query the action graph (as above) for outstanding actions associated with the concept

  29. [38]

    Perform each action and compute the state changes to insert into the concept state graph

  30. [39]

    Insert the completion record with the output into the action graph. The behavior of a concept agent might even be thought of as a kind of reverse synchronization that goes from invoca- tion to completion, with�������� representing the arbitrary computational function of the ag...

    2025

  31. [1992]

    ������������� ������� �� �������� ��� ��������� ��� ��������� �����������2, 1 (1992), 31–57

    Viewpoints: A Framework for Integrating Multiple Perspec- tives in System Development. ������������� ������� �� �������� ��� ��������� ��� ��������� �����������2, 1 (1992), 31–57. doi:10.1142/ S0218194092000038

    1992

Pith tools

Reviewed August 5, 2026 · model on record in the stance chip above.