I'm a 100% vibe-coder. AI/CS is not my field. I've made plenty of neat apps that are useful to me. Don't ask me how they work; they just do.

Sure the engineering may be abysmal, but it's good enough to work.

It only takes basic english to produce these results, plus complaining to the AI agent that "The GUI is ugly and overcrowded. Make it look better, and dark mode."

Want specs? "include a specs.md"

This isn't a 20% more productive feeling. It's productivity beyond what I will ever do on my own, given this is not my field.

This is all possible because AI was trained on the outstanding work of CS engineers like ya'll.

But the article is highly opinionated. It's like saying only phD's can be called scientists, or only programmers can be computer hackers. But in reality every human is a scientist and a hacker in the real world. The guy in a street corner in India came up with novel ways to make and sell his product, but never wrote a research paper on it. The guy on his fourth marriage noted a statistical correlation in the outcome when meeting women at a bar vs. at a church. The plant that grew in the crevice of a rock noted sunlight absorption was optimal at an angle of 78.3 degrees and grew in that direction.

You made a forest hut and you are calling out people who build skyscrapers - gatekeepers.

> I'm a 100% vibe-coder. AI/CS is not my field. I've made plenty of neat apps that are useful to me.

This describes me pretty well too, though I do have a tiny bit of programming experience. I wrote maybe 5000 lines of code unassisted between 1995-2024. I didn't enjoy it for the most part, nor did I ever feel I was particularly good at it. On the more complex stuff I made, it might take several weeks of effort to produce a couple hundred lines of working code.

Flash forward to 2025 and I co-wrote (with LLMs) a genuinely useful piece of back office code to automate a logistics problem I was previously solving via a manual process in a spreadsheet. It would hardly be difficult for most people here to write this program, its just making some API calls, doing basic arithmetic, and displaying the results in a TUI. But I took a crack at it several times on my own and unfortunately between the API documentation being crap and my own lack of experience, I never got to the point where I could even make a single API call. LLMs got me over that hump and greatly assisted with writing the rest of the codebase, though I did write some of it by hand and worked through some debugging to solve issues in edge cases. Unlike OP, I do think I reasonably well understand what >90% of the code is doing.

> This isn't a 20% more productive feeling. It's productivity beyond what I will ever do on my own, given this is not my field.

So yeah, to the people here saying the above sentiment is BS - its not. For people who have never worked in programming or even in tech, these tools can be immensely useful.

I think it's like CMS and page builders enabling people to build their own websites without html and server knowledge. They're not making web developers disappear, instead there are more web developers now because those some of those people would eventually outgrow their page builders and need to hire web developers.

The crucial part is security.

If the apps runs locally it doesn’t matter, if it‘s connected to the net it could be the seed for the next Mirai bot network.

What have you actually made?

> Don't ask me how they work; they just do. Sure the engineering may be abysmal, but it's good enough to work.

I've worked on several projects from a few different engineering disciplines. Let me tell you from that experience alone, this is a statement that most of us dread to hear. We had nothing but pain whenever someone said something similar. We live by the code that nothing good is an accident, but is always the result of deliberate care and effort. Be it quality, reliability, user experience, fault tolerance, etc. How can you be deliberate and ensure any of those if you don't understand even the abstractions that you're building? (My first job was this principle applied to the extreme. The mission demanded it. Just documenting and recording designs, tests, versioning, failures, corrections and even meetings and decisions was a career in itself.) Am I wrong about this when it comes to AI? I could be. I concede that I can't keep up with the new trends to assess all of them. It would be foolish to say that I'm always right. But my experience with AI tools hasn't been great so far. It's far easier to delegate the work to a sufficiently mentored junior staff. Perhaps I'm doing something wrong. I don't know. But that statement I said earlier - it's a fundamental guiding principle in our professional lives. I find it hard to just drop it like that.

> But the article is highly opinionated. It's like saying only phD's can be called scientists, or only programmers can be computer hackers.

Almost every single quality professional in my generation - especially the legends - started those pursuits in their childhood under self-motivation (not as part of school curriculum even). You learn these things by pushing your boundary a little bit every day. You are a novice one day. You are the master on another. Are you absolutely pathetic at dancing? Try ten minutes a day. See what happens in ten years. Meanwhile, kids don't even care about others' opinion while learning. Nobody is gatekeeping you on account of your qualifications.

What they're challenging are the assumptions that vibe/AI coders seem to hold, but don't agree with their intuition. They are old fashioned developers. But their intuitions are honed over decades and they tend be surprisingly accurate for reputed developers like Geohotz. (There are numerous hyped up engineering projects out there that made me regret ignoring my own intuition!) It's even more valid if they can articulate their intuition into reasons. This is a very formal activity, even if they express them as blog posts. Geohotz clearly articulates why he thinks that AI copilots are nothing more than glorified compilers with a very leaky specification language. It means that you need to be very careful with your prompts, on top of tracking the interfaces, abstractions and interactions that the AI currently doesn't do at all for you. Perhaps it works for you at the scale you're trying. But lessons like the Therac-25 horror story [1] always remind us how bad things can go wrong. I just don't want to put that extra effort and waste my time reviewing AI generated code. I want to review code from a person whom I can ask for clarifications and provide critiques and feedback that they can follow later.

[1] https://thedailywtf.com/articles/the-therac-25-incident