9 ms·

Write less code, be more responsible

169 points by orhunp_ 6mo ago

agentultra 6mo ago
I’m working as a single solo developer of a tiny video game. I’m writing it in C with raylib. No coding assistants, no agents, not even a language server. I only work on it for a few hours during the week. And it’s progressing at a reasonable pace that I’m happy with. I got cross-compilation from Linux to Windows going early on in a couple of hours. Wasn’t that hard. I’ve had to rework parts of the code as I’ve progressed. I’ve had to live with decisions I made early on. It’s code. It’s fine. I don’t really understand the, “more, better, faster,” cachet to be honest. Writing the code hasn’t been the bottle neck to developing software for a long time. It’s usually the thinking that takes most of the time and if that goes away well… I dunno, that’s weird. I will understand it even less. Agree with writing less code though. The economics of throwing out 37k lines of code a week is… stupid in the extreme. If we get paid by the line we could’ve optimized for this long before LLM’s were invented. It’s not like more lines of code means more inventory to sell. It’s usually the opposite: the more bugs to fix, the more frustrated customers, the higher churn of exhausted developers.
- anitil 6mo ago
  I had a look at your github and blog but couldn't find the game, is it public? Or do I need to watch your streams to see it?
- bdangubic 6mo ago
  > Writing the code hasn’t been the bottle neck to developing software for a long time. I see this on HN just so much and I am not sure what this is, almost seems like a political slogan that followers keep repeating. I had to do some rough math in my head but in the last 5 years I have been involved with hiring roughly 40 SWEs. Every single one of them was hired because writing the code was THE bottleneck (the only one) and we needed more people to write the code
  - ahefner 6mo ago
    But how much time per week does an SWE actually spend writing code?
    - bdangubic 6mo ago
      another one, this is 2nd most frequent thing people write here, not sure how to even approach answering :) so I’ll do what I was thought in first grade to never do and answer a question with a question - how much time per week does a brick layer spend laying bricks? they are looking at these new “robots” laying bricks automatically and talking on BrickLayerNews “man, the brick laying has not been a bottleneck for a long time.” But to answer your question directly, a lot of time if other people do their job well. Last week I had about 7 hours of meetings, the rest of the time I was coding (so say 35 hours) minus breaks I had to take to stretch and rest my eyes
      - paulhebert 6mo ago
        Interesting! I guess it really varies between jobs, roles, and companies. Thats never been my experience but I have an odd skill set that mixes design and dev. I’ve always spent a lot of time planning, designing, thinking, etc. How detailed are the tickets if you spend all your time coding? You never have to think through architecture, follow up on edge cases the ticket writers didn’t anticipate, help coworkers with their tasks, review code, etc.?
      - deleted 6mo ago
        [deleted]
      - apsurd 6mo ago
        i think this is it. you're a bricklayer. No, the bottleneck for erecting buildings is not bricklaying. Without taking all the time to write a dissertation to try to convince you, because why; how about we just start with even zoning laws and demographic analysis preclude the laying of the bricks. is it so unreasonable to think it is not about the laying of the bricks?
      - slopinthebag 6mo ago
- brianwmunz 6mo ago
  Honestly I think you can tell pretty quickly if a company or person is approaching AI from the viewpoint of accelerating development and innovation or just looking to do the same amount of work with less people. The space has been flooded by mean-spirited people who love the idea of developers becoming obsolete, which is a viewpoint that isn't working out for a lot of companies right now...many are already scrambling to rehire. Approaching the situation practically, integrating AI as a tool and accelerator is the much smarter way and if done right will pay for itself anyway.
  - shimman 6mo ago
    Those mean spirited people are actually capitalists and they've been chasing the dream of perpetual labor since the 1800s.
- 20k 6mo ago
  >I don’t really understand the, “more, better, faster,” cachet to be honest. Writing the code hasn’t been the bottle neck to developing software for a long time. It’s usually the thinking that takes most of the time and if that goes away well… I dunno, that’s weird. I will understand it even less. This is what I've always found confusing as well about this push for AI. The act of typing isn't the hard part - its understanding what's going on, and why you're doing it. Using AI to generate code is only faster if you try and skip that step - which leads to an inevitable disaster
  - koolba 6mo ago
    > The act of typing isn't the hard part - its understanding what's going on, and why you're doing it. Using AI to generate code is only faster if you try and skip that step - which leads to an inevitable disaster It’s more than just typing though. A simple example remembering the exact incantation of CSS classes to style something that you can easily describe in plain English. Yes, you could look them up or maybe even memorize them. But there’s no way you can make wholesale changes to a layout faster than a machine. It lowers the cost for experimentation. A whole series of “what if this was…” can be answered with an implementation in minutes. Not a whole afternoon on one idea that you feel a sunk cost to keep.
    - sublinear 6mo ago
      This is not correct. CSS is the style rules for all rendering situations of that HTML, not just your single requirement that it "looks about right" in your narrow set of test cases. Nobody writing production CSS for a serious web page can avoid rewriting it. Nobody is memorizing anything. It's deeply intertwined with the requirements as they change. You will eventually be forced to review every line of it carefully as each new test is added or when the HTML is changed. No AI is doing that level of testing or has the training data to provide those answers. It sounds like you're better off not using a web page at all if this bothers you. This isn't a deficiency of CSS. It's the main feature. It's designed to provide tools that can cover all cases. If you only have one rendering case, you want an image. If you want to skip the code, you can just not write code. Create a mockup of images and hand it off to your web devs.
- colechristensen 6mo ago
  >Writing the code hasn’t been the bottle neck to developing software for a long time. Then we're doing different things. I didn't like GitHub so I wrote my own. 60k lines of code later... yes writing code was the bottleneck which has been eliminated. The bottleneck is now design, review, and quality assessments that can't be done trivially. This isn't even the project I wanted to be doing, the tools that were available were holding me back so I wrote my own. It also consumes a few hours a week. If you think writing code isn't the bottleneck then you aren't thinking big enough. If you don't WANT to think big enough, that's fine, I also do things for the joy of doing them.
  - ozim 6mo ago
    We do different things, I do code for other people to use. Once we tried shipping features and updates every week, because we could ideate, code, test and deploy that fast. No user wanted that - product owners and business wanted that or they thought they wanted, until users came with torches and pitchforks. Don’t forget there is user adoption and education. Churning out features no one will use because they don’t know about is useless.
- bitexploder 6mo ago
  You can use LLM to write less code too. Just takes more intention. Which is kind of the whole point.
- dpark 6mo ago
  > Writing the code hasn’t been the bottle neck to developing software for a long time. It’s usually the thinking that takes most of the time Does your coding not involve thinking? And if not, why are you not delighted to have AI take that over? Writing unthinking boilerplate is tedious garbage work. Today I wanted to address a bug I found on a product I work on. At the intersection of platform migration and backwards compatibility I found some customers getting neither. I used an LLM to research the code paths and ensure that my understanding of the break was correct and what the potential side effects of my proposed fix would be. AI saved me stepping through code for hours to understand the side effects. I asked it for a nice description of the flow and it gave it to me, including the pieces I didn’t really know because I’d never even touched that code before. I could have done this. Would it have been a better use of my time than moving on to the next thing? Probably not. Stepping through function calls in an IDE is not my idea of good “thinking” work. Tracing through glue to understand how a magical property gets injected is a great job for a machine.
  - lelanthran 6mo ago
    >> Writing the code hasn’t been the bottle neck to developing software for a long time. It’s usually the thinking that takes most of the time > I used an LLM to research the code paths and ensure that my understanding of the break was correct and what the potential side effects of my proposed fix would be. Using the LLM for understanding is very different to using the LLM for codegen. You are not really disagreeing with the author here; it's just that for the specific project he is talking about, he already understands it just fine so the advantages of LLM help in understanding is tiny.
    - dpark 6mo ago
      My point is that these are not separate activities. They are drawing a false distinction between thinking and coding and then asserting that code speed doesn’t matter and implying that AI only helps with the coding bit. None of this is actually true, though. Coding and thinking are often tightly intertwined, as rarely is the coding piece so straightforward that it requires no interesting thought. Coding speed does matter, even if it’s not the primary bottleneck for many things. And AI can be very helpful outside the context of pure coding.
- throwaw12 6mo ago
  > Writing the code hasn’t been the bottle neck to developing software for a long time It was! pre-2022 people needed developers to build software for them, now with platforms like Replit, Lovable - people are creating their own tiny software projects, which wasn't easily accessible in the past. If you say coding wasn't a bottleneck, then indirectly you could also say, you don't need developers. If you need developers, outcome of their other type of work (thinking, designing based on existing tools and so on) is actually CODE.
- changyou 6mo ago
  [dead]
- ignoramous 6mo ago
  > Writing the code hasn’t been the bottle neck to developing software for a long time. For who? There's no lack of professional programmers who couldn't clear FizzBuzz now coding up company-sized systems using Agents. This is all good as long as agents can stick to the spec/req & code it all up with decent enough abstractions... as the professional approving it is in no position to clue it on code organization or bugs or edge cases. I think, we (as a society) are looking at something akin to "reproducibility crisis" (software full of Heisenbugs) as such "vibe coded" systems get widely sold & deployed, 'cause the "pros" who excel at this are also good at... selling.
  - agentultra 6mo ago
    Valid concern and one I share. If you’re going to vibe code up an operating system you will still need the experience and understanding of operating system fundamentals to have a chance at producing anything useful. The one-shot vibe-coded C compiler is a good example. Sure it created a compiler that could pass the basic tests. But it was no where near a plausible or useful compiler you’d use in a production system. Someone who knows compilers reviewed it and was able to prompt Claude or Gemini to fix the issues. But still… you’re not going to be able to do that unless you know what to look for. On an enterprise development team doing boring, Line of Business software? Might have a chance at rolling the dice and trusting the agents and tests and processes to catch stuff for you but I’d still be worried about people who don’t know what questions to ask or have deep expertise to know what is “good,” etc.
    - daotoad 6mo ago
      The gap between quality work and baseline LLM output is precisely the understanding. If it can be validated by automation, the bot will do it. But no automation suite is complete or perfect. What concerns me is that building software using the LLMs gives a distance that inhibits the formation of the sort of understanding I need to "just know" a code base intuitively. So when product asks for a feature, my ability to be sufficiently pedantic about the 6 different non-obvious things this impacts is less effective. And when I need to choose abstractions and try to form an effective ontology, my intuition is less effective. I believe I can still grind out an effective solution, but I start farther from the finish line. Does the LLM's ability to "answer questions" about the codebase make up for my lack of intuition? Does my apparent ability to run faster make up for the fact that I am starting farther from the end of the race? I don't know yet.
- hnthrowaway0315 6mo ago
  “more, better, faster,” I have heard these words, almost verbatim, from manager-yes-men coming from a FAANG background, and surprisingly concentrated in a certain demography (if someone find this offensive, I'll remove this part). My CTO wants us to "deliver as fast as possible", and my VP wants us to "go much faster, and more ownership". "Better" or anything related with quality was definitely mentioned, too, but always at a second place. To this day, I consider these yes-men to be a major red flag, so I always tried to probe for such information during interviews.
  - drekipus 6mo ago
    I'm interested in how you're probing for them? I haven't needed to change jobs but I'm worried that one day I'll have to
    - hnthrowaway0315 6mo ago
      Just ask along the line "Do you have someone from FAANG as a director/VP? Because I have worked with a few and really loved the learning process" and do a bit of research once you know the name of the hiring manager.
- YesBox 6mo ago
  I've been developing a moderately popular (for an indie) game for over 4 years at this point (full time). C++, SFML, SQLite. Same as you: no coding assistants, no agents, etc. I also don't use git. [1] One of the largest speedups is from how much of the codebase I can keep in my head. Because I started from an empty C++ file, the engine reflects how I reason and organize concepts (lossless compression). Thus most of the codebase is in my brains RAM. I don't see how LLM agents are going to improve my productivity in the long run. The less a person understands their code (organized logic), the more abstracted the conversation is going to become when directing an agent. The higher up the abstraction ladder you go, the less distinct your product becomes. [1] And very, very rarely have I wished I had it for a moment. Not using git simplifies abstracted parts of development. No branches, no ballooning of conceptual tangents, etc. Focus on one thing at a time. Daily backups and a log of what I worked on for the day suffices should I need to revisit/remember earlier changes. I've never been in a situation where I change I made over a week ago interfered with todays work.
  - agentultra 6mo ago
    I definitely feel like understanding the system is a big part of what makes it relatively easy to maintain/understand. My game is just in my spare time while I'm looking for work and the scope of the project is small so that I can finish it, release it, and start working on the next one. I'm not trying to build an engine or anything. Just a game. Not even the best game I can make. I can iterate on it fast because I know the structures. I can refactor it fast because I've built an intuition for a process over time that keeps code amenable to changes over time. I know I'm not going to make the right decisions at the start so I avoid committing to generalizations, etc. Editing code is pretty fast for me. Again, years working with a particular setup. I still have expandable snippets, multi-cursor editing and a host of macros for common editing motions. Checking changes... pretty fast. I'm getting to the point where I might invest in using dynamic reloading for my in-development builds. I suspect it will take a few hours to do at most. Not a big deal. For now I have a basic system that just watches for file changes and recompiles/re-runs the program. In a different context, working on a team in a large multi-million line codebase... I dunno what other people find it's like but I've never found it terribly slow to write/edit code or ship features. I can usually knock most tasks out at a reasonable pace especially when my familiarity with the area of the code I'm working in increases. I usually find my priorities shift with the demands of users, the business, etc. Some times I work on shipping new features quick. Other times it's making sure what we ship the right things and done well so that we don't leak PII. Either way... actually writing the code isn't the slowest part, in my experience. It's all the other stuff: the meetings, the design, maintenance, documentation, understanding the problem domain, actually shipping the code to production, etc that takes up the most time for me.
- pdimitar 6mo ago
  This: > I don’t really understand the, “more, better, faster,” cachet to be honest And this: > I’m working as a single solo developer ...I believe explain it all here. You likely are not beholden to PMs, CEOs and the like. Of course you can go at your own pace. I am actually puzzled that you don't understand that aspect yourself. > The economics of throwing out 37k lines of code a week is… stupid in the extreme Again, bosses. CEOs have 14 calls a week with potential prospects and sometimes want demos, sometimes they sign quickly and want a prototype, and sometimes they arrange a collab with a friend or family. Then 3 weeks later the whole thing falls apart and you have to throw it away because it's getting in the way of delivering what actually still pays the bills. I am not the CEO. I try making his visions come true. I don't get to make the calls on whether 37k of lines will be quickly churned out and then deleted some weeks later. I think your comment is overly focused only on the coding/programming aspect of things. We don't exist in a vacuum. May I ask how do you make your living? That might shed extra light on your trouble understanding the inevitable churn when writing code for money. --- All of this does not even mention the fact that I 100% agree that less coding lines == less trouble. Code is generally a liability, I believe every mature dev understands that. But often we are not given a choice so we have to produce more code and periodically compress it / re-architect it (while never making the mistake of asking to be given time to do so because we never will).
- quacker 6mo ago
  Writing the code hasn’t been the bottle neck to developing software for a long time. Code may not be the bottleneck, but writing it absolutely does consume time. Especially with solo game dev, I can prototype ideas, try them out, and then refine or scrap them at a rate I could never do without AI. This type of experimentation is a perfect use-case for AI. It’s actually super fun, and if I pay attention and give the AI decent instructions, I don’t really lose out on code quality.
- h4kunamata 6mo ago
  >I don’t really understand the, “more, better, faster,” cachet to be honest Numbers, it is all about numbers. I have worked in a company where one release a week would drive the managers insane, by them we should have one release every minute. Things break all the time because in order to deploy faster and faster, corners were cut and now one of the most visited online pet store in the country is down :)
stratts 6mo ago
It was always possible to write large amounts of crappy code if you were motivated or clueless enough (see https://github.com/radian-software/TerrariaClone https://github.com/radian-software/TerrariaClone). It's now just easier, and the consequences less severe, as the agent has code comprehension superpowers and will happily extend your mud ball of a codebase. There are still consequences, however. Even with an agent, development slows, cost increases, bugs emerge at a higher rate, etc. It's still beneficial to focus on code quality instead of raw output. I don't think this is limited writing it yourself, mind - but you need to actually have an understanding of what's being generated so you can critique and improve it. Personally, I've found the accessibility aspect to be the most beneficial. I'm not always writing more code, but I can do much more of it on my phone, just prompting the agent, which has been so freeing. I don't feel this is talked about enough!
Kiyo-Lynn 6mo ago
[dead]
qudat 6mo ago
A similar post with more emphasis on validating changes: https://bower.sh/thinking-slow-writing-fast https://bower.sh/thinking-slow-writing-fast
chillaranand 6mo ago
For various internal tools & other projects, I started using config only tools and avoid code as much as possible. https://avilpage.com/2026/03/config-first-tools.html https://avilpage.com/2026/03/config-first-tools.html
- dgb23 6mo ago
  I like this. Thanks for sharing. I think "config first" is an understatement. The more general term here is "data driven". It's sort of obvious that agents are way better and faster when writing data that can be validated easily against a schema and understood and reviewed in far less time. Data driven also gives you leverage, because it is far easier to for a program to produce data than code. The same applies to humans as well. Sort of ironic that we are now rediscovering and celebrating robust approaches like writing well designed CLIs, data driven programming, actionable error messages and good documentation. Maybe AI agents are a sort of reality check or even evolutionary pressure that forces us to do the right things.
osm3000 6mo ago
I am a machine learning engineer. I've been in the domain almost 12 years now (different titles and roles). In my current role (and by no means that is unique), I don't know how to write less code. Here are problems I am facing: - DS generating a lot of code - Managers who have therapy sessions with Gemini, and in which their ideas have been validated - No governance on DS (you want this package? import it) - No governance on Infrastructure (I spent a couple of months upskilling in a pipeline technology that were using: reading documentation and creating examples, until I became very good it...just for the whole tech to be ditched) - Libraries and tools that have been documentation, or too complex (GCP for example) The cognitive overload is immense. Back few years ago, when I was doing my PhD, immersing in PyTorch and Scipy stack had a huge return on investment. Now, I don't feel it. So, how do I even write less code? Slowly, I am succumbing to the fact that my tools and methods are inappropriate. I am steadily shifting towards offloading this to Claude and its likings. Is it introducing risks? For sure. It's going to be a disaster at one point. But I don't know what to do. Do I need a better abstraction? Different way to think about it? No clue
- __mharrison__ 6mo ago
  I've seen some success teaching data scientists how to write better code. SWE concepts like modularity, testing, and refuse. Things that they normally ignore or choose to throw out the window. (Disclosure: I'm a corporate trainer)
  - osm3000 6mo ago
    I appreciate that. I am not a position though to advocate for such a change :)
    - maigret 5mo ago
      Not yet, maybe.
- rwmj 6mo ago
  What is DS?
gbro3n 6mo ago
My current take is that AI is helping me experiment much faster. I can get less involved with the parts of an application that matter less and focus more (manually) on the parts that do. I agree with a lot of the sentiment here - even with the best intentions of reviewing every line of AI code, when it works well and I'm working fast on low stakes functionality, that sometimes doesn't happen. This can be offset however by using AI efficiencies to maintain better test coverage than I would by hand (unit and e2e), having documentation updated with assistance and having diagrams maintained to help me review. There are still some annoyances, when the AI struggles with seemingly simple issues, but I think that we all have to admit that programming was difficult, and quality issues existed before AI.
jsxyzb 6mo ago
[dead]
bob1029 6mo ago
> Nowadays many people are pushing AI-assisted code, some of them in a responsible way, some of them not. So... what do we do? You hold them accountable. Once upon a time we used to fire people from their jobs for doing things poorly. Perhaps we could return to something approximating this model.
voidUpdate 6mo ago
I'm not entirely sure I can trust the opinions of someone on LLMs when their blog is sponsored by an AI company. Am I not simply seeing the opinions that the AI company is paying for?
AlexSalikov 6mo ago
Good framing. I’d add that “be responsible” extends well beyond code quality - it’s about product responsibility. AI making code cheaper to produce doesn’t make the decisions around it any cheaper. What to build, for whom, and why — that’s still fully on you. It should free up more time for strategy, user understanding, and saying “no” to things that shouldn’t exist regardless of how easy they are to ship. The maintainability concern Orhun raises is real, but I think the root cause isn’t AI — it’s ownership. If you don’t understand what was built, you can’t evolve it. It’s the same failure mode as a PM who doesn’t grasp the technical implementation — they end up proposing expensive features that fight the architecture instead of working with it. Eventually, someone has to pay for that disconnect, and it’s usually the team
andai 6mo ago
After experimenting with various approaches, I arrived at Power Coding (like Power Armor). This requires: - small codebases (whole thing is injected into context) - small, fast models (so it's realtime) - a custom harness (cause everything I tried sucks, takes 10 seconds to load half my program into context instead of just doing it at startup lmao) The result is interactive, realtime, doesn't break flow (no waiting for "AI compile", small models are very fast now), and most importantly: active, not passive. I make many small changes. The changes are small, so small models can handle them. The changes are small, so my brain can handle them. I describe what I want, so I am driving. The mental model stays synced continuously. Life is good.
shevy-java 6mo ago
> So you are saying that the quality of the projects is going down? The website seems to at the least be semi-generated via AI. But I think the statement that the quality of many projects went downwards, is true. I am not saying all projects became worse, per se, but if you, say, search for some project these days, often you land on a github page only. Or primarily. How is the documentation there? Usually there is README.md and some projects have useful documentation. But in most cases that I found, open source projects really have incredibly poor documentation for the most part. Documentation is not code, so the code could be great, but I am increasingly noticing that even if the code gets better, the documentation just gets worse; rarely updated, if at all. Even when you file requests for specific improvements, often there is no response or change, probably because the author just lacks time to do so, anyway. But I am also seeing that the code also gets worse. AI generated slop is often unreadable and unmaintainable. I have even recently seen AI spam slop used on mailing lists - look here: https://lists.ffmpeg.org/archives/list/ffmpeg-devel@ffmpeg.org/thread/W36Z3IDH6ZQ55CKFJ6KRJZCS5NJBNFL3/ https://lists.ffmpeg.org/archives/list/ffmpeg-devel@ffmpeg.o... Michael Niedermayer does not seem to understand why AI slop is a problem. One comment reveals that. I don't read mailing lists myself really (never was able to keep up with traffic) but I would be pissed to no ends if AI spam like that would land into my mailbox and waste my time. Yet the people who use AI spam, don't seem to understand mentally why that is a problem. This is interesting. They suddenly think spam is ok if AI generated it. So the overall trend is that quality goes down more and more. Not in all projects but in many of them.
philipwhiuk 6mo ago
> It's something ethical that I don't know the answer to. In my case, it was the guy's first ever open source project and he understandably went for the quickest way of creating an app. While I appreciate their contribution to open source, they should be responsible for the quality of what they put out there. Pitching this is the exact opposite of the maintainer burden of expectation. > Sometimes I discover a project that is truly wonderful but visibly vibe-coded. I start using it without the guarantee of next release not running rm -rf and wipe my system. For me this is on you, not the developer.
travelalberta 6mo ago
Code Complete came out in '93 and even then they acknowledge most of the work around development wasn't actually programming but architecture, requirements, and design. Sure you can let Claude have a field day and churn out whatever you want but the question is: a) Did you read the diffs and provide the necessary oversight to make sure it actually does what you want properly, b) Is the feature actually useful? If you've worked on legacy systems you know there's so much garbage floating around that the bar isn't that high generally for code as long as it seems to work. If you read the code and documentation Claude makes thoroughly and aren't blindly accepting every commit there is not really a problem as long as you are responsible and can put your stamp of approval on it. If you are pushing garbage through it doesn't matter if a junior dev, yourself, or Claude wrote it, the problem isn't the code but your CI/CD process. I think the problem is expectations. I know some devs at 'AI-native' organizations that have Claude do a lot for them. Which is fine, for a lot of boiler plate or standard requests they can now ship 2X code. The problem is the expectation is now that they ship 2X code. I think if you leave timelines relatively the same as pre-AI then having an agent generate, document, refactor, test, and evaluate code with you can lead to a better product.
Radle 6mo ago
My repos for personal projects are split in two. One side contains code of better quality than I could write myself. The other side is throwaway vibe-coded shit that works somehow.
Witty0Gore 6mo ago
I think that generally creators being responsible for what they ship applies across the board. That doesn't change because AI has it's fingers in it.
nour833 6mo ago
Yeah many newbies are thinking that all ai generated code is safe while they can poison the next gen ai by training on wrong data.
0xnadr 6mo ago
This resonates. Smaller codebases are easier to audit, easier to maintain, and usually faster. The best code is the code you don't write.
globnomulous 6mo ago
I'm quite surprised by the negativity of the comments in this thread, especially contrasted with the positivity and enthusiasm I see in other threads. I'm an AI pessimist. I don't like it. I have resisted it. You'll find plenty of Rage against the Machine comments in my account history on Hacker News. The AI optimists drive me up the wall. And I can tell all of the nay-sayers in this thread, from first-hand experience, that the AI tools can be useful. When you use them well, they can save time. If you're writing just a dinky webapp for your "radio on the internet" startup, it can do a lot of grunt work. It's better auto completion, at a minimum. Last week I was struggling with an annoying, interlocking-race-condition/-stale-state bug. Fixing one issue kept reintroducing others that I'd just fixed. Skill issue, right? Right. And Clause 4.6 Opus diagnosed the problem and fixed it with just a little bit of coaxing. Then I asked it to fix another issue and it wound up chasing its tail, as it tried to apply the same principle to unrelated code with unrelated problems. Call these tools stochastic parrots. Call them autocorrect on steroids. Call them whatever you want. If you think they're worthless or have no use, you're living either in a fantasy land or in 2022 just after openai released its first, hilariously stupid chatbot.
- Pannoniae 6mo ago
  I think the unstated assumption here is that some of the criticism comes from different places. 1. what you have identified here, thinking they're useless 2. wanting them to be useless because they like the process of writing code itself, and AI makes that less important, so it's a form of wishful thinking. 3. having ethical concerns about AI, so they want it to fail. And part of that is dismissing their usefulness (after all, it's easier to get rid something which isn't that useful...) I personally find the third one quite fascinating -- like the cognitive dissonance about how the whole free software movement started out as a way to subvert copyright and nowadays they're almost the biggest defenders of it... but I do understand the reasoning here.
mary00114477 6mo ago
[dead]

169 points by orhunp_ 6mo ago

I’m working as a single solo developer of a tiny video game. I’m writing it in C with raylib. No coding assistants, no agents, not even a language server. I only work on it for a few hours during the week. And it’s progressing at a reasonable pace that I’m happy with. I got cross-compilation from Linux to Windows going early on in a couple of hours. Wasn’t that hard. I’ve had to rework parts of the code as I’ve progressed. I’ve had to live with decisions I made early on. It’s code. It’s fine. I don’t really understand the, “more, better, faster,” cachet to be honest. Writing the code hasn’t been the bottle neck to developing software for a long time. It’s usually the thinking that takes most of the time and if that goes away well… I dunno, that’s weird. I will understand it even less. Agree with writing less code though. The economics of throwing out 37k lines of code a week is… stupid in the extreme. If we get paid by the line we could’ve optimized for this long before LLM’s were invented. It’s not like more lines of code means more inventory to sell. It’s usually the opposite: the more bugs to fix, the more frustrated customers, the higher churn of exhausted developers.

anitil 6mo ago
I had a look at your github and blog but couldn't find the game, is it public? Or do I need to watch your streams to see it?
bdangubic 6mo ago
> Writing the code hasn’t been the bottle neck to developing software for a long time. I see this on HN just so much and I am not sure what this is, almost seems like a political slogan that followers keep repeating. I had to do some rough math in my head but in the last 5 years I have been involved with hiring roughly 40 SWEs. Every single one of them was hired because writing the code was THE bottleneck (the only one) and we needed more people to write the code
- ahefner 6mo ago
  But how much time per week does an SWE actually spend writing code?
  - bdangubic 6mo ago
    another one, this is 2nd most frequent thing people write here, not sure how to even approach answering :) so I’ll do what I was thought in first grade to never do and answer a question with a question - how much time per week does a brick layer spend laying bricks? they are looking at these new “robots” laying bricks automatically and talking on BrickLayerNews “man, the brick laying has not been a bottleneck for a long time.” But to answer your question directly, a lot of time if other people do their job well. Last week I had about 7 hours of meetings, the rest of the time I was coding (so say 35 hours) minus breaks I had to take to stretch and rest my eyes
    - paulhebert 6mo ago
      Interesting! I guess it really varies between jobs, roles, and companies. Thats never been my experience but I have an odd skill set that mixes design and dev. I’ve always spent a lot of time planning, designing, thinking, etc. How detailed are the tickets if you spend all your time coding? You never have to think through architecture, follow up on edge cases the ticket writers didn’t anticipate, help coworkers with their tasks, review code, etc.?
    - deleted 6mo ago
      [deleted]
    - apsurd 6mo ago
      i think this is it. you're a bricklayer. No, the bottleneck for erecting buildings is not bricklaying. Without taking all the time to write a dissertation to try to convince you, because why; how about we just start with even zoning laws and demographic analysis preclude the laying of the bricks. is it so unreasonable to think it is not about the laying of the bricks?
    - slopinthebag 6mo ago
brianwmunz 6mo ago
Honestly I think you can tell pretty quickly if a company or person is approaching AI from the viewpoint of accelerating development and innovation or just looking to do the same amount of work with less people. The space has been flooded by mean-spirited people who love the idea of developers becoming obsolete, which is a viewpoint that isn't working out for a lot of companies right now...many are already scrambling to rehire. Approaching the situation practically, integrating AI as a tool and accelerator is the much smarter way and if done right will pay for itself anyway.
- shimman 6mo ago
  Those mean spirited people are actually capitalists and they've been chasing the dream of perpetual labor since the 1800s.
20k 6mo ago
>I don’t really understand the, “more, better, faster,” cachet to be honest. Writing the code hasn’t been the bottle neck to developing software for a long time. It’s usually the thinking that takes most of the time and if that goes away well… I dunno, that’s weird. I will understand it even less. This is what I've always found confusing as well about this push for AI. The act of typing isn't the hard part - its understanding what's going on, and why you're doing it. Using AI to generate code is only faster if you try and skip that step - which leads to an inevitable disaster
- koolba 6mo ago
  > The act of typing isn't the hard part - its understanding what's going on, and why you're doing it. Using AI to generate code is only faster if you try and skip that step - which leads to an inevitable disaster It’s more than just typing though. A simple example remembering the exact incantation of CSS classes to style something that you can easily describe in plain English. Yes, you could look them up or maybe even memorize them. But there’s no way you can make wholesale changes to a layout faster than a machine. It lowers the cost for experimentation. A whole series of “what if this was…” can be answered with an implementation in minutes. Not a whole afternoon on one idea that you feel a sunk cost to keep.
  - sublinear 6mo ago
    This is not correct. CSS is the style rules for all rendering situations of that HTML, not just your single requirement that it "looks about right" in your narrow set of test cases. Nobody writing production CSS for a serious web page can avoid rewriting it. Nobody is memorizing anything. It's deeply intertwined with the requirements as they change. You will eventually be forced to review every line of it carefully as each new test is added or when the HTML is changed. No AI is doing that level of testing or has the training data to provide those answers. It sounds like you're better off not using a web page at all if this bothers you. This isn't a deficiency of CSS. It's the main feature. It's designed to provide tools that can cover all cases. If you only have one rendering case, you want an image. If you want to skip the code, you can just not write code. Create a mockup of images and hand it off to your web devs.
colechristensen 6mo ago
>Writing the code hasn’t been the bottle neck to developing software for a long time. Then we're doing different things. I didn't like GitHub so I wrote my own. 60k lines of code later... yes writing code was the bottleneck which has been eliminated. The bottleneck is now design, review, and quality assessments that can't be done trivially. This isn't even the project I wanted to be doing, the tools that were available were holding me back so I wrote my own. It also consumes a few hours a week. If you think writing code isn't the bottleneck then you aren't thinking big enough. If you don't WANT to think big enough, that's fine, I also do things for the joy of doing them.
- ozim 6mo ago
  We do different things, I do code for other people to use. Once we tried shipping features and updates every week, because we could ideate, code, test and deploy that fast. No user wanted that - product owners and business wanted that or they thought they wanted, until users came with torches and pitchforks. Don’t forget there is user adoption and education. Churning out features no one will use because they don’t know about is useless.
bitexploder 6mo ago
You can use LLM to write less code too. Just takes more intention. Which is kind of the whole point.
dpark 6mo ago
> Writing the code hasn’t been the bottle neck to developing software for a long time. It’s usually the thinking that takes most of the time Does your coding not involve thinking? And if not, why are you not delighted to have AI take that over? Writing unthinking boilerplate is tedious garbage work. Today I wanted to address a bug I found on a product I work on. At the intersection of platform migration and backwards compatibility I found some customers getting neither. I used an LLM to research the code paths and ensure that my understanding of the break was correct and what the potential side effects of my proposed fix would be. AI saved me stepping through code for hours to understand the side effects. I asked it for a nice description of the flow and it gave it to me, including the pieces I didn’t really know because I’d never even touched that code before. I could have done this. Would it have been a better use of my time than moving on to the next thing? Probably not. Stepping through function calls in an IDE is not my idea of good “thinking” work. Tracing through glue to understand how a magical property gets injected is a great job for a machine.
- lelanthran 6mo ago
  >> Writing the code hasn’t been the bottle neck to developing software for a long time. It’s usually the thinking that takes most of the time > I used an LLM to research the code paths and ensure that my understanding of the break was correct and what the potential side effects of my proposed fix would be. Using the LLM for understanding is very different to using the LLM for codegen. You are not really disagreeing with the author here; it's just that for the specific project he is talking about, he already understands it just fine so the advantages of LLM help in understanding is tiny.
  - dpark 6mo ago
    My point is that these are not separate activities. They are drawing a false distinction between thinking and coding and then asserting that code speed doesn’t matter and implying that AI only helps with the coding bit. None of this is actually true, though. Coding and thinking are often tightly intertwined, as rarely is the coding piece so straightforward that it requires no interesting thought. Coding speed does matter, even if it’s not the primary bottleneck for many things. And AI can be very helpful outside the context of pure coding.
throwaw12 6mo ago
> Writing the code hasn’t been the bottle neck to developing software for a long time It was! pre-2022 people needed developers to build software for them, now with platforms like Replit, Lovable - people are creating their own tiny software projects, which wasn't easily accessible in the past. If you say coding wasn't a bottleneck, then indirectly you could also say, you don't need developers. If you need developers, outcome of their other type of work (thinking, designing based on existing tools and so on) is actually CODE.
changyou 6mo ago
[dead]
ignoramous 6mo ago
> Writing the code hasn’t been the bottle neck to developing software for a long time. For who? There's no lack of professional programmers who couldn't clear FizzBuzz now coding up company-sized systems using Agents. This is all good as long as agents can stick to the spec/req & code it all up with decent enough abstractions... as the professional approving it is in no position to clue it on code organization or bugs or edge cases. I think, we (as a society) are looking at something akin to "reproducibility crisis" (software full of Heisenbugs) as such "vibe coded" systems get widely sold & deployed, 'cause the "pros" who excel at this are also good at... selling.
- agentultra 6mo ago
  Valid concern and one I share. If you’re going to vibe code up an operating system you will still need the experience and understanding of operating system fundamentals to have a chance at producing anything useful. The one-shot vibe-coded C compiler is a good example. Sure it created a compiler that could pass the basic tests. But it was no where near a plausible or useful compiler you’d use in a production system. Someone who knows compilers reviewed it and was able to prompt Claude or Gemini to fix the issues. But still… you’re not going to be able to do that unless you know what to look for. On an enterprise development team doing boring, Line of Business software? Might have a chance at rolling the dice and trusting the agents and tests and processes to catch stuff for you but I’d still be worried about people who don’t know what questions to ask or have deep expertise to know what is “good,” etc.
  - daotoad 6mo ago
    The gap between quality work and baseline LLM output is precisely the understanding. If it can be validated by automation, the bot will do it. But no automation suite is complete or perfect. What concerns me is that building software using the LLMs gives a distance that inhibits the formation of the sort of understanding I need to "just know" a code base intuitively. So when product asks for a feature, my ability to be sufficiently pedantic about the 6 different non-obvious things this impacts is less effective. And when I need to choose abstractions and try to form an effective ontology, my intuition is less effective. I believe I can still grind out an effective solution, but I start farther from the finish line. Does the LLM's ability to "answer questions" about the codebase make up for my lack of intuition? Does my apparent ability to run faster make up for the fact that I am starting farther from the end of the race? I don't know yet.
hnthrowaway0315 6mo ago
“more, better, faster,” I have heard these words, almost verbatim, from manager-yes-men coming from a FAANG background, and surprisingly concentrated in a certain demography (if someone find this offensive, I'll remove this part). My CTO wants us to "deliver as fast as possible", and my VP wants us to "go much faster, and more ownership". "Better" or anything related with quality was definitely mentioned, too, but always at a second place. To this day, I consider these yes-men to be a major red flag, so I always tried to probe for such information during interviews.
- drekipus 6mo ago
  I'm interested in how you're probing for them? I haven't needed to change jobs but I'm worried that one day I'll have to
  - hnthrowaway0315 6mo ago
    Just ask along the line "Do you have someone from FAANG as a director/VP? Because I have worked with a few and really loved the learning process" and do a bit of research once you know the name of the hiring manager.
YesBox 6mo ago
I've been developing a moderately popular (for an indie) game for over 4 years at this point (full time). C++, SFML, SQLite. Same as you: no coding assistants, no agents, etc. I also don't use git. [1] One of the largest speedups is from how much of the codebase I can keep in my head. Because I started from an empty C++ file, the engine reflects how I reason and organize concepts (lossless compression). Thus most of the codebase is in my brains RAM. I don't see how LLM agents are going to improve my productivity in the long run. The less a person understands their code (organized logic), the more abstracted the conversation is going to become when directing an agent. The higher up the abstraction ladder you go, the less distinct your product becomes. [1] And very, very rarely have I wished I had it for a moment. Not using git simplifies abstracted parts of development. No branches, no ballooning of conceptual tangents, etc. Focus on one thing at a time. Daily backups and a log of what I worked on for the day suffices should I need to revisit/remember earlier changes. I've never been in a situation where I change I made over a week ago interfered with todays work.
- agentultra 6mo ago
  I definitely feel like understanding the system is a big part of what makes it relatively easy to maintain/understand. My game is just in my spare time while I'm looking for work and the scope of the project is small so that I can finish it, release it, and start working on the next one. I'm not trying to build an engine or anything. Just a game. Not even the best game I can make. I can iterate on it fast because I know the structures. I can refactor it fast because I've built an intuition for a process over time that keeps code amenable to changes over time. I know I'm not going to make the right decisions at the start so I avoid committing to generalizations, etc. Editing code is pretty fast for me. Again, years working with a particular setup. I still have expandable snippets, multi-cursor editing and a host of macros for common editing motions. Checking changes... pretty fast. I'm getting to the point where I might invest in using dynamic reloading for my in-development builds. I suspect it will take a few hours to do at most. Not a big deal. For now I have a basic system that just watches for file changes and recompiles/re-runs the program. In a different context, working on a team in a large multi-million line codebase... I dunno what other people find it's like but I've never found it terribly slow to write/edit code or ship features. I can usually knock most tasks out at a reasonable pace especially when my familiarity with the area of the code I'm working in increases. I usually find my priorities shift with the demands of users, the business, etc. Some times I work on shipping new features quick. Other times it's making sure what we ship the right things and done well so that we don't leak PII. Either way... actually writing the code isn't the slowest part, in my experience. It's all the other stuff: the meetings, the design, maintenance, documentation, understanding the problem domain, actually shipping the code to production, etc that takes up the most time for me.
pdimitar 6mo ago
This: > I don’t really understand the, “more, better, faster,” cachet to be honest And this: > I’m working as a single solo developer ...I believe explain it all here. You likely are not beholden to PMs, CEOs and the like. Of course you can go at your own pace. I am actually puzzled that you don't understand that aspect yourself. > The economics of throwing out 37k lines of code a week is… stupid in the extreme Again, bosses. CEOs have 14 calls a week with potential prospects and sometimes want demos, sometimes they sign quickly and want a prototype, and sometimes they arrange a collab with a friend or family. Then 3 weeks later the whole thing falls apart and you have to throw it away because it's getting in the way of delivering what actually still pays the bills. I am not the CEO. I try making his visions come true. I don't get to make the calls on whether 37k of lines will be quickly churned out and then deleted some weeks later. I think your comment is overly focused only on the coding/programming aspect of things. We don't exist in a vacuum. May I ask how do you make your living? That might shed extra light on your trouble understanding the inevitable churn when writing code for money. --- All of this does not even mention the fact that I 100% agree that less coding lines == less trouble. Code is generally a liability, I believe every mature dev understands that. But often we are not given a choice so we have to produce more code and periodically compress it / re-architect it (while never making the mistake of asking to be given time to do so because we never will).
quacker 6mo ago
Writing the code hasn’t been the bottle neck to developing software for a long time. Code may not be the bottleneck, but writing it absolutely does consume time. Especially with solo game dev, I can prototype ideas, try them out, and then refine or scrap them at a rate I could never do without AI. This type of experimentation is a perfect use-case for AI. It’s actually super fun, and if I pay attention and give the AI decent instructions, I don’t really lose out on code quality.
h4kunamata 6mo ago
>I don’t really understand the, “more, better, faster,” cachet to be honest Numbers, it is all about numbers. I have worked in a company where one release a week would drive the managers insane, by them we should have one release every minute. Things break all the time because in order to deploy faster and faster, corners were cut and now one of the most visited online pet store in the country is down :)

stratts 6mo ago

It was always possible to write large amounts of crappy code if you were motivated or clueless enough (see https://github.com/radian-software/TerrariaClone https://github.com/radian-software/TerrariaClone). It's now just easier, and the consequences less severe, as the agent has code comprehension superpowers and will happily extend your mud ball of a codebase. There are still consequences, however. Even with an agent, development slows, cost increases, bugs emerge at a higher rate, etc. It's still beneficial to focus on code quality instead of raw output. I don't think this is limited writing it yourself, mind - but you need to actually have an understanding of what's being generated so you can critique and improve it. Personally, I've found the accessibility aspect to be the most beneficial. I'm not always writing more code, but I can do much more of it on my phone, just prompting the agent, which has been so freeing. I don't feel this is talked about enough!

Kiyo-Lynn 6mo ago

[dead]

qudat 6mo ago

A similar post with more emphasis on validating changes: https://bower.sh/thinking-slow-writing-fast https://bower.sh/thinking-slow-writing-fast

chillaranand 6mo ago

For various internal tools & other projects, I started using config only tools and avoid code as much as possible. https://avilpage.com/2026/03/config-first-tools.html https://avilpage.com/2026/03/config-first-tools.html

dgb23 6mo ago
I like this. Thanks for sharing. I think "config first" is an understatement. The more general term here is "data driven". It's sort of obvious that agents are way better and faster when writing data that can be validated easily against a schema and understood and reviewed in far less time. Data driven also gives you leverage, because it is far easier to for a program to produce data than code. The same applies to humans as well. Sort of ironic that we are now rediscovering and celebrating robust approaches like writing well designed CLIs, data driven programming, actionable error messages and good documentation. Maybe AI agents are a sort of reality check or even evolutionary pressure that forces us to do the right things.

osm3000 6mo ago

I am a machine learning engineer. I've been in the domain almost 12 years now (different titles and roles). In my current role (and by no means that is unique), I don't know how to write less code. Here are problems I am facing: - DS generating a lot of code - Managers who have therapy sessions with Gemini, and in which their ideas have been validated - No governance on DS (you want this package? import it) - No governance on Infrastructure (I spent a couple of months upskilling in a pipeline technology that were using: reading documentation and creating examples, until I became very good it...just for the whole tech to be ditched) - Libraries and tools that have been documentation, or too complex (GCP for example) The cognitive overload is immense. Back few years ago, when I was doing my PhD, immersing in PyTorch and Scipy stack had a huge return on investment. Now, I don't feel it. So, how do I even write less code? Slowly, I am succumbing to the fact that my tools and methods are inappropriate. I am steadily shifting towards offloading this to Claude and its likings. Is it introducing risks? For sure. It's going to be a disaster at one point. But I don't know what to do. Do I need a better abstraction? Different way to think about it? No clue

__mharrison__ 6mo ago
I've seen some success teaching data scientists how to write better code. SWE concepts like modularity, testing, and refuse. Things that they normally ignore or choose to throw out the window. (Disclosure: I'm a corporate trainer)
- osm3000 6mo ago
  I appreciate that. I am not a position though to advocate for such a change :)
  - maigret 5mo ago
    Not yet, maybe.
rwmj 6mo ago
What is DS?

gbro3n 6mo ago

My current take is that AI is helping me experiment much faster. I can get less involved with the parts of an application that matter less and focus more (manually) on the parts that do. I agree with a lot of the sentiment here - even with the best intentions of reviewing every line of AI code, when it works well and I'm working fast on low stakes functionality, that sometimes doesn't happen. This can be offset however by using AI efficiencies to maintain better test coverage than I would by hand (unit and e2e), having documentation updated with assistance and having diagrams maintained to help me review. There are still some annoyances, when the AI struggles with seemingly simple issues, but I think that we all have to admit that programming was difficult, and quality issues existed before AI.

jsxyzb 6mo ago

[dead]

bob1029 6mo ago

> Nowadays many people are pushing AI-assisted code, some of them in a responsible way, some of them not. So... what do we do? You hold them accountable. Once upon a time we used to fire people from their jobs for doing things poorly. Perhaps we could return to something approximating this model.

voidUpdate 6mo ago

I'm not entirely sure I can trust the opinions of someone on LLMs when their blog is sponsored by an AI company. Am I not simply seeing the opinions that the AI company is paying for?

AlexSalikov 6mo ago

Good framing. I’d add that “be responsible” extends well beyond code quality - it’s about product responsibility. AI making code cheaper to produce doesn’t make the decisions around it any cheaper. What to build, for whom, and why — that’s still fully on you. It should free up more time for strategy, user understanding, and saying “no” to things that shouldn’t exist regardless of how easy they are to ship. The maintainability concern Orhun raises is real, but I think the root cause isn’t AI — it’s ownership. If you don’t understand what was built, you can’t evolve it. It’s the same failure mode as a PM who doesn’t grasp the technical implementation — they end up proposing expensive features that fight the architecture instead of working with it. Eventually, someone has to pay for that disconnect, and it’s usually the team

andai 6mo ago

After experimenting with various approaches, I arrived at Power Coding (like Power Armor). This requires: - small codebases (whole thing is injected into context) - small, fast models (so it's realtime) - a custom harness (cause everything I tried sucks, takes 10 seconds to load half my program into context instead of just doing it at startup lmao) The result is interactive, realtime, doesn't break flow (no waiting for "AI compile", small models are very fast now), and most importantly: active, not passive. I make many small changes. The changes are small, so small models can handle them. The changes are small, so my brain can handle them. I describe what I want, so I am driving. The mental model stays synced continuously. Life is good.

shevy-java 6mo ago

> So you are saying that the quality of the projects is going down? The website seems to at the least be semi-generated via AI. But I think the statement that the quality of many projects went downwards, is true. I am not saying all projects became worse, per se, but if you, say, search for some project these days, often you land on a github page only. Or primarily. How is the documentation there? Usually there is README.md and some projects have useful documentation. But in most cases that I found, open source projects really have incredibly poor documentation for the most part. Documentation is not code, so the code could be great, but I am increasingly noticing that even if the code gets better, the documentation just gets worse; rarely updated, if at all. Even when you file requests for specific improvements, often there is no response or change, probably because the author just lacks time to do so, anyway. But I am also seeing that the code also gets worse. AI generated slop is often unreadable and unmaintainable. I have even recently seen AI spam slop used on mailing lists - look here: https://lists.ffmpeg.org/archives/list/ffmpeg-devel@ffmpeg.org/thread/W36Z3IDH6ZQ55CKFJ6KRJZCS5NJBNFL3/ https://lists.ffmpeg.org/archives/list/ffmpeg-devel@ffmpeg.o... Michael Niedermayer does not seem to understand why AI slop is a problem. One comment reveals that. I don't read mailing lists myself really (never was able to keep up with traffic) but I would be pissed to no ends if AI spam like that would land into my mailbox and waste my time. Yet the people who use AI spam, don't seem to understand mentally why that is a problem. This is interesting. They suddenly think spam is ok if AI generated it. So the overall trend is that quality goes down more and more. Not in all projects but in many of them.

philipwhiuk 6mo ago

> It's something ethical that I don't know the answer to. In my case, it was the guy's first ever open source project and he understandably went for the quickest way of creating an app. While I appreciate their contribution to open source, they should be responsible for the quality of what they put out there. Pitching this is the exact opposite of the maintainer burden of expectation. > Sometimes I discover a project that is truly wonderful but visibly vibe-coded. I start using it without the guarantee of next release not running rm -rf and wipe my system. For me this is on you, not the developer.

travelalberta 6mo ago

Code Complete came out in '93 and even then they acknowledge most of the work around development wasn't actually programming but architecture, requirements, and design. Sure you can let Claude have a field day and churn out whatever you want but the question is: a) Did you read the diffs and provide the necessary oversight to make sure it actually does what you want properly, b) Is the feature actually useful? If you've worked on legacy systems you know there's so much garbage floating around that the bar isn't that high generally for code as long as it seems to work. If you read the code and documentation Claude makes thoroughly and aren't blindly accepting every commit there is not really a problem as long as you are responsible and can put your stamp of approval on it. If you are pushing garbage through it doesn't matter if a junior dev, yourself, or Claude wrote it, the problem isn't the code but your CI/CD process. I think the problem is expectations. I know some devs at 'AI-native' organizations that have Claude do a lot for them. Which is fine, for a lot of boiler plate or standard requests they can now ship 2X code. The problem is the expectation is now that they ship 2X code. I think if you leave timelines relatively the same as pre-AI then having an agent generate, document, refactor, test, and evaluate code with you can lead to a better product.

Radle 6mo ago

My repos for personal projects are split in two. One side contains code of better quality than I could write myself. The other side is throwaway vibe-coded shit that works somehow.

Witty0Gore 6mo ago

I think that generally creators being responsible for what they ship applies across the board. That doesn't change because AI has it's fingers in it.

nour833 6mo ago

Yeah many newbies are thinking that all ai generated code is safe while they can poison the next gen ai by training on wrong data.

0xnadr 6mo ago

This resonates. Smaller codebases are easier to audit, easier to maintain, and usually faster. The best code is the code you don't write.

globnomulous 6mo ago

I'm quite surprised by the negativity of the comments in this thread, especially contrasted with the positivity and enthusiasm I see in other threads. I'm an AI pessimist. I don't like it. I have resisted it. You'll find plenty of Rage against the Machine comments in my account history on Hacker News. The AI optimists drive me up the wall. And I can tell all of the nay-sayers in this thread, from first-hand experience, that the AI tools can be useful. When you use them well, they can save time. If you're writing just a dinky webapp for your "radio on the internet" startup, it can do a lot of grunt work. It's better auto completion, at a minimum. Last week I was struggling with an annoying, interlocking-race-condition/-stale-state bug. Fixing one issue kept reintroducing others that I'd just fixed. Skill issue, right? Right. And Clause 4.6 Opus diagnosed the problem and fixed it with just a little bit of coaxing. Then I asked it to fix another issue and it wound up chasing its tail, as it tried to apply the same principle to unrelated code with unrelated problems. Call these tools stochastic parrots. Call them autocorrect on steroids. Call them whatever you want. If you think they're worthless or have no use, you're living either in a fantasy land or in 2022 just after openai released its first, hilariously stupid chatbot.

Pannoniae 6mo ago
I think the unstated assumption here is that some of the criticism comes from different places. 1. what you have identified here, thinking they're useless 2. wanting them to be useless because they like the process of writing code itself, and AI makes that less important, so it's a form of wishful thinking. 3. having ethical concerns about AI, so they want it to fail. And part of that is dismissing their usefulness (after all, it's easier to get rid something which isn't that useful...) I personally find the third one quite fascinating -- like the cognitive dissonance about how the whole free software movement started out as a way to subvert copyright and nowadays they're almost the biggest defenders of it... but I do understand the reasoning here.

mary00114477 6mo ago

[dead]