NEXUS’s experience with unreachable screens exposes the gap between code that compiles and applications that work, as AI-generated software fails at the seams between components.
Woojune Chung’s experience at NEXUS highlights a problem that can be hidden by a successful build: software can compile cleanly and still be unusable. Working on ANT, the company’s open-source AI engineering platform, he found that some AI-generated applications passed verification checks but opened to blank screens when launched. In one internal evaluation, almost 15 finished screens could not be reached through the app’s navigation, because the routes linking them had never been created.
The issue was not that the individual coding tasks failed in isolation. Rather, the faults appeared where separately produced parts were supposed to connect. Chung told KoreaTechDesk that AI-generated work often satisfied the compiler by filling shared services with empty placeholder values, allowing the build to pass even though the application could not perform the intended action. In another case, conflicting instructions over route creation meant no task actually built the paths users needed.
Those failures point to a broader weakness in conventional software verification. Build checks, type checks and unit-style validation can confirm that code is structurally acceptable, but they do not guarantee that components interact correctly once the product is assembled. The International Software Testing Qualifications Board’s Foundation Level syllabus distinguishes between component testing, integration testing, system testing and acceptance testing precisely because each level exposes different kinds of risk.
Chung described the junctions between pieces of code as “seams”, meaning the places where routes, APIs, injected services, styling references and backend dependencies must all line up. Those seams are where AI-generated applications are most likely to fail, because one part may compile correctly while depending on another part that is absent, misconfigured or never connected. A build can therefore validate each fragment without proving that the full user journey works.
In response, ANT changed how it assigns work and verifies results. The system now gives one task responsibility for establishing shared application services before other tasks rely on them, and it bars empty stand-ins that exist only to satisfy type rules. It then runs a separate integration step that checks whether navigation links, APIs, dependencies and styling references reach valid destinations, and whether buttons trigger functioning actions.
Chung also added render smoke tests after seeing code that compiled successfully but still produced a blank interface. Those tests exercise the application itself rather than only the code path leading to compilation, adding a behavioural check that can reveal failures ordinary verification misses. He said that if such a test fails, the agent must repair the product code rather than weaken or remove the test.
The problem becomes harder when AI systems generate both the application and the tests that are supposed to evaluate it. A July 2026 paper, “On the Risk of Coding Before Testing: An Empirical Study on LLM-Based Test Generation Workflow”, found that tests produced after exposure to faulty code detected about 14% of faults in the researchers’ experimental setting, compared with 25% when tests were generated independently. The study suggested that generated tests can absorb the same mistaken assumptions as the code they are meant to challenge.
Industry data points in the same direction. Applause’s September 2026 State of Digital Quality in Functional Testing report found that 65.1% of respondents used AI to create test cases, while 48.4% used it to identify and close gaps in test coverage. That distinction matters: creating more tests does not necessarily mean the tests are probing the right behaviour, especially if they never check whether users can move through the product as intended.
The challenge is not confined to one platform. Korean testing company ONYCOM, according to an October 12, 2026 report by Electronic Times, is developing its [ai]Q platform to support test design, execution and results analysis. The company says it combines AI-assisted testing with expert review to catch missing verification requirements and business-rule inconsistencies, and it reported that test-design work fell by about half in a financial-sector proof of concept. That kind of efficiency may help teams move faster, but it does not remove the need to prove that applications behave correctly in real conditions.
Chung said another limitation remains unresolved: many applications depend on live authentication systems, external APIs and specific session states, while development tests often rely on mocks. An integration that works against a simulated service may still fail against the real one. ANT’s maturity documentation reflects that constraint, with its core planning, design and coding workflows marked stable, while service connections and virtualisation remain in beta and the overall project is described as pre-alpha. For truly production-ready software, he argued, engineers still need to reproduce operating conditions and inspect the behaviour directly.
That is the practical lesson for founders and investors evaluating AI coding tools. A platform that can generate working components is not necessarily proving that the product is complete. What matters is whether its verification process checks navigation, shared services, external integrations and user journeys under realistic conditions. Chung’s unreachable screens show how easily a project can appear finished while remaining incomplete in ways only real integration testing will expose.
Disclaimer: This content is intended for informational purposes only. Readers are advised to exercise their own judgement, conduct due diligence, or consult a qualified expert before acting on any information provided.
