The shine is starting to wear off vibe coding. I know, because I’ve been there. One moment I’m in Cursor, impressed by what a large language model can produce. The next, I’m staring at the clock, realising I’ve lost hours because it couldn’t navigate the complexity of the codebase I’m working on - and I find myself back in PyCharm, questioning the value of the detour. One answer that’s emerging is "Spec-First Development". You don’t toss vague instructions at an AI and hope for magic. Instead, you craft the clearest, most rigorous specification you can - and let the agent build from that. Better still, treat specifications as code artefacts: versioned, under source control, and continually refined with compacted, curated context. For me, this isn’t a radical shift. I’ve long worked with test-driven development, where the unit test is the specification. And LLMs thrive on this. Unit tests aren’t just notes in prose; they’re executable specifications - formal, computable, and unforgiving in all the right ways. That’s the deeper lesson: when you hand a spec to an LLM, the more formalisation, the better. Natural language is fine, but structure wins. Code loves tests. Maths loves notation. Business, however, has no equivalent - no unit test for strategy documents, compliance rules, or process design. Enter ontologies and knowledge graphs. They give us a way to formalise business semantics, capturing domains in rigorous, computable detail. Paired with an LLM, they don’t just guide the generation - they also validate it. The future of agentic coding - and of LLMs in business more broadly - won’t be built on “vibes.” It will be driven by how well we can formalise intent: transforming ambiguity into something structured, testable, and executable. ⭕ Spec-kit: https://lnkd.in/dPZCgUeq ⭕ What is an Ontology: https://lnkd.in/ePS7ha8z ⭕ What is a Knowledge Graph: https://lnkd.in/e5ed_f8g
Roy Roebuck
1mo
Fully agree. As a Management Analyst for over 40 years, I never talk to a system or software developer unless I have end-to-end specifications, including a business, functional, process, and data model in-hand to start the project discussions. Then, I do a thorough Verification of the developers' understanding of the requirement. As they are progressing to completion, I seek routine validation that what they are developing is what I specified, or give me good reasoning to update the spec. This is what I do with the coding assistant GenAIs I've used. Here's an interim knowledge representation collection artifact generated from a local file using the #RGEM method. https://1drv.ms/x/c/25934fa5818b7671/EVNt3-cnnahEkVBaUrjrAnkB_SkZFfP5JTbcRymTiDObew
John Evans
1mo
And before you specify you map out the 'logical data model' - the 'Ontology' using 'Entity Relationship Diagramming.' SSADM got that bit right. It was an essential step then and it still is. Any so-called Systems Thinking approach that avoids it is just propaganda in disguise.
Biology teaches us that knowledge is the essence of life. In engineered systems, the representation and application of knowledge are fundamental to designing reliable, scalable, and efficient architectures. These systems must be capable of sensing information, transforming it into structured, expandable, and explainable knowledge, and delivering discernible insights that enable end-to-end visibility and control over both form and function of the system. See https://www.linkedin.com/posts/raomikkilineni_knowledge-as-the-elixir-of-life-part-ii-activity-7372274922976354304-QdY_?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAAoJP8BOz6d2X3jidvBxaF8yiLA7ajeVDo
Yep! Loose coupling of LLMs and Knowledge Graphs is the inevitable endgame for how AI will redefine both software development and usage. Fundamentally, the following artifacts will evolve from separate documents into a single doc, processed by an LLM with the aforementioned loose coupling: 1. Problem Description 2. Solution Specification 3. Implementation Plan 4. Actual Code 5. Test Suite 6. Usage Documentation Coincidentally, I went through this exact process earlier this week while creating an HTML-based Single Page Application (SPA) to exercise functionality exposed by the OpenLink AI Layer add-on to a live Virtuoso instance. I used Google Gemini 2.5 Pro as the LLM, and it successfully produced ~80% of the solution. I contributed the remaining ~20% to finesse certain subtleties (e.g., Markdown-to-JSON transformer and API key masking). The result? A playground SPA that enables the use of Markdown to create an AI Agent/Assistant loosely coupled with Data Spaces (databases, knowledge bases/graphs, filesystems, APIs). [1] Links: [1] https://www.linkedin.com/posts/kidehen_virtuosordbms-cdo-cdio-activity-7370960470771388416-lEN8 -- related post.
Here here. Have you tried Claude Code in PyCharm?
VIBE programming = too shallow, bypasses craft. Spec-driven AI = too rigid, risks waterfall revival. AI as assistant = right path, if it helps comprehension and feedback. AI as inspiration = even better path, if it pushes us to invent new interpretive, semiotic programming models.
Oliver Cronk
1mo
Feels like there is an intersection here between what you are talking about and the EDGY enterprise design language that describes the relationship and structure of organisations. Worth taking a look if you've not already seen it: https://enterprise.design/ Intersection Group Lisa Woodall Wolfgang Goebl
I would like to take it one step further: Ontology-driven vibe coding. Why bother having an LLM produce code for something you've specified already, when that specification is enough to have an app rendered realtime without code having to be generated. And that is already possible: https://www.linkedin.com/posts/bvanderraadt_vibecoding-nocode-ontology-activity-7370877555022905344-vGrp?utm_source=share&utm_medium=member_desktop&rcm=ACoAAABcM-gBDgVgMlUbZope8Y2WB94vKQ-DhPs
Himanshu Tiwari
1mo
Is there requirement traceability? Is each requirement mapped to a test case? It used to be that simple, but somewhere it got lost in the "faster, cheaper, and better" ask, while ignoring that you can only pick two of them.
President of the Intersection Group, EDGY Co-Author, Enterprise Design Coach
1moAnd finally you end up with a domain specific programming language again. We've been there for decades, Code generation is as old as industrial Software development. People don't know what they want and therefore are not good in verbalising what they need. LLMs won't help much.