{"slug": "i-don-t-vibe-code", "title": "I Don't Vibe Code", "summary": "The article, published on March 5, 2026, explains why the author personally does not use \"vibe coding\" with Large Language Models (LLMs). The author cites being a \"cheapskate\" who refuses to pay for AI tokens and being an experienced \"old\" developer who views the hype as reminiscent of past low-code trends. Ultimately, the author argues that while LLMs can be useful for simple tasks, they do not address the essential complexity of software development.", "body_md": "- March 05, 2026\n- A \"brief\" accounting of various reasons why vibe coding has just never clicked for me personally as a developer.\n\nThere has been a lot of discussion online lately about vibe coding and and how Large Language Models (LLMs) will revolutionize the field of software development. Every new model will launch us into realms of pure productivity, shipping software at the speed of thought and removing all the friction and overhead of product development. Or something like that.\n\nMaybe. I’ll have to take your word for it. I don’t vibe code.\n\nIf it’s working for you, great! I’m not really here to argue the merits or flaws of LLMs at depth here in this piece, but it’s just never clicked for me personally. This page is a “brief” accounting of various reasons why.\n\n## I’m a Cheapskate\n\nI’m not a purist. I’ve tried using LLMs that are integrated into an IDE. They\nhave been useful for some tasks that are simple enough to be easily describable\nbut annoying enough to not just do them myself. For instance, resizing [a grid\nof square images to be smaller](/projects/sky-gradients). I *could* go look at\nthe command-line arguments for ImageMagick, but that was a perfect thing to ask\nthe AI to do. I then tried using one of the AI tools to analyze my code in a\nproject and a few other small tasks before it all came to an awkward halt. The\nsystem informed me that I had just run out of credits and I would need to\nprovide a credit card to purchase more tokens I wanted to keep going.\n\nNow, you must understand that I come from a long line of cheapskates from both\nsides of my family tree. We’ve been pinching pennies and hunting bargains for\ncenturies both here and on the other side of the Atlantic. As an example, one of\nmy distant ancestors died during the [King Philip’s\nWar](https://en.wikipedia.org/wiki/King_Philip's_War) because he left the\nsafety of the fort to retrieve some cheese he had left behind when evacuating his\nhouse. So you must believe me that the idea of paying a service in perpetuity\nso I could *think* just seemed so laughably absurd and horrific that I didn’t\neven bother giving them my card. I closed the laptop. I uninstalled the IDE and went\nback to using [Emacs](https://en.wikipedia.org/wiki/Emacs) even. And I realized\nthat I just didn’t even notice the lack anymore.\n\n## I’m Old\n\nIt does help that I’m old. I’ve been writing code for a long time, especially in\nan industry that calls a developer with 5 years of experience a “senior\nengineer.” Experience is a welcome antidote to anxiety sometimes (*as long as\nit’s not anxiety about ageism in an industry that calls a developer senior with\nonly 5 years of experience*) , and the AI hype doee remind me of earlier\nbreakthroughs in low and no-code tooling. I don’t doubt that AI can be a useful\ntool for developers. I know there are tasks it can help with as better tooling.\nBut these arguments always leave me thinking about the accidental and essential\ncomplexity again.\n\n[Fred Brooks](https://en.wikipedia.org/wiki/Fred_Brooks) was old even when I was\na young coder myself. As the project manager for IBM’s System 360 line of\nmainframes (and accompanying operating system) he had a front row seat to when\nall the now common ways software projects go wrong were novel and new. He\ncollected these observations in a book * The Mythical\nMan-Month* which should\nstill be required reading for software engineering courses today. My edition was\na newer reprint that included a later essay titled “\n\n[No Silver Bullet](https://en.wikipedia.org/wiki/No_Silver_Bullet)” where Brooks looked at the effect that new tools can have on developer productivity. To think like a programmer, you must understand that the real world is complex. Programming can be best thought of as imposing simplified representations – we call them\n\n*_abstractions*– on top of our messy reality to make it understandable by reducing complexity. This lets us generalize specific situations into layers that can be built on top of each other. For instance the specific action of putting peanut butter onto a piece of bread could be generalized into a spread(substance) method that could take peanut butter or cream cheese as an argument. And we could use these spread methods to create higher-level functions like create_pbj() and so on. Coding in a modern high-level programming language is like standing on top of a ziggurat of abstractions, where a single line of code could trigger millions of operations on multiple systems. It’s very exciting!\n\nNow, what if we could keep going and abstract away the act of programming\nitself? This is the dream of agentic AI, where swarms of agents can be given\ntasks to implement on their own without supervision. Sounds great! But this is\naddressing what Brooks calls *accidental complexity*, the things that are\ncomplicated about writing code itself. In the time since the essay was written,\nsoftware development has made great strides against this type of complexity.\nInstead of writing in low-level machine code, we can use modern dynamically\ninterpreted languages which are compiled to assembly. Instead of remembering how\nto write a [quick sort](https://www.youtube.com/watch?v=ywWBy6J5gz8) (*trust me,\nyou’re going to want to click that link*) from scratch, I just need to call a\nsort method in a standard library. Instead of having to build a whole web\napplication from scratch, I can use an existing framework. If I want to rename\nor restructure some code, my editor can help do that for me. AI seems like the\nlatest iteration and some editors have already replaced their predictable old\ntooling for renaming and refactoring code with unpredictable AI agents. Sure, it\nmight seem like rolling the dice, but how common is a [critical\nfailure](https://rpgmuseum.fandom.com/wiki/Critical_failure) anyway?\n\nHowever, even as the better tooling has diminished accidental complexity,\n*essential complexity* still remains. There still is the complicated work of\ndesigning our abstractions and systems the right way, one that is elegant, clear\nand maintainable. And that complexity isn’t going anywhere. This type of work\ntakes skill and experience and wisdom hard-won from system failures past. And,\nI’m not sure if LLM’s fancy autocomplete approach works so well with this type\nof complexity, which often isn’t so straightforward to solve. Maybe with\nprompting, it could be guided toward a preferred approach, but at that point the\nperson doing the guiding might as well design the approach alone, since the LLM\nwouldn’t be able to articulate why it chose a certain path. Essential complexity\nis often weird and rare and messy. Maybe I’m wrong and the models are getting\nbetter at these kind of messy situations as well, but I’ve found that it often\nrequires a specific kind of mindset and approach. Luckily for me, I love the\nmessy stuff.\n\n## I Love Mess\n\nI’ve been talking so far about how software can abstract processes, but we also\nuse abstraction’s reductive properties as a tool to understand the world. In the\nclassic book * Seeing Like a\nState*,\nJames Scott describes how the motivating project of the post-enlightenment was\nto make their populations and possessions\n\n*legible*through abstraction and categorization. To measure is to modify. For instance, a country might begin to look at its forests not as complex ecosystems but just assessed by their percentages of timber that can be used for ship-building. This view then allows a country to act on this information in ways like replacing those forests with monocultures of just a single tree. A forest is abstracted into a system for growing ship masts.\n\nThis approach created the bureaucracy and the paper form, which has evolved into\nthe web form and database. As programmers, we need to reduce the messy data of\nthe world in order to act on it. We expect [our dates to be\nexact](https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca). We\nexpect [names to be relatively\nsimple](https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/).\nWe expect data to be complete at time of entry and consistent over time. Every\nprogrammer and every system design is a series of\n[Procrustean](https://en.wikipedia.org/wiki/Procrustes) choices about what\naspects of reality we want to reflect in our systems and what we can discard.\nI’m not saying this to criticize; this approach is the only way to build systems\nthat aren’t bogged down in an endless thicket of special situations (what we\ncall “edge cases” because they’re supposed to be rare paths on the periphery).\nBut, this process is so innate that we sometimes forget that it is also\nartificial, especially when it’s describing people. [Forcing a gender field to\nonly accept “male” or\n“female”](https://travel.state.gov/content/travel/en/passports/passport-help/sex-marker.html)\ndoesn’t force gender itself to be binary. Our definitions of [race are social\nconstructions that shift all the\ntime](https://www.nytimes.com/interactive/2023/10/16/us/census-race-ethnicity.html?unlocked_article_code=1.QlA.hsUD.Zln08WoXHt_3&smid=url-share).\nOur simplified model might provide us with insights (*autism diagnoses have\nincreased 300% over the last 20 years!*) but not capture the underlying factors\nbehind those insights (*it’s likely just a result of changes in how we define\nautism and increased\nscreening*).\nIt’s important to step back and look at the bigger picture of how any model was\nmade and what type of knowledge it doesn’t capture. Every abstraction is also an\nocclusion. As a data journalist, I learned how to interview data and how to be\nhighly rigorous about all the ways in which the answers I found could be\nmisleading. Paranoia is the data journalist’s best friend, if you want to avoid\n\n[an embarrassing correction.](/published/times-regrets-error.html). You need to be able to think about not just what the data says, but all the stuff it doesn’t include.\n\nUnfortunately, this metacognition is something an LLM can’t ever do. The model\nis their reality. As Robin Sloan succinctly notes in his compelling essay [“Are\nLanguage Models in\nHell?”](https://www.robinsloan.com/lab/language-models-hell/), AI models are\nbuilt from and view the world in a stripped-down way. Where you and I might look\nat text and see its context (things like the text formatting and titles, the\nauthor’s bio, the site where this was linked from), the LLM operates purely on a\nworld of letters and nothing more (technically, they’re receiving subword\ntokens, which is [why early models couldn’t count the letter ‘r’ in\nstrawberry](https://www.secwest.net/strawberry)). Asking a LLM to recognize the\nlimitations of its view on reality is like [asking a goldfish how the water\nis](https://fs.blog/david-foster-wallace-this-is-water/).\n\nWhen I was writing this section, I have been thinking about [DOGE’s inept\nattempts to find fraud at the Social Security\nAdministration](https://www.nytimes.com/2025/06/16/us/politics/doge-social-security.html?unlocked_article_code=1.Q1A.XJp3.4fxPQ8FD7iNl&smid=url-share).\nIn one example, DOGE looked at the SSA databases and discovered there were over\n9 million records in there with birth dates over 120 year ago but no death dates\nrecorded. Elon Musk declared the only possible explanation was that millions of\npeople were fraudulently receiving benefits. He was wrong about [both the cause\nof the problem and the severity of its\nimpact](https://crr.bc.edu/150-year-olds-arent-getting-social-security-heres-a-better-task-for-doge/).\nDOGE could’ve questioned the data quality. They could’ve examined payments being\nmade. They could’ve asked any of the experts at SSA to explain it to them. But\ninstead they took the data as it is and leaped to wrong conclusions, a pattern\nthey repeated over and over (as in this example of a different fraud claim about\npayments):\n\nIn the extensive analysis that followed, agency experts carefully documented fallacies in DOGE’s work, according to documents reviewed by The Times and those people.\n\n“These payments are valid,” Sean Brune, an acting deputy commissioner, wrote in a memo examining one of the issues. (A Treasury spokeswoman declined to comment.)\n\nBut Mr. Russo, who did not respond to a request for comment, said that DOGE would not trust career civil servants, according to people familiar with his statements. Instead, he insisted that Akash Bobba — a 21-year-old who had interned at Palantir and become one of DOGE’s lead coders — conduct his own analysis.\n\nIn their own wild ways, the DOGE crew were replicating the same operating conditions for themselves that cause LLMs to go astray. They refused to consider alternative explanations that were outside of what the data told them. They talked to nobody outside of their own circle. They latched onto a simplified explanation that was appealing to them because it completely validated their worldview of incompetent government staff and rampant fraud everywhere.\n\nThis is not a rare situation. I myself am mortified by the possibility of looking like a dumbass, so I don’t ever want to outsource my data analysis to an LLM. But, of course many people do. I fear this problem will only get worse.\n\n## Friction is a Gift\n\nThe appeal of LLM-driven development is that it’s supposed to eliminate\nfriction. Boosters spin tales of development teams shipping dozens of features\nin a single day, using multiple teams of agents working autonomously at their\ncommand in [increasingly strange\ntopologies](https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16dd04).\nAnd I get it, software development can be tedious and frustrating. It must feel\nsuper exciting to be able to churn out code at relatively ludicrous speeds and\nplay with polished products instead of prototypes.\n\nI need the friction though.\n\nWhen I am first learning a new language or framework, I struggle with friction\nto do even the most basic tasks. It sucks! And when am working with a new and\nunfamiliar code repository or data source, I need to set aside hours to\nscrutinize it. I often find myself doing a [close\nreading](https://en.wikipedia.org/wiki/Close_reading), pulling up specific files\nto look over line by line until I understand their context and the choices their\ndevelopers made. I know I could just ask an LLM to summarize the project for me\nand save myself the time, but I’ve found I need this process to really marinate\nin the code. I need it to not just understand the choices the developers made,\nbut *why* they made them and how they reflect the constraint or idioms of the\nlanguage they are using. I learn by failing, and if the LLM takes that work away\nfrom me, I won’t really understand what I’m doing.\n\nEven when working in familiar languages and my own code, I still rely heavily on\nfriction as a clue. When writing the code becomes hard, that tells me that I’m\ngoing down a wrong path with the current architecture, and that I should\nseriously consider redesigning things to make future enhancements easier. When\nthat happens, I usually go out for a long walk (or sign off for the day) to give\nmy brain space to step back and consider things from a new angle. It really\nworks. I find these pauses so effective that I will even force it upon myself\nwhen the way seems clear. When working on large software projects, I will wait\nto start coding a new feature until I’ve written an [Architectural Decision\nRecord](https://adr.github.io/) first that describes what I want to do. These\ndocuments force me to capture what I’m thinking at this point in time, my\nassumptions about the problem and the ramifications of my approach. Sometimes,\nit even makes me realize I was too enamored with my initial hunch to see how it\nwould go astray, and it always serves a good way to capture “what were they\nthinking?” for any future inheritors of my work.\n\nThe LLM-driven approach to friction is to just code your way through it without\nrethinking anything. And the LLM will oblige. It’ll probably make code that will\nwork. The performance metrics will be fine, the tests will pass (especially if\nthey also were written by the LLM). But it won’t know why it chose that path. It\ndoesn’t feel friction and can’t explain if one architectural approach felt\ncleaner than another. If the engineers crafting the prompts lack the insight to\nknow what is a good approach or a bad one, they get stuck in a dynamic of asking\nthe AI to code its way through friction over and over again. This can result in\na thicket of weird abstractions, and the only design documentation for future\nteams is a single Markdown file that contained the instructions for an AI model\nused a few years back. Good luck reconstructing the architectural decisions from\nthat! It is telling that most of the vibe coding success stories I’ve seen have\nbeen by developers who are already experts in what they are asking the LLM to\nbuild (and who are thus able to guide its work), or for situations where the\nstakes of failure are low. For the everything else, we just have to figure out\nhow to know [if the rest of the fucking\nowl](https://www.reddit.com/r/funny/comments/eccj2/how_to_draw_an_owl/) is any\ngood and safe to use.\n\nI’d be remiss if I didn’t mention one other thing that bothers me when LLM\npromoters invoke friction as a problem. Most of the LLM marketing in\nadvertisements, live demos and LinkedIn posts that I’ve seen portrays a solitary\nengineer (or perhaps a single team) heroically using LLM-driven coding to blast\nout some sort of app or website and launch it quickly (*our velocity and KPI is\nthrough the roof!*). But industry really wants developers to use LLMs for work,\nwhere the friction is usually established processes and practices to keep\ndefects or even poorly-conceptualized features from making it to production.\nInevitably, the need to prioritize LLM-driven velocity is turned against people\nthemselves – other engineers or team-mates in product or project management or\ntesting or compliance or design. Because those roles are seen as friction too.\nWho needs user research when we can craft AI personas? Who needs design when we\nhave AI tools to spit out web layouts? Who needs project managers when *we* are\nthe managers of our army of agents? What if we didn’t need to wait for another\ndeveloper to review our pull request and just automatically merge code that\npasses tests and scans? **What if we didn’t have to spend any of our work time\ntalking to other people and just could live in the realm of pure coding?** But,\nsoftware development is a collaborative process, and each member of the team\nhelps make a good product what it is. Removing those roles or replacing them\nwith LLM-inflected ghosts will certainly allow teams to move faster, but it\ndoesn’t mean the products that they deliver will be better. And the process will\ncertainly be a lot lonelier.\n\n## I Care A Lot\n\nPerhaps my simplest reason for not using LLMs is that I just love programming so\nmuch that I don’t want to hand it off to a machine. In much the same way I\nwouldn’t resort to AI if I were an artist or a musician, programming is one way\nfor me to express my creativity, and I will not cede that joy. Although [it can\nbe extremely frustrating at times](https://bukk.it/drawing-vs-drawing.jpg),\nthere is a profound delight in shaping something from a nebulous idea into a\nreal system, especially if it involves an elegant implementation or interesting\nproblems. Some evenings, I close the work laptop and open the personal laptop to\ndive into some new fun thing I want to build. And when I am building software\nprofessionally as part of a team, that is even better! I love the collaboration\nand the process of shaping software together, especially the ways in which\npeople will step up and take ownership of problems. I don’t think the dynamic is\nthe same when the team is just taking ownership of prompts and the LLM assistant\nis doing the work. Or the LLM assistant is replacing parts of the team.\n\nOwnership is important. Over the past few decades, I’ve worked in roles where\nI’ve developed a strong sense of personal responsibility. As a data journalist,\nan error in code could lead to an embarrassing correction or a devastating\nlawsuit. In civic technology, errors can mean catastrophic failures in providing\nservices and benefits, whether it’s to an entire vulnerable population or to a\nsingle person. I’m not going to say that I’ve never made mistakes, but I care a\nlot about getting it right because I care about the mission of the work. I have\nbeen privileged to work on teams with many other people who also care and want\nto do the best they can for people. An LLM can’t care. Sure, it [can do a\nconvincing job of pretending](https://www.youtube.com/watch?v=thsuwFAqc7U), but\nit’s still just a facsimile of a mind stringing together words that are more\nlikely to be associated with other. It’s not bothered by its mistakes or trying\nto do better, because [it has no inner\nconsciousness](https://www.noemamag.com/the-mythology-of-conscious-ai/), let alone a conscience. It can\nnever be held accountable, and I can never hand off my moral responsibilities to\nit for that reason.\n\nWhen the LLM does well, it’s a genius that will replace all coders. When the LLM\ndeletes all of your infrastructure or “lies” about tests, it’s your fault. After\nall, you just needed to structure your prompts and workflows exactly the right\nway so it will jostle the LLM into giving the correct output. Oops, try again.\nAnd again. Much of the LLM advice I’ve read emphasizes that you must give all\nthe necessary instructions and amendments and codicils up front or the system\nwill do things wrong. This mindset is a significant departure from agile\nprogramming, which emphasizes frequent course corrections and feedback and\ntrusting in your team to do the right thing. Instead, we seem to be retreating\nto a new usage model similar to the [time-sharing models of early\ncomputers](https://www.ibm.com/history/time-sharing) in the 1950s. Except here,\ninstead of walking up to hand in a sheaf of punch cards, the solitary programmer\nis instead bringing legal documents to be turned into programs.\n\nI jest; there is no legal liability at play here. It’s probably not surprising\ngiven the similar demographics involved, but LLM suppliers are repeating the\nsame dynamic as Tesla. [New features are being rolled out to user without safety\ntesting](https://www.fastcompany.com/91500914/elon-musks-self-driving-delusions-get-a-reality-check)\nand, just as strangely, LLM boosters, like Tesla superfans, [often blame\nthemselves and others for catastrophic\noutcomes](https://alexeyondata.substack.com/p/how-i-dropped-our-production-database)\nby saying the users should’ve done better in writing their prompts. I’m not\nreally sure what to make of this, but it bothers me that technology is\nstandardizing a capitalism where more risks are being borne by consumers because\ncompanies and government have both abdicated their responsibilities. [We banned\nlawn darts after they killed a single\nchild](https://en.wikipedia.org/wiki/Lawn_darts), but chatbots driving users to\ndeath and psychosis are accepted as the price of innovation in AI. Will things\nchange when vibe coding itself leads to someone dying from system failures\nrather than [dying of\nembarassment](https://futurism.com/artificial-intelligence/claude-wife-photos)?\n\nCoding has also been my comfort when times are hard. There is research that\n[playing Tetris is an effective way to avoid\nPTSD](https://www.ox.ac.uk/news/2017-03-28-tetris-used-prevent-post-traumatic-stress-symptoms).\nThe theory is that the therapy works because engaging the parts of the brain\nthat handle arranging and rotating shapes hinders the formation of traumatic\nmemories. Now, I am fortunate enough to not suffer from PTSD (and I am not\nmaking light of people who do), but I do also relate to this concept.\nProgramming feels like a complicated puzzle and has sometimes been my solace in\ndark times. As the example above hints at, I know a lot about DOGE, because for\nthe past year [I’ve been building and maintaining a system to track their\nrampage](https://dogetrack.info). Unlike a work project, this has been an\nexercise in assembling datasets to provide clarity into an organization that\nwants to stay obscured. It’s been a rewarding exercise and a way for me to\nchannel my despair into something I hope will be useful. This isn’t the only\ntime I’ve used code [as a way to work through my\nsadness](/projects/times-haiku.html), and it works because it *is* work and the\nprocess would be diminished if I only focused on the product.\n\n## A Few Other Silly Reasons\n\nThis has already proven to be a much longer piece than I expected, especially since it was originally just a few short posts on Bluesky. Before I close it out, a few more quick reasons!\n\nFirst, I absolutely hate the [unctuous tone that AI chatbots default take by\ndefault](https://www.youtube.com/watch?v=VecinjfP8Bk). As someone who grew up in\na city on the East Coast, I get really suspicious when someone is weirdly super\nnice to me without me knowing them, because it usually means they’re either\nabout to launch into a scam or proselytize to me. Reading LLM chat transcripts\nmakes my skin crawl. Yes, I am aware I could make the LLM adopt a whole\ndifferent tone, but somehow that makes the idea feel even worse.\n\nLike many developers, I have a whole folder of draft hobby projects that have\nnever been finished. For instance, there’s the one where I was going to write a\nclone of Spelling Bee, but it was going to be in Clojurescript so I could use\nthe [Blabrecs](https://mkremins.github.io/blabrecs/) code to generate non-words\nand make it super frustrating. Okay, I guess that would’ve just been funny to\nme. You had to be there. From the LLM perspective, these are folders of failures\nand I could indeed use LLM to make an app a day or whatever challenge I want.\nHowever, the process was far more important than the product (again!). Not every\nwhimsy needs to become a reality. Often, I get more from the fun of\nbrainstorming and the process of learning enough to know that I don’t need to\ncontinue and finish the job. It’s easy to forget this sometimes.\n\nThis wasn’t going to be an essay about the morality of using LLMs for my work. Not because I don’t care, but because many others have written far more effectively than me about the fraught implications of this technology. And at this moment where LLMs are bombing schools with children or generating child porn on demand, I really don’t feel comfortable using them. And I don’t feel comfortable not mentioning this aspect at all. It may be true that there is no ethical consumption under capitalism, but I’ll be damned if I’m not going to at least try. We can’t build a better world with tools that immiserate so many.\n\nWeirdly, nobody seems more miserable than LLM boosters. I might be more swayed\nif developers were using their newfound productivity gains to finally live that\n[4-hour workweek](https://en.wikipedia.org/wiki/The_4-Hour_Workweek) that nerds\nwere pretending to idolize 10 years ago. But perversely, it seems like many in\nSilicon Valley are outsourcing work to the AI agents and then using [their\nnewfound spare time to do even more\nwork](https://www.youtube.com/watch?v=l-Z0iyBNxpk). Instead of using their time\nfor relaxation or art or joy, they’re embracing\n[9-9-6](https://www.forbes.com/sites/bryanrobinson/2025/08/04/the-9-9-6-work-schedule-could-be-coming-to-your-workplace-soon/)\nwork schedule and a hyper-quantified workplace that would make even [Frederick\nTaylor](https://en.wikipedia.org/wiki/Scientific_management) blanch in horror.\nIt’s possible that the LLM revolution will finally come for me and my job, but\nI’d rather not work myself into the grave first.\n\n## Now What?\n\nI don’t pretend to know the future. Maybe the technology will advance to such a point I will regret my lack of experience and familiarity. Or, maybe it’ll stagnate and the whole financial house of cards will come tumbling down. If that happens, I hope we can rebuild software development into the humane practice of building a better world, one line of code at a time.", "url": "https://wpnews.pro/news/i-don-t-vibe-code", "canonical_source": "https://jacobharr.is/personal/i-dont-vibe-code", "published_at": "2026-05-20 16:56:42+00:00", "updated_at": "2026-05-20 18:35:48.592581+00:00", "lang": "en", "topics": ["large-language-models", "developer-tools", "artificial-intelligence"], "entities": ["ImageMagick"], "alternates": {"html": "https://wpnews.pro/news/i-don-t-vibe-code", "markdown": "https://wpnews.pro/news/i-don-t-vibe-code.md", "text": "https://wpnews.pro/news/i-don-t-vibe-code.txt", "jsonld": "https://wpnews.pro/news/i-don-t-vibe-code.jsonld"}}