Paper deep dive
Vibe-Coding: Feedback-Based Automated Verification with no Human Code Inspection, a Feasibility Study
Michal Töpfer, František Plášil, Tomáš Bureš, Petr Hnětynka
Intelligence
Status: succeeded | Model: google/gemini-3.1-flash-lite-preview | Prompt: intel-v1 | Confidence: 95%
Last extracted: 4/18/2026, 1:39:54 AM
Summary
This paper investigates 'vibe-coding' for Collective Adaptive Systems (CAS), proposing a feedback-based automated verification method that eliminates the need for human code inspection. By utilizing a novel Functional Constraints Logic (FCL) to provide fine-grained, actionable feedback to an LLM, the authors demonstrate that this approach significantly improves the convergence of adaptation manager synthesis compared to coarse metric-based feedback.
Entities (4)
Relation Signals (2)
Vibe-Coding → appliedto → Collective Adaptive Systems
confidence 95% · This paper studies feedback-based automated verification of LLM-generated adaptation managers in Collective Adaptive Systems (CAS).
Functional Constraints Logic → providesfeedbackfor → LLM-generated code
confidence 95% · fine-grained constraint violations provide actionable feedback that typically yields a valid adaptation manager
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Vibe coding inherently assumes iterative refinement of LLM-generated code through feedback loops. While effective for conventional software tasks, its reliability in runtime-adaptive systems is unclear -- especially when generated code is not manually inspected. This paper studies feedback-based automated verification of LLM-generated adaptation managers in Collective Adaptive Systems (CAS). We focus on the key challenges of verification in the loop: how to detect failures of generated code at runtime and how to report them precisely enough for an LLM to fix them. We combine the adaptation loop with a vibe-coding feedback loop where correctness is checked against (i) generic architectural constraints and (ii) functional constraints formalized in Functional Constraints Logic (FCL), a novel first-order temporal logic over potentially finite traces. Conducting the Dragon Hunt CAS case study, we show that fine-grained constraint violations provide actionable feedback that typically yields a valid adaptation manager within a few iterations, while simple coarse metric-based feedback often stalls. Our findings suggest that feedback precision is the dominant factor for reliable vibe coding in systems designed by domain experts with no programming skills, thereby obviating the need for human code inspection.
Tags
Links
- Source: https://arxiv.org/abs/2604.14867v1
- Canonical: https://arxiv.org/abs/2604.14867v1
Trouble viewing inline? Open PDF directly →
Full Text
27,624 characters extracted from source content.
Expand or collapse full text
Vibe-Coding: Feedback-Based Automated Verification with no Human Code Inspection, a Feasibility Study Michal Töpfer Charles University Prague, Czech Republic michal.topfer@matfyz.cuni.cz František Plášil Charles University Prague, Czech Republic frantisek.plasil@matfyz.cuni.cz Tomáš Bureš Charles University Prague, Czech Republic tomas.bures@matfyz.cuni.cz Petr Hnětynka Charles University Prague, Czech Republic petr.hnetynka@matfyz.cuni.cz Abstract Vibe coding inherently assumes iterative refinement of LLM-gene- rated code through feedback loops. While effective for conven- tional software tasks, its reliability in runtime-adaptive systems is unclear—especially when generated code is not manually inspected. This paper studies feedback-based automated verification of LLM- generated adaptation managers in Collective Adaptive Systems (CAS). We focus on the key challenges of verification in the loop: how to detect failures of generated code at runtime and how to report them precisely enough for an LLM to fix them. We combine the adaptation loop with a vibe-coding feedback loop where correctness is checked against (i) generic architectural constraints and (i) functional constraints formalized in Functional Constraints Logic (FCL), a novel first-order temporal logic over potentially finite traces. Conducting the Dragon Hunt CAS case study, we show that fine-grained constraint violations provide ac- tionable feedback that typically yields a valid adaptation manager within a few iterations, while simple coarse metric-based feedback often stalls. Our findings suggest that feedback precision is the dominant factor for reliable vibe coding in systems designed by domain experts with no programming skills, thereby obviating the need for human code inspection. 1 INTRODUCTION 1.1 Motivation: vibe coding not involving programmers but domain experts Vibe coding has popularized the idea that developers can “steer” LLM-generated code by iteratively providing feedback, instead of reading and editing the code directly [5]. Discussions around vibe coding frequently assume at least light human inspection: Develop- ers read errors, skim diffs, and reason about fixes. In many practical settings, however, the person who specifies the task is a domain expert (e.g., game designer, city planner, building engineer) who cannot reliably inspect code. In that case, the feedback loop must be fully automated: it must (i) execute the generated artifact, (i) detect failures, and (i) generate failure reports that are understandable and actionable for the LLM. Collective Adaptive Systems (CAS) accentuate this challenge. Typically, CAS are complex systems where a large number of het- erogeneous agents adapt their behavior to their environment in pursuit of an individual or collective goal. They are controlled by adaptation manager, which modifies their settings, assigns them tasks, and organizes them into collaborative groups (also called en- sembles) based on a higher-level strategy reflecting the functional goal of each group. In CAS, correctness is not a purely local prop- erty of a function; it depends on agents’ multi-step interactions, dynamic grouping, and runtime architectural consistency [4,7,12]. Thus, a vibe-coded adaptation manager might compile, run, and still systematically fail because it assigns agents to inappropriate tasks and groups early on, violating the intended coordination strategy. 1.2 Setting, key challenge, research question, and contributions We study a vibe-coding scenario where: • An LLM generates an adaptation manager (AM) that re- solves groups of agents (ensembles) at each adaptation step. •The AM is not manually inspected; only feedback-loop refinement is allowed. •The domain expert can state desired behavior as constraints over agents and groups and provide a test set. The key challenge is verification of generated code. When the generated AM fails, the system must determine whether the failure is due to (i) a crash or interface mismatch, (i) an architectural invariant violation (e.g., invalid agent assignment into a group), or (i) functional misbehavior in a particular group. Furthermore, the system must report the failure in the feedback loop precisely enough that an LLM can repair it. Based on two feasibility studies 1 (one of them is described in Section 2), we focus on the following research question: RQ: How efficient is the method of combining the vibe coding feedback loop and the adaptation loop? Efficiency is operationalized as the number of feedback iterations required to obtain an AM that passes verification across a set of test executions. Our approach is based on the hypothesis that feedback granular- ity is decisive. We therefore compare three feedback-level variants: coarse domain metrics (baseline), system generic constraints, and fine-grained functional constraints violations. Overall, the key contributions include: 1 https://github.com/smartarch/llm-adaptation/tree/vibex 1 arXiv:2604.14867v1 [cs.SE] 16 Apr 2026 Michal Töpfer, František Plášil, Tomáš Bureš, and Petr Hnětynka (1)A combined adaptation+feedback architecture that turns runtime verification outcomes into repairable LLM feed- back. (2)Functional Constraints Logic (FCL), a novel first-order tem- poral logic that supports both infinite and finite traces with explicit trace boundary operators. (3) An empirical evaluation showing that functional constraint- level feedback improves convergence compared to domain metric-level feedback. 2 CASE STUDY 2.1 Dragon Hunt as a CAS We use the Dragon Hunt scenario, a fictional game crafted so that an LLM is unlikely to have been trained to its exact rules. A Dragon resides in a Cave near a Village. Villagers (agents) are farmers or warriors; they can: • Farm wheat in the Village; • Spawn new villagers (requires two villagers and sufficient wheat); • Move between Village and Cave; • Attack the Dragon (more effective for Warriors than Farm- ers). The Dragon retaliates stochastically, potentially damaging or killing villagers. The objective is to defeat the Dragon within 30 steps. The scenario is designed so that successful play requires coordinated multi-step strategy: early farming to build an economy, then travel to the cave, and then sustained attacks while managing risk. 2.2 Ensemble-based modeling and adaptation manager We model the Dragoon Hunt scenario as a CAS by using ensemble- based architecture concepts (similar to DEECo [1]). Agents become components—villagers and the dragon; groups of villagers associ- ated with a particular task correspond to ensembles such as Farm, Attack, GoToCave, SpawnFarmer, and SpawnWarrior. At each step, the AM reassigns components to ensembles—performs ensemble resolution: (1)by observing component attributes (role, location, health) and environment variables (wheat, dragon HP) (2)assigns each villager to exactly one ensemble, producing the “architecture” for that step; (3) applies ensemble effects to advance the system state. Ensemble resolution is a grouping problem and is NP-hard in gen- eral [6]. This motivates heuristic synthesis via LLMs and makes the case study a good stress test for vibe coding: local correctness is insufficient; success depends on coordinated sequencing. 3 VERIFICATION METHOD 3.1 Combining adaptation and feedback loops Figure 1 summarizes the key components of the verification method and their interplay. An AM is generated by an LLM given a prompt based on the domain description and architecture specification. The AM is executed inside the adaptation loop. The constraint verifier monitors test runs, and either approves the AM or produces a cumulative constraint-violation report. That report is appended Figure 1: Combining adaptation (red, I.- I.) and feedback (black, 1.-5.) loops. to the new version of the prompt, and the LLM is asked to revise the AM. 3.2 Prompt structure and feedback encoding To maximize reproducibility and reduce prompt drift, prompts are generated from a template. The template includes: •Interface contract: required AM functions and return format; •Domain rules: scenario description, state variables, avail- able actions/ensembles, effects; •Strategy intent: a natural-language description of the de- sired behavior in terms of ensemble resolution; • Constraints summary: optional list of functional con- straints in plain language. On failure, the constraint verifier returns a report encoded as a short list of bullet points, each containing the violated constraint and, optionally, the step window and the most relevant state excerpts. This is intended to mirror how developers communicate bugs: “what failed”, “when it failed”, and “what evidence supports it”. 3.3 Failure taxonomy in LLM-generated AMs In preliminary runs, failures clustered into recurring categories: Syntactic/interface failures include missing functions, wrong return types, invalid imports, or runtime exceptions. Architectural rules failures include assigning the same villager to multiple en- sembles, omitting villagers from any ensemble, or producing un- known ensemble names. Behavioral/strategy failures include, despite satisfying architectural rules, still losing because the AM delays attacking, mismanages wheat, or violates role/location dis- cipline. This taxonomy motivates layered constraint verification: generic constraints filter the first two categories, while functional constraints target the third. 2 Vibe-Coding: Feedback-Based Automated Verification with no Human Code Inspection, a Feasibility Study 3.4 Verification constraint layers and run coverage Verification is performed by executing multiple test runs from var- ied initial states and random seeds. A candidate AM is accepted only if it passes all checks across the suite of test runs. The testing is done for the following constraint layers: Generic constraints. Importability/executability (no exceptions), valid group/ensemble names, and exactly one group assignment per villager. These address common LLM failure modes such as missing imports, wrong return shapes, or inconsistent grouping. Functional constraints. Requirements expressed in the temporal logic FCL (Section 4). These address behavioral misalignment, such as wrong ordering of tasks, starving wheat production, sending farmers to fight, and delaying attacks. 4 FCL DESCRIPTION AND EXAMPLES OF THE CONSTRAINTS 4.1 Design goals and semantic intuition Functional Constraint Logic (FCL), introduced in [11], is designed for two goals: (i) expressiveness for bounded multi-step require- ments common in CAS strategies, and (i) producing diagnostic counterexamples that can be translated into LLM-friendly feedback. Compared to classical temporal logic LTL, FCL makes trace step counts explicit, which helps in generating informative feedback such as “attack happens 0 times in steps 1–15”rather than a generic “globally”, “sometimes in the future”, “next”, or “until” temporal determination available in LTL. An execution of a CAS under an AM yields a trace of system states and ensemble assignments in particular. FCL formulas are evaluated over this trace. For a given step푖, the windowed operator ♦ 푛 푡 휑counts how many steps in the interval[푖,푖+푡)satisfy휑(for푡> 0) and checks whether the count is at least푛. This explicit counting makes it straightforward to produce diagnostic counterexamples: if the count is below푛, the verifier can report the exact deficit and list steps where휑was false. For finite traces, MAX and BEG (Section 4.2) allow constraints to “shrink” windows near trace boundaries (e.g., “eventually before the end”), avoiding spurious failures when a run (actual trace) terminates early. 4.2 Core operators and finite traces The core temporal operator is♦ 푛 푡 휑, meaning that휑holds at least 푛times within a window of length푡from the current step. A dual “always” style constraint can be encoded by setting푛= 푡and past windows are supported by negative푡. To support finite traces, FCL includes special counters in the current step: • BEG: how many steps from the beginning of the trace; • MAX: how many steps remain to the end of the trace. This avoids ambiguous semantics near trace endings and enables constraints like “eventually before the end”. There is also the counter INF to support infinite traces. 4.3 Examples from Dragon Hunt Win condition. The Dragon is eventually dead: ∀푑 ∈ Dragons :♦ 1 푀퐴푋 (d.hp≤ 0) Attack early. The Dragon is attacked at least once within the first 15 steps: ♦ 1 15 (|Attack| ≥ 1) Farmers stay in village. ∀푓 ∈ 퐹푎푟푚푒푟푠 :♦ 푀퐴푋 푀퐴푋 (f .location= “Village ′ ) Go-to-cave implies eventual attack. (푣 ∈ GoToCave∧ 푀퐴푋> 0) ⇒♦ 1 푀퐴푋 (푣 ∈ Attack) Economy is not starved. A simple bounded constraint that en- forces repeated farming early (illustrative): ♦ 3 10 (|Farm| ≥ 1) While simplistic, such constraints are useful as scaffolding: they guide the LLM toward viable strategies, and can later be relaxed or refined. More examples and details on FCL can be found in [11]. 4.4 From counterexample to feedback For each violated formula, the constraint verifier constructs a coun- terexample consisting of the relevant step range, the valuations of referenced sets (e.g., Attack empty), and the smallest witness set (e.g., the specific villager violating a location constraint). This is then rendered as a concise textual report. The goal is not to prove properties exhaustively, but to provide a detailed feedback message that supports repair. 5 EXPERIMENT RESULTS AND VALIDATION 5.1 Settings and feedback-level variants We implemented a framework 2 that realizes all the conceptual com- ponents depicted in Figure 1 and allows us to control the verification process described in Section 3. Thus, it constructs the prompts and provides input to the LLM through its API, runs the system adapta- tion loop with constraint verification, and activates the feedback loop by presenting feedback to the LLM with a constraint violation report. For assessing the importance of granularity by which an error is reported in feedback, we have chosen to compare three feedback level variants (listed by refining the granularity of levels): (1)Metrics-only: just domain outcome metrics are reported (e.g., win/loss, remaining Dragon HP, steps survived). This means that no constraints from Section 3 are considered, so this feedback level serves as a baseline. (2)Generic-only: only generic constraint failures are reported; functional constraints failures are not explained. (3)Full constraint feedback: both generic and functional constraint violations are reported. This combination has been chosen since the satisfaction of generic constraints is a natural condition for desired functionality. Table 1 summarizes the three feedback level variants and the typical information available to the LLM for code repair. To illustrate the difference between metrics-only and full con- straint feedback consider a run that loses because villagers reach the cave but do not attack. Metrics-only feedback may only report “loss, Dragon HP=50”; the LLM must guess whether to spawn more warriors, change travel timing, or attack earlier. Full constraint feedback instead reports a specific violated obligation, e.g., “The 2 https://github.com/smartarch/llm-adaptation/tree/vibex 3 Michal Töpfer, František Plášil, Tomáš Bureš, and Petr Hnětynka Table 1: Compared feedback variants. VariantOracleReporting info (examples) Metricsoutcome score win/loss; remaining Dragon HP; steps survived; wheat at end Generic- only execution + arch. rules exception trace; “invalid ensemble name”; “component assigned twice” Fullcon- straint arch. rules + FCL violated formula; time window; wit- ness agents/sets, e.g., “No attack in steps 1–15” Dragon should be attacked at least once in the first 15 steps.” when ♦ 1 15 (|퐴푡푎푐푘| ≥ 1) is violated. 5.2 Main result: feedback precision improves convergence We measure the efficiency of the method by the number of feedback- loop iterations (convergence) needed to obtain an AM that passes verification over the run test suite. Based on a preliminary study 2 , a maximum of 10 unsuccessful iterations is allowed before aborting. Figure 2 shows the distributions over 10 independent attempts to vibe-code an AM per feedback level variant 3 . The results show that full constraint feedback typically con- verges within a few iterations. Generic-only feedback is less effec- tive because many AMs fail functionally but provide no repairable signal. Metrics-only feedback often stalls: it indicates failure but does not specify which part of the multi-step strategy is broken. This supports the paper’s central claim that diagnostic specificity is necessary for vibe coding of CAS featuring multi-step interactions. With full constraint feedback, same failed attempts are “one-bug” iterations: for instance, the AM may satisfy the economy constraints but delay travel to the cave, triggering an early attack violation. The subsequent repair often consists of adding an explicit threshold (e.g., “if wheat>X then send two warriors to cave”) or prioritizing GoToCave/Attack once the Dragon HP is non-trivial. On the other hand, multiple constraints are often violated simul- taneously, providing even more precise feedback: “Warrior John should attack the Dragon after moving to the Cave.” when the “Go-to-cave implies eventual attack” constraint is violated for a par- ticular villager. In our experience, this tends to elicit focused fixes (attack when in a cave) rather than broad, destabilizing changes. In contrast, metric-only feedback frequently leads the LLM to overfit to the metric without understanding the causal structure of the game, producing unstable oscillations such as spawning too many villagers (starving wheat) or sending all villagers to attack (collaps- ing the economy). To further assess robustness, we ensure that the accepted AMs pass across the whole test suite for multiple initial states and ran- dom seeds. Constraint-accepted AMs typically demonstrate con- sistent sequencing (farm early, then travel/attack) across different initial state mixes. This suggests that the constraint set acts as a strategy-shaped oracle rather than a single-point performance signal, which is especially important for stochastic domains. 3 The results in Figure 2 are for GPT 5 nano; furthermore, the results for GPT 5 mini are available at https://github.com/smartarch/llm-adaptation/tree/vibex 0 2 4 6 Count Metrics-only feedback with func. constr. in init. prompt w/o func. constr. in init. prompt 0 2 4 6 Count Generic-only constraints in feedback 123456789Aborted Number of feedback loop iterations to obtain a valid AM 0 2 4 6 Count Full constraint feedback (generic and functional) Figure 2: Distributions of feedback-loop iterations needed to obtain a valid AM in the Dragon Hunt example for different feedback variants. 5.3 Validation and interpretation A key concern is whether “passing constraints” corresponds to genuinely correct behavior. In our method, constraints are treated as the formalization of the intended strategy, and the test suite is designed to achieve high coverage over representative system states. In this sense, constraints act as executable requirements: they operationalize the domain expert’s intent. Nevertheless, we interpret the results as feasibility evidence rather than a definitive guarantee: the approach is only as good as the constraint set and run coverage. 6 DISCUSSION AND RELATED WORK 6.1 Relation to vibe coding feedback loops and formal verification for LLM-generated code Most vibe coding tooling focuses on compilation errors, unit tests, static analyzers, and even fuzzy testing [5,9]. These are highly effective for programs with local properties and clear oracles. Our setting differs: the oracle is temporal, multi-step, and architectural. We show that integrating runtime temporal constraints is a practical way to extend vibe coding beyond unit-test-centric tasks. There is growing interest in bringing formal methods to LLM outputs, including verification and runtime monitoring [2,13]. Our contribution is complementary: we target bounded temporal re- quirements and explicitly aim to produce repairable feedback, not only verdicts. From a workflow perspective, the verifier plays the role of an automated “reviewer” that points to specific violations. 4 Vibe-Coding: Feedback-Based Automated Verification with no Human Code Inspection, a Feasibility Study 6.2 Self-adaptation and collective systems context Our setting is motivated by a long line of work on self-adaptive systems [1,10]. In these systems, adaptation logic is traditionally en- gineered and validated using model-based or rule-based techniques. Recent surveys highlight growing interest in employing generative AI in self-adaptive systems [14]. Compared to approaches that em- bed ML components inside the runtime loop, our work focuses on using LLMs to synthesize the control logic itself and then validating it through repeated executions plus constraint monitoring. This aligns with calls for rigorous engineering of collective adaptive systems [3]. 6.3 Why temporal constraints fit vibe coding and implications for VibeX practitioners A recurring pattern in vibe coding studies is that improvements come from turning vague failures into precise, localized signals (e.g., failing unit tests, minimized repro cases [8]). In multi-agent and collective adaptive systems, the natural oracles are temporal and relational: the failure may be “nothing happens for too long” or “the wrong agents coordinate”. Windowed temporal constraints like those in FCL provide exactly this kind of localized signal: they identify when an obligation was missed and which agents or en- sembles are involved. This allows the LLM to remain in a narrow repair mode rather than triggering broad rewrites. For practitioners using vibe coding in domains with runtime interaction (games, simulations, robotics, distributed coordination), our results suggest two practical guidelines. First, invest in con- straint instrumentation early: even a small set of temporal con- straints can dramatically improve feedback quality compared to scalar metrics. Second, treat constraint sets as evolving artifacts: be- gin with strategy-shaped scaffolding constraints (e.g., “attack early”) and refine them as the loop stabilizes. This mirrors test-driven de- velopment but extends it to temporal requirements, bringing a “requirements-as-tests” mindset to vibe coding. 6.4 Future work and threats to validity Two directions appear particularly promising. First, constraints can be used not only for monitoring but also for guidance during generation: the prompt could include machine-readable constraint fragments or automatically derived intermediate goals. Second, the verification suite could be expanded from deterministic runs to statistical coverage, combining temporal constraints with random- ized scenario generation to systematically surface rare but harmful failures. Both directions aim to reduce the manual effort of “con- straint engineering” while increasing confidence in automated vibe coding. Construct validity: constraints may mis-specify intent. Internal validity: LLM and environment stochasticity; mitigated by repeti- tion and controlled seeds. External validity: Dragon Hunt is syn- thetic; larger CAS may require richer constraints and scalable exe- cution. Reliability: prompt sensitivity; template-based prompting reduces variability but does not eliminate it. 7 CONCLUSION We studied feedback-based automated verification for vibe-coded adaptation managers in CAS under a no-inspection assumption. By integrating runtime verification into the feedback loop and express- ing functional requirements as fine-grained temporal constraints in FCL, the feedback loop converges efficiently in most runs. Coarse metric feedback frequently stalls because it lacks a causal diagnostic signal. For VibeX, the key takeaway is that, for runtime-dependent adap- tive systems, the feedback structure matters more than the iteration count: temporal constraint violations transform refinement from trial-and-error into directed correction. Acknowledgment: This work was partially supported by the EU HORIZON-JU-Chips project NexTArc (EU grant agreement No. 101194287, Czech national funding Id 9A25008) and partially by Charles University institutional funding 260821. References [1] Tomas Bures, Ilias Gerostathopoulos, Petr Hnetynka, Jaroslav Keznikl, Michal Kit, and Frantisek Plasil. 2013. DEECo – an Ensemble-Based Component System. In Proc. of CBSE’13. ACM, 81–90. [2]Aaron Councilman, David Jiahao Fu, Aryan Gupta, Chengxiao Wang, David Grove, Yu-Xiong Wang, and Vikram Adve. 2025. Towards Formal Verification of LLM-Generated Code from Natural Language Prompts. arXiv:2507.13290 [cs.PL] https://arxiv.org/abs/2507.13290 [3]Rocco De Nicola, Stefan Jähnichen, and Martin Wirsing. 2020. Rigorous engi- neering of collective adaptive systems: special section. International Journal on Software Tools for Technology Transfer 22, 4 (2020), 389–397. doi:10.1007/s10009- 020-00565-0 [4]Nicola Del Giudice, Michele Loreti, Michela Quadrini, and Aniqa Rehman. 2025. Monitoring Local and Global Properties of Collective Adaptive Systems. In Leveraging Applications of Formal Methods, Verification and Validation. Rigorous Engineering of Collective Adaptive Systems. Springer, 281–296. [5] Yuyao Ge, Lingrui Mei, Zenghao Duan, Tianhao Li, Yujia Zheng, Yiwei Wang, Lexin Wang, Jiayu Yao, Tianyu Liu, Yujun Cai, Baolong Bi, Fangda Guo, Jiafeng Guo, Shenghua Liu, and Xueqi Cheng. 2025. A Survey of Vibe Coding with Large Language Models. arXiv:2510.12399 [cs.AI] https://arxiv.org/abs/2510.12399 [6] Mikhail Y. Kovalyov and Erwin Pesch. 2010. A generic approach to proving NP-hardness of partition type problems. Discrete Applied Mathematics 158, 17 (2010), 1908–1912. doi:10.1016/j.dam.2010.08.001 [7] Michele Loreti and Aniqa Rehman. [n. d.]. A Logical Framework for Reasoning About Local and Global Properties of Collective Systems. In Proc. of QEST 2022, Warsaw, Poland. doi:10.1007/978-3-031-16336-4_7 [8] Niels Mündler, Mark Niklas Müller, Jingxuan He, and Martin Vechev. 2025. SWT- Bench: Testing and Validating Real-World Bug-Fixes with Code Agents. arXiv preprint arXiv:2406.12952 (2025). [9] Ana Nunez, Nafis Tanveer Islam, Sumit Kumar Jha, and Peyman Najafirad. 2024. AutoSafeCoder: A Multi-Agent Framework for Securing LLM Code Generation through Static Analysis and Fuzz Testing. arXiv:2409.10737 [cs.SE] https://arxiv. org/abs/2409.10737 [10]Michal Töpfer, Tomáš Bureš, František Plášil, and Petr Hnětynka. 2025. On Limits of LLMs in Adaptation of Ensemble-Based Architectures. (2025). doi:10. 2139/ssrn.5357551 [11]Michal Töpfer, František Plášil, Tomáš Bureš, and Petr Hnětynka. 2026. Feedback- based Automated Verification in Vibe Coding of CAS Adaptation Built on Con- straint Logic. arXiv:2602.18607 [cs.AI] https://arxiv.org/abs/2602.18607 [12]Karthik Vaidhyanathan and Henry Muccini. 2026.Software Architecture in the Age of Agentic AI. In Software Architecture. ECSA 2025 Tracks and Work- shops. Springer Nature Switzerland, Cham, 41–49. [13]Yedi Zhang, Sun Yi Emma, Annabelle Lee Jia En, and Jin Song Dong. 2025. RvLLM: LLM Runtime Verification with Domain Knowledge. arXiv:2505.18585 [cs.AI] [14]Li Zhong and Zilong Wang. 2024. Can LLM Replace Stack Overflow? A Study on Robustness and Reliability of Large Language Model Code Generation. Proceed- ings of the AAAI Conference on Artificial Intelligence 38, 19 (2024), 21841–21849. doi:10.1609/aaai.v38i19.30185 5