I really tried to get into the vibe coding thing - just describe the thing I need in human language and let the agent figure it out. It was incredible at first. Then I realized that I am spending a lot of time writing clarifications because the agent either forgot or misinterpreted something. Then I realized that I am waiting an awful long time for each agent step to complete just to write another correction or clarification. Then I realized that this constant start-stop process is literally melting my brain and making me unable to do any real work myself. It's basically having the same effect as scrolling any other algorithmic feed. Now I am back to programming myself and only bouncing the boring bits off of ChatGPT.
If you're going to vibe code, why not do it in C?
171–180 of 626 posts
Re: If you're going to vibe code, why not do it in C?
#172Software development jobs must be very diverse if even this anti-vibe-coding guy thinks AI coding definitely makes developers more productive. In my work, the bigger bottleneck to productivity is that very few people can correctly articulate requirements. I work in backend, API development, which is completely different from fullstack development with backend development. If you ask PMs about backend requirements, th…
and in reality, all the separate roles should be deprecated
we vibe requirements to our ticket tracker with an api key, vibe code ticket effort, and manage the state of the tickets via our commits and pull requests and deployments
just teach the guy the product manager is shielding you from not to micromanage and all the frictions are gone
in this same year I've worked at an organization that didn't allow AI use at all, and by Q2, Co-Pilot was somehow solving their data security concerns (gigglesnort)
in a different organization none of those restrictions are there and the productivity boost is through an order of magnitude greater
Re: If you're going to vibe code, why not do it in C?
#173Earlier quoted context omitted.
Not to refute your point but I’ve met overly confident people with “AI skills” who are “extremely productive” with it, while producing garbage without knowing, or not being able to tell the difference.
You're describing lack of care and lack of professionalism, fire these people, nothing to do with the tools, it's the person using it the problem.
Yea I’m talking about people and that’s honestly what matters here. At the end of the day this tools is used by people and how people use it plays a big role in how we assess its usefulness.
Re: If you're going to vibe code, why not do it in C?
#174Earlier quoted context omitted.
Why Rust? Haskell is gold standard here.
Can you elaborate? What is it about Haskell that makes it better?
Very advanced type system which allows to move a lot of program correctness to typing system. So basically if your program compiles, it probably works.
It's also has GC which makes it better suited for most programs, compared to Rust with its manual memory management.
Re: If you're going to vibe code, why not do it in C?
#175I really tried to get into the vibe coding thing - just describe the thing I need in human language and let the agent figure it out. It was incredible at first. Then I realized that I am spending a lot of time writing clarifications because the agent either forgot or misinterpreted something. Then I realized that I am waiting an awful long time for each agent step to complete just to write another correction or clari…
I don't have much experience with it either, but what has worked so far is breaking down the problem into very small steps I can verify easily.
Re: If you're going to vibe code, why not do it in C?
#176Earlier quoted context omitted.
I have done both strict back-end, strict front-end, full stack, QA automation and some devops as well, I worked in an all Linux shop where we were encouraged by great senior devs to always strive for better software all around. I think you're right, it mostly depends on your mindset and how much you expose yourself to the craft. I can tackle obscure front-end things sometimes better than back-end issues despite hatin…
Hehe. In the "someone should make a website"™ department: using a crap tons of legacy protocols and plugins semi-interoperable with modern while offering legacy browsers loaded with legacy plugins something usable to test with, i.e., - SSL 2.0-TLS 1.1, HTTP/0.9-HTTP/1.1, ftp, WAIS, gopher, finger, telnet, rwho, TinyFugue MUD, UUCP email, SHOUTcast streaming some public domain radio whatever - , , , XHTML, SGML - Java…
why even write webpages or apps anymore just prompt an LLM everytime a user makes a request and write the page to send to the user :D
Re: If you're going to vibe code, why not do it in C?
#177I want to do my vibe coding in a dependently typed language, so that at least I can tell what the inputs and outputs are. I say Idris is the future!
Or... I want to only write the tests. The implementation is... an implementation detail!
Re: If you're going to vibe code, why not do it in C?
#178Earlier quoted context omitted.
To be honest I've never worked in an environment that seemed too complex. On my side my primary blocker is writing code. I have an unending list of features, protocols, experiments, etc. to implement, and so far the main limit was the time necessary to actually write the damn code.
That sounds like papier mache more than bridge building, forever pasting more code on as ideas and time permit without the foresight to engineer or architect towards some cohesive long-term vision. Most software products built that way seem to move fast at first but become monstrous abominations over time. If those are the only places you keep finding yourself in, be careful!
There are a wide number of small problems for which we do not need bridges.
As a stupid example, I hate the functionality that YouTube has to maintain playlists. However, I don't have the time to build something by hand. It turns out that the general case is hard, but the "for me" case is vibe codable. (Yes, I could code it myself. No, I'm not going to spend the time to do so.)
Or, using the Jira API to extract the statistics I need instead of spending a Thursday night away from the family or pushing out other work.
Or, any number of tools that are within my capabilities but not within my time budget. And there's more potential software that fits this bill than software that needs to be bridge-stable.
Re: If you're going to vibe code, why not do it in C?
#179Earlier quoted context omitted.
No I'm not, I'm just sick of these edgy takes where AI does not improve productivity when it obviously does. Even if you limit your AI experience to finding information online through deep research it's such a time saver and productivity booster that makes a lot of difference. The list of things it can do for you is massive, even if you don't have it write a single line of code. Yet the counter argument is like "bu..…
It "obviously" does based on what, exactly? For most devs (and it appears you, based on your comments) the answer is "their own subjective impressions", but that METR study ( https://arxiv.org/pdf/2507.09089 ) should have completely killed any illusions that that is a reliable metric (note: this argument works regardless of how much LLMs have improved since the study period, because it's about how accurate dev's impr…
not OP but I have a hard metric for you.
AI multiplied the amount of code I committed last month by 5x and it's exactly the code I would have written manually. Because I review every line.
model: Claude Sonnet 3.5/4.5 in VSCode GitHub Copilot. (GPT Codex and Gemini are good too)
Re: If you're going to vibe code, why not do it in C?
#180There was a recent discussion, “Why AI Needs Hard Rules, Not Vibe Checks” ( https://news.ycombinator.com/item?id=46152838 ). We need as many checks as possible - and ideally ones that come for free (e.g., guaranteed by types, lifetimes, etc.) - which is why Rust might be the language for vibe coding. Without checks and feedback, LLMs can easily generate unsafe code. So even if they can generate C or Assembly that wor…
Rust doesn't prevent programs from having logic errors. If LLMs produce code riddled with bugs in one language it will do in other languages as well. Rust isn't going to save you.
All kinds of drugs produce unwanted risks and side effects if abused, so let's abuse crystal meth! Cannabis isn't going to save you.