{"id":134,"date":"2025-09-09T21:32:21","date_gmt":"2025-09-09T19:32:21","guid":{"rendered":"https:\/\/stefanescu.lu\/?p=134"},"modified":"2025-09-17T09:03:24","modified_gmt":"2025-09-17T07:03:24","slug":"learning-to-stop-worrying-and-love-the-vibe","status":"publish","type":"post","link":"https:\/\/stefanescu.lu\/?p=134","title":{"rendered":"Learning to Stop Worrying and Love the Vibe"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n
\n\n\n\n

The post is a reflection based on building obsidize<\/a>, I wrote more about it in:<\/p>\n\n\n\n

    \n
  1. Scratching the Vibe \u2013 How I Learned to Stop Worrying and Love the Vibe<\/a><\/li>\n\n\n\n
  2. Scratching the Vibe \u2013 The Itch<\/a><\/li>\n\n\n\n
  3. Scratching the Vibe \u2013 The Scratch<\/a><\/li>\n\n\n\n
  4. Scratching the Vibe \u2013 The Vibe<\/a><\/li>\n<\/ol>\n\n\n\n
    \n\n\n\n

    I\u2019ve been fascinated by computers\u2014and what they can be taught to do\u2014since my childhood in the \u201980s. It always seemed like with the right secret incantation you could open portals to new worlds, new possibilities; you could gain superpowers if only you knew how to conjure the magic.<\/p>\n\n\n\n

    I wanted this power, and I admired those who had it. It seemed a skill difficult to master, a skill arriving from the future, a skill the grown-ups around me struggled with\u2014which made it all the more desirable.<\/p>\n\n\n\n

    \n\n\n\n

    My first programming experiences came in the early 1990s on clones of the Z80<\/a>\/ZX Spectrum<\/a>. I used BASIC<\/a> to draw and animate simple geometric shapes, or later to write (well, copy) games published as text listings in the back of PC Report<\/a> magazine.<\/p>\n\n\n\n

    My high school diploma project (Assistant Programming Analyst) was a FoxPro<\/a> clone of Norton Commander<\/a>. My engineering diploma project was a C\/C++ disk defragmentation<\/a> application.<\/p>\n\n\n\n

    FoxPro, disk defragmentation, BASIC (not to mention Pascal, MFC, CORBA, and others): I watched each of these fade into obsolescence during my career. Yet in a way, the essence of programming didn\u2019t change. That first code I wrote 35 years ago\u2014reading input, initializing state, controlling flow, calling library functions\u2014that was programming. That was software. Until 2022.<\/p>\n\n\n\n

    \n\n\n\n

    By then, my understanding of what makes software successful had already shifted. While writing code remained the only way to \u201cteach your computer to do something,\u201d the viability of that \u201csomething\u201d\u2014its relevance, cost, and chance of survival\u2014was less about coding and more about capturing real business needs. It was about growing solutions that could evolve with a changing domain, team, or organization (or better yet, growing the right team to build the right solution<\/a>). I\u2019ve seen too many thousands of lines of clean, elegant code wasted by bad requirements, misaligned business goals, dysfunctional organizations, clueless management. In that world, being \u201ccode complete\u201d was just one small step.<\/p>\n\n\n\n

    Software engineering is about solving real problems with software, in the most cost-effective way possible.<\/strong> And in the projects I worked, the main problems were rarely the code itself. I found myself focusing more on process, specification, and communication.<\/p>\n\n\n\n

    And then \u201cteaching your computer to do something\u201d changed.<\/p>\n\n\n\n

    \n\n\n\n

    Andrej Karpathy coined the term \u201cvibe coding\u201d<\/a> to describe letting large language models drive implementation. He called it \u201cfully giving in to the vibes, embracing exponentials, and forgetting that the code even exists.\u201d In this style, the \u201cassistant\u201d is no longer just an assistant: it builds functionality, proposes architectures, suggests next features. The human supplies guidance, feedback, and high-level direction.<\/p>\n\n\n\n

    On obsidize<\/a>, I set out to lean on coding assistants as far as they could go. And they can go surprisingly far. By the end, although I spent many hours testing and debugging, I can\u2019t honestly say I\u2019ve read every line of code in the repository.<\/p>\n\n\n\n

    Of course, I ran black-box end-to-end tests\u2014the \u201cacceptance testing.\u201d I read and reworked the documentation the assistants generated. I zoomed in on specific namespaces when needed, wrote some code, requested features, made architectural decisions. I decided what to implement and when to stop. But I didn\u2019t read every line. I didn\u2019t write (or review) every test.<\/p>\n\n\n\n

    Does that make me just a responsible babysitter<\/a> for the code assistants? Was I just vibing, or was I doing proper \u201cAI-assisted engineering\u201d?<\/p>\n\n\n\n

    In human teams, you\u2019re not expected to read all the code either\u2014not in large projects. You trust your teammates, and that trust is reinforced with conventions, reviews, tests, demos, documentation. Code assistants are new, and the level of implicit trust they deserve is still being defined. But similar checks are emerging in the LLM world: multiple personas to review code from different angles (something Claude-Code already implements<\/a>), security reviews<\/a>, chained tasks, and structured implementation phases.<\/p>\n\n\n\n

    Using code assistants means you\u2019re not only writing code\u2014but you\u2019re not a pure product owner either. Oversight is tighter. You manage direction, but you must also stay close to the code, watch the repo carefully (ready to revert an agent\u2019s mess), validate changes. And unlike with humans, you must be willing to discard huge amounts of work\u2014hundreds of lines, entire modules. Code is cheap now. Agents don\u2019t take ownership of their mistakes. You can\u2019t let sloppy code slip by hoping someone else will fix it later. It\u2019s better to throw it away, redefine the task, and go again. The agent won\u2019t be offended.<\/p>\n\n\n\n

    That raises another question: if code is cheap, if agents write most of it, does the choice of programming language matter? I think it does. You still need to read it, debug it, play with it when the AI stalls in its stochastic echo chamber. Languages that are well-designed, consistent, and concise may gain an edge. Clojure, for example, is known for brevity (good for context windows and tokens), functional purity, and explicit state handling. And with the Clojure-MCP server<\/a>, Claude can interact directly with a live REPL\u2014iterating like an experienced developer.<\/p>\n\n\n\n

    \n\n\n\n

    Are coding assistants silver bullets for software development?<\/strong><\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    It depends on the monster you\u2019re trying to slay.<\/p>\n\n\n\n

    If you need to churn code faster, or tackle technologies outside your core competence, then yes: they help. I had never finished a production-ready personal project before. I always got stuck on deployment and packaging, lost interest when forced to learn some necessary but boring technology. With AI teammates, I got further than ever.<\/p>\n\n\n\n

    For companies that see software as a manufacturing task\u2014cranking out features and polishing wheels\u2014assistants will boost productivity. More stuff will be built.<\/p>\n\n\n\n

    For companies in novel domains, where constraints come from the business environment, assistants can accelerate iteration, get you to working prototypes, let you test hypotheses quickly. Not a silver bullet, but a powerful tool.<\/p>\n\n\n\n

    \n\n\n\n

    In the late \u201990s, Eric S. Raymond experimented with a then-new paradigm<\/a>: the Linux model, open source, massively collaborative, free. That movement powered the cloud and SaaS revolutions. At the time, critics worried free software would kill developer jobs, handing value to corporations. And maybe it did: those $8.8 trillion in open-source software<\/a> didn\u2019t land in contributors\u2019 pockets, but they did lower corporate costs. At the same time, free software spawned countless small companies that didn\u2019t need to reinvent the wheel.<\/p>\n\n\n\n

    Did open source create opportunities for software engineers, or take them away? In the early 2000s, you were still expected to implement your own circular buffers, even your own network stack. Today, most software development is an integration exercise of open-source standards. Writing from scratch is a \u201ccode smell.\u201d The building blocks changed.<\/p>\n\n\n\n

    Now the granularity shifts again. Coding assistants\u2014trained on hundreds of millions of open-source lines\u2014are the new layer of abstraction. They integrate the standard industry tools for you, ready to use.<\/p>\n\n\n\n

    Fed by free and open-source software, we are approaching an uncanny version of Richard Stallman\u2019s vision<\/a>: software nearly free as in beer, but not free as in freedom. Everyone can create software. Few get paid for it. The agribusiness of code, controlled by a handful of AI companies.<\/p>\n\n\n\n

    Some see this as the end of the software engineer. I don\u2019t. Those critics have always underestimated what engineering really is. Software engineering has always been about more than code. And maybe, now that code itself is less central, the other parts of the craft\u2014problem framing, communication, iteration, validation\u2014will finally get their due.<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n
    \n\n\n\n

    <\/p>\n","protected":false},"excerpt":{"rendered":"

    The post is a reflection based on building obsidize, I wrote more about it in: I\u2019ve been fascinated by computers\u2014and what they can be taught to do\u2014since my childhood in the \u201980s. It always seemed like with the right secret … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-134","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/stefanescu.lu\/index.php?rest_route=\/wp\/v2\/posts\/134","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/stefanescu.lu\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/stefanescu.lu\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/stefanescu.lu\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/stefanescu.lu\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=134"}],"version-history":[{"count":8,"href":"https:\/\/stefanescu.lu\/index.php?rest_route=\/wp\/v2\/posts\/134\/revisions"}],"predecessor-version":[{"id":191,"href":"https:\/\/stefanescu.lu\/index.php?rest_route=\/wp\/v2\/posts\/134\/revisions\/191"}],"wp:attachment":[{"href":"https:\/\/stefanescu.lu\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=134"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/stefanescu.lu\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=134"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/stefanescu.lu\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=134"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}