8 ms·
Read your code
- deleted 1y ago[deleted]
- chanux 1y agoRelated reading: Programming as theory building ~ Peter Naur [PDF] https://pages.cs.wisc.edu/~remzi/Naur.pdf https://pages.cs.wisc.edu/~remzi/Naur.pdf
- swedishPerson1 1y ago[dead]
- davidmurdoch 1y agoTitle made me think this was about writing code for vibrators.
- tempodox 1y agoThat would be safety-critical, so you had better not vibe code it.
- patrickmay 1y agoJust how powerful are your . . . . Never mind, I don't want to know.
- vermon 1y agoPart of the definition of vibe coding is not looking at the code. If you read code you are not "vibing" anymore, you are just using AI tools to write code.
- Uehreka 1y ago“using AI tools to write code” is too clunky of a phrase. Unless someone proposes a sticky two/three-syllable verb (that people actually want to use, inb4 some sarcastic person suggests “poop-coding” or something) then people are going to fall back on vibe-coding because it’s quick to say, its definition will become blurred, and we’ll have no one to blame but ourselves.
- alphazard 1y agoI'm not going to read code created by an AI. The AI exists to prevent me from having to deal with the complexity of a task. The absolute most I want to read and write are type signatures. I'll set those up, let the AI go, see if it works. If it doesn't, maybe retry with a better prompt. If it still doesn't work, then I'll have to get involved. Start implementing from the top down, and once there is enough architectural structure, the AI can usually finish up. This still happens quite a bit, and it's just like taking away a hard task from someone less experienced. The difference is there is no point in investing your time teaching or explaining anything to the AI. It can't learn in that way, and it's not a person.
- nsxwolf 1y agoMight as well have it code in assembler then. Get the performance boost.
- stirfish 1y agoToo many tokens, imo. I like to vibe code single self-contained pages in html, css, and JavaScript, because there's a very slim chance that something in the browser is going to break my computer.
- Cheer2171 1y agoThen enjoy your security holes, placeholder fake features, and miles of atrocious 'clever' hacks.
- bbqfog 1y ago[flagged]
- chrisjj 1y ago> Sounds like every piece of human generated code I’ve ever seen. Good code is less visible.
- exasperaited 1y ago
- simonw 1y agoNew vibe coding definition just dropped! "Vibe-Coding is a dialogue-based coding process between a human and an AI where the human guides and the AI implements." Reminds me of Steve Yegge's short-lived CHOP - Chat Oriented Programming: https://sourcegraph.com/blog/chat-oriented-programming-in-action https://sourcegraph.com/blog/chat-oriented-programming-in-ac... I remain a Karpathy originalist: I still define vibe coding as where you don't care about the code being produced at all. The moment you start reviewing the code you're not vibe coding any more, by the definition I like.
- siva7 1y agoWe professionals need to stop with paroles like "vibe coding is bad". If you don't have dev skills and experience, your code will be shit - no matter if vibe coded or manually done. If you can't guide another dev - here the a.i. - the result will be as good as the clueless leading the clueless.
- josephg 1y agoVibe coding can make it a lot harder to learn programming though, depending on how you use an AI. If you're a beginner and you can't read code very well, you're going to struggle a lot more when you have thousands of lines of the stuff written badly by an AI.
- visarga 1y agoWhich means real experience still takes years. But you need to consider the speed at which coding agents improve. Maybe next year they will be more reliable to use without domain experience. Today? You can get a small app or POC without knowing how to code.
- tempodox 1y agoIf you don't guide the LLM, vibe coding is Russian roulette, no matter how good you think you are. If you look at the code, it's not vibe coding any more by its original definition. So vibe coding is only “good” for code that gets thrown away real quick.
- davidmurdoch 1y ago"You cannot delegate the act of thinking" This is very dumb. Of course you can.
- crinkly 1y agoIndeed. You can however be a moron and delegate it to another moron.
- visarga 1y ago> This is very dumb. Of course you can. When it's your problem being delegated, you can't delegate consequences away. I can eat for you, but you won't get satiated this way.
- exasperaited 1y agoIt is a philosophical remark and it is true on that level for sure. You cannot delegate the act of thinking because the process of delegation is itself a decision you have made in your own mind. The thoughts of your delegates are implicitly yours. Just like if you include a library in your code, you are implicitly hiring the developers of that library onto your project. Your decision to use the library is hiring the people who wrote it, to implicitly write the code it replaces. (This is something I wish more people understood)
- fxtentacle 1y agoThat article is like advising a blind person to thoroughly look at the road before crossing it.
- ollysb 1y agoYou can be an architect without reading the code. My process involves building a detailed plan before starting, at which point I ask lots of questions about architecture. After implementation I have a custom agent for reviewing the architecture and I usually ask a few questions at this point as well.
- energy123 1y agoIn what other area is it fashionable to use your own shortcomings and lack of knowledge as evidence that something is a bad idea?
- ericpauley 1y agoPersonally, I find that if a model can vibe-code the functionality I'm working on then it's not very high-value functionality. Perhaps (a) it's boilerplate (fine), (b) I'm not creating enough/the right abstraction, or (c) the code could easily be written by a junior dev. If I'm working on truly new functionality, modeling complex states and assumptions, or producing something that generalizes to many settings, the model does poorly beyond being a souped up auto-complete. That's not to say that these models don't provide value, especially when writing code that is straightforward but can't be easily generalized/abstracted (e.g., some test-case writing, lots of boilerplate idioms in Go, and basic CRUD). In terms of labor I potentially see this increasing the value (and therefore cost) of actual experienced developers who can approach novel and challenging problems, because their productivity can be dramatically amplified through proper use of AI tooling. At the other end of spectrum, someone who just writes CRUD all day is going to be less and less valuable.
- skydhash 1y agoBoilerplate code is my signal to take a few moment and says do I really need all that code? Or should I write some generators/parsers instead? Even when I'm not able to, copy-pasting is often easier.
- bbqfog 1y agoThese tools continue to increase in power. It’s incredible and there’s no use denying it. Asking people to read ai generated code will soon make as much sense as asking people to read compiler generated ASTs.
- danielbln 1y agoSoon, but not yet. At this point one should at least skim the code, and have a veritable zoo of validation and correction mechanisms in place (tests, LSP, complexity eval, completion eval, bot review, human review etc). That said, if you spend most of your time sussing out function signatures and micromanaging every little code decision the LLM makes, then that's time wasted imo and something that will become unacceptable before long. Builders will rejoice, artisan programmers maybe not so much.
- chrisjj 1y ago> Not reviewing AI-generated code will lead to serious problems. A requirement to do so might lead to more. Like loss of job for the illiterate "programmer".
- yanis_t 1y agoIf you write code yourself your productivity is limited by how much code you can write. If you read/review code generated by AI, then it's limited by how much you can read/review. The latter is not that much bigger than the former. I believe at some point we'll have to let go.
- tempodox 1y ago> productivity is limited by how much code you can write. So you measure “productivity” in lines of code? Say no more.
- BrunoRB 1y agoI'm not clear on the point you're making, but I do know that reading/reviewing is often more time-consuming and harder than actually writing code - at least if you're doing it right. Anyhow, I think we all just got too mesmerized with the LLM magic tricks and are slowly realizing that in real software writing we simply got a "slightly better stackoverflow". The claims of hyper-productivity are the same old ones of "I just copy and paste stuff other people wrote", i.e. people are just writing simple PoCs and really bad software - it's mostly bullshiters that couldn't and still can't do fizzbuzz. The real stuff continues to be written same way as before - and this is gonna become more and more apparent as the LLM garbage sneaks in more and more software.
- skydhash 1y ago> "slightly better stackoverflow" I'm still not sold on that. Stack overflow UI has lot of signals for a good response. The amount of answers, the upvotes on those answers, the comments,... With a quick scan, you can quickly see if you need to go back to the web search page (I've never used SO search) or do a slower read.
- kbrannigan 1y agoAre LMM compilers that are generating computer understandable instructions. I think of back in the day people use to chisel assembly code by hand. then came a system that all people to code more in english-like commands(prompts).
- _jab 1y agoI've found that there's a pretty consistent relationship between how clearly I can imagine what the code should look like, and how effective vibe coding is. Part of the reason for that is that it means I'll be more opinionated about the output of the model, and can more quickly tell whether it's done something reasonable.
- glitchc 1y agoI'm waiting for LLMs to vibe-code new algorithms.
- joe8756438 1y agoCurrently, the only way to understand code is to read it. You no longer need to understand code to produce it (maybe in some pre-AI cases that was also true). So no, you don’t _need_ to read code anymore. But not reading code is a risk. That risk is proportional to characteristics that are very difficult, and in many cases impossible, to measure. So currently best practice would be to continue reading code. Sigh.
- deleted 1y ago[deleted]
- jedimastert 1y agoThis comment section is unbelievable lol. I'm genuinely struggling to believe this many people would let code into a codebase without review.
- apwell23 1y agowhy should we give even tiny bit F about our employer when they are using AI to do interviews?
- exasperaited 1y agohttps://en.wikipedia.org/wiki/Therac-25 https://en.wikipedia.org/wiki/Therac-25
- skeaker 1y agoNot all software is life or death. I'd argue that very little of it is.
- jedimastert 1y agoI'm sure the devs at horizon IT thought the same thing https://www.theguardian.com/uk-news/2025/jul/08/post-office-scandal-inquiry-horizon-it-scandal https://www.theguardian.com/uk-news/2025/jul/08/post-office-...
- skeaker 1y agoPoint not taken. That remains as the vast minority of all software. I can't link a counterexample because nobody would ever put an article saying "indie game has bug" or "IoT coffeepot has to be rebooted every few months," but I can assure you the majority of software has much lower stakes.
- exasperaited 1y agoI am not struggling to believe it at all. Because I am an old guy with a CS degree but decades of web development experience. Apparently this is called being "a legacy developer". This is the logical conclusion of the indiscipline of undereducated developers who have copied and pasted throughout their career. This reality is then expressed as "but humans also copy and paste" as if this makes it OK to just hand that task over now to an AI that might do it better, where the solution is to train people to not copy and paste. Everything about AI is the same story, over and over again: just pump it out. Consequences are what lawyers are for. It's really interesting to me that within basically a generation we've gone from people sneering at developers with old fashioned, niche development skills and methodologies (fortran, cobol, Ada) to sneering at people with the old-fashioned mindset that knowing what your code is doing is a fundamental facet of the job.
- andix 1y agoCoding with AI agents is very similar to working with junior developers (or even other developers) in a team. Someone needs to give the project direction, keep the code organized, suggest refactorings, and many more things. I guess it's really hard to work with AI agents, if you don't have real project experience in a more senior position.
- apwell23 1y agojunior developer doesn't delete tests to "make tests pass"
- michaelrpeskin 1y agoYou haven't been in the industry long enough :)
- spauldo 1y agoI do that and I'm senior :) (To be fair my kind of testing is a lot different than unit tests, and the tests I'm cancelling are mulit-page forms that require three signatures.)
- funkyfourier 1y agoIn my experience it is more like a quite skilled developer, but who is dead drunk.
- deleted 1y ago[deleted]
- goodspc 1y agowe can arrange them, not arranged by them
- broast 1y agoReading code is just as fun as writing it, to be honest
- eddd-ddde 1y agoPersonally I love reading code and reviewing code. I always find it funny when people say that LLMs result in their job having less of what they like (coding) and more of what they hate (reviewing).
- MomsAVoxell 1y agoI have found the following methods to be workable and productive when using AI/ML in a project: * Treat the AI/ML as a junior programmer, not a senior - albeit one willing to make a leap on basically any subject, nevertheless - a junior is someone whose code must always be questioned, reviewed, and understood - before execution. Senior code is only admissible from a human being. However, human beings may have as many junior AI’s in their armpit as they want, as long as those humans do not break this rule. * Have good best practices in the first f’in place!! Vibe-coding is crap because ‘agile hacking’ is crap. Put your code through a proper software process, with a real workflow - i.e. don’t just build it and ship it. Like, ever. Even if you’ve written every line of code yourself - but especially if you haven’t - never ship code you haven’t tested, reviewed, proven, demonstrated in a production analog environment, and certified before release. Yes, I mean it, your broken FNORD hacking habits will be force-magnified immediately by any AI/ML system you puke them into. Waterfall or gtfo, vibe-code’rs… * Embrace Reading Code. Look, if you’re gonna churn milk into butter, know what both milk and butter taste like, at least for your sake. Don’t ship sour butter unless you’re making cheese, and even then, taste your own cheese. AI/ML is there to make you a more competent human being; if you’re doing it to avoid actually doing any work, you’re doing it wrong. Do it to make work worth doing again….
- pvds78 1y ago[dead]
- BadBadJellyBean 1y agoWe have a simple rule: You commit it, you own it. If you vibe coded it that's okay. If it's garbage that's on you. Blaming the LLM doesn't count. So of course you have to read the code. You have to read it and understand it. Works well for us.
- yosito 1y agoAnother related rule: never commit code to the main branch that hasn't been read by at least two humans.
- AdieuToLogic 1y ago> Another related rule: never commit code to the main branch that hasn't been read by at least two humans. Passive code reviews ("read by at least two humans") are fraught with error. IMHO, a better mantra is: Never allow a merge to the main branch that does not have some amount of documented test coverage, be it unit, functional, and/or integration specs.
- BadBadJellyBean 1y agoOf course that is true but with AI you can add documentation and tests. You can have absolut garbage with all green tests. We do human reviews on PRs but in the end it's your code that you have to stand behind.
- redhale 1y ago> It’s always easier to straighten a sapling than a grown tree. Ok, but in this case you can just throw away the tree and a new one will grow immediately for you to review anew. Rinse and repeat. I'm not saying the author's proposed approach is never the right one, but there is a meaningfully different approach between the two suggested. You can look at the result of a fully autonomous agent, note the issues, tweak your prompt + inputs and then start over. You get the benefits of more closely-steered output without the drag of having to constantly monitor it synchronously. For some things, this approach is token-wasteful, but for small (yet critical / high-value) features, I have found it to work quite well. And an ancillary benefit is that your starting prompts and inputs improve over time.
- aDyslecticCrow 1y agoBut once you have carefully inspected 8 trees and thrown them away, you may need to start from sapling after-all. And what about when you need a Forrest? Seed from trees grow new trees. A whole Forrest cannot be inspected and discarded over and over. > but for small (yet critical / high-value) features These are the features than need the human attention. These are the features that are the most fun for a human to make. These are the features that make the human improve the most. So it's the last ones i would leave to the AI.
- SubiculumCode 1y agoANyone else getting a warning when they go to the linked https site that there is a security risk?
- vdupras 1y ago> Everyone keeps saying it these days: treat your AI like a (brilliant) new junior dev. Really? You mean that person that drains senior developer time, but in which we still invest time because we're confident they're going to turn out great after the onboarding? Until then, they're a net time sink, aren't they? Unless the projects you've got to deliver are fantastically boring. So is this really what it's all about? Perpetual onboarding?
- AdieuToLogic 1y agoIt is funny how "vibe coding" best practices are indistinguishable from stakeholders defining functional requirements. Both require sufficient formalization of what is needed such that it can be delivered and neither is overly concerned with how the solution is encoded. It is almost as if understanding the problem to be solved is the hard part.