{"slug": "a-picture-can-only-fail-a-vibe-check", "title": "A Picture Can Only Fail a Vibe Check", "summary": "Sven Reinck published a piece in JAVAPRO arguing that AI does not lower software costs but shifts them, making writing cheaper while understanding code becomes more valuable. Reinck proposed an interactive dependency visualization tool that generates continuous diagrams from class files, allowing developers to explore codebases spatially and refactor based on visual noise rather than rules. The approach faces scrutiny because visual complexity does not reliably measure architectural problems, while existing package metrics and cyclic dependency detection provide objective, build-failing measurements that pictures cannot match.", "body_md": "Sven Reinck published a piece in JAVAPRO this week called \"[Beyond UML: Clean Software Architecture in the Age of AI-Generated Code](https://javapro.io/2026/06/10/beyond-uml-clean-software-architecture-in-the-age-of-ai%E2%80%91generated-code/),\" and it gets a relatively common observation right out of the gate: AI does not lower the cost of software. It changes the cost centers; writing gets cheaper, and the understanding gets more valuable, because it comes from not only the code but the environment the code exists in. The work that used to happen on the side, in code reviews and pairing sessions and hallway arguments about structure, ends up becoming its own line item in a well-functioning environment.\n\nReinck frames this through the [Jevons paradox](https://en.wikipedia.org/wiki/Jevons_paradox), the same rebound effect that turned faster compilers into more complex mental models rather than shorter workdays. That framing is correct, and it deserves to be said as often as possible, because most of the discourse around AI coding is still arguing about whether the generated code is good instead of asking who understands it.\n\nThis is the source of much discussion in computing; it's why [Zig refuses AI contributions](https://bytecode.news/posts/2026/04/simon-willison-on-zig-s-anti-llm-policy) (those contributions ignore the human elements of understanding and propagation) and is probably a huge lever for why [Anthropic is migrating Bun to Rust](https://bytecode.news/posts/2026/06/bun-has-been-converted-to-rust-now-what), as an inversion of Zig's approach.\n\nWith that said, Reinck's answer to the understanding problem is a tool he says he has prototyped: an interactive dependency visualization, generated continuously from class files so it covers Java, Kotlin, and Groovy in one pass, with zoom, focus, and filter as the primitives for exploration.\n\nHis analogy is that a static UML diagram is a paper map while his tool is Google Maps. The diagram is never stale because it is never separate from the territory.\n\nHe reports two experiences with the prototype that sound valid: The first is that the codebase became spatial for him; he found himself thinking of a class as \"the one down in the lower right,\" and knowing its neighbors gave him context faster. The second is that he refactored code because the diagram looked noisy, not because a rule told him to. He calls this aesthetics rather than architecture, and he considers it a feature: the tool nudges toward clean structure without wagging a finger at him. A snarled graph, or even a *busy* graph, is an indicator.\n\nWhen code has a place, it has neighbors, and neighbors are context. Reinck has discovered, through tooling, something that some developers experience innately, and his enthusiasm for it is well placed.\n\nThe second observation wants more scrutiny, though, because it contains the seed of its own failures.\n\nA diagram that looks noisy is *expressing* complexity. It is not *measuring* it. Those are different things. Graph layout algorithms struggle with edge density, not with semantic wrongness; an event bus, a dependency injection container, or a well-used or common utility package will all produce ugly neighborhoods in a dependency graph while being entirely intentional. Meanwhile, a clean-looking graph can hide a layering violation that happens to lay out nicely. \"This feels wrong\" and \"this *is* wrong\" sometimes coincide, maybe even often, but Reinck is treating the coincidence as the measurement mechanism, even if it's in an incidental way.\n\nThe thing is: we already know how to measure what he wants to express. Bob Martin worked out [package metrics](https://en.wikipedia.org/wiki/Software_package_metrics) in the mid-nineties: afferent and efferent coupling, instability, abstractness, distance from the main sequence. Cyclic dependency detection is a solved graph problem. These are numbers, and numbers can fail a build. A picture can only fail a vibe check.\n\nAnd we have built the picture before, repeatedly. [Structure101](https://structure101.com/) gave the JVM world interactive dependency graphs and dependency structure matrices nearly two decades ago, won awards for it, and was eventually [acquired by Sonar](https://structure101.com/products/) and folded into a code quality platform. [Lattix](https://www.lattix.com/) built a business on the dependency structure matrix. [Sonargraph](https://www.hello2morrow.com/products/sonargraph) is still maintained and still measures exactly the structural erosion Reinck is worried about. [jQAssistant](https://jqassistant.org/) puts your entire codebase into a graph database and lets you query it. [ArchUnit](https://www.archunit.org/) skips the picture entirely and lets you write the architectural rule as a unit test that fails when someone violates it. Spring's [Modulith](https://spring.io/projects/spring-modulith) is yet another tool for asserting architectural isolation.\n\nThe category Reinck is working with is not new territory: it's an arena littered with ghosts, all asking \"remember me?\" with a few new players gently insisting that *this* time they'll get it right.\n\nThus: if always-in-sync interactive dependency visualization is the answer, why has it never stuck? UML did not fail because the diagrams went stale. Generated-from-source diagrams have existed for as long as IDEs have had a \"show dependencies\" menu item, and they did not change practice enough to change the industry. (That's why we keep doing things like asking \"What if we could just generate the graphs on the fly? We could put that into a product, and call it Together/J, and...\")\n\nThe medium was never the bottleneck. These tools died, or struggle for adoption, because people don't *use* them. They're not convenient enough, or their value proposition is too unclear: they may be great tools, they may be horribly *useful* tools, but an *incredibly useful* tool that gets hidden away in the back of a toolshed might as well not exist. People don't see the need themselves, or they don't see the *benefits* themselves, so the tooling *does not matter*.\n\nWhich is exactly where Reinck's piece has real promise, even though the article does not quite articulate it. AI changes the value propositions. If code arrives faster than mental models form, then \"what is connected to what\" stops being an onboarding question and becomes a daily one. The demand curve for architectural legibility shifts. The cost proposition changes; when understanding was based in human memory, the tooling struggled to add value, but when understanding is inferred from what code actually says, explicitly, the graph's *actual metrics* might provide greater correlative value. That is the strongest version of Reinck's argument, and it survives even if his particular prototype never ships.\n\nIt's impossible to say if the prototype Reinck refers to will actually shift the way we think about understanding code; it'd be great to see a better mousetrap, but mousetrap technology has changed remarkably little over the past few eons. (It has changed, but not much, from \"get a cat\" to some slightly more humane applications.) Yet it might be that with the tooling AI finally gives us, the metrics around measuring code complexity are *addressable*, and we can start making complexity something that *actually fails a build* at last... and at the very least, even if a build succeeds, we might consider the complexity something worth diving into and tracking.", "url": "https://wpnews.pro/news/a-picture-can-only-fail-a-vibe-check", "canonical_source": "https://bytecode.news/posts/2026/06/a-picture-can-only-fail-a-vibe-check", "published_at": "2026-06-10 11:19:06+00:00", "updated_at": "2026-06-11 18:40:27.362930+00:00", "lang": "en", "topics": ["artificial-intelligence", "generative-ai", "ai-tools", "ai-ethics"], "entities": ["Sven Reinck", "JAVAPRO", "Zig", "Anthropic", "Bun", "Rust"], "alternates": {"html": "https://wpnews.pro/news/a-picture-can-only-fail-a-vibe-check", "markdown": "https://wpnews.pro/news/a-picture-can-only-fail-a-vibe-check.md", "text": "https://wpnews.pro/news/a-picture-can-only-fail-a-vibe-check.txt", "jsonld": "https://wpnews.pro/news/a-picture-can-only-fail-a-vibe-check.jsonld"}}