13 ms·

Using AI to write better code more slowly

• chengyongru 5mo ago
  [flagged]
• whyfire-9326 5mo ago
  [flagged]
• kiba 5mo ago
  I used LLM as a tutor to tackle unfamiliar terrain. That is, I write code that I know very likely doesn't work but is the best code that I could have written. The LLM will happily tirelessly show me what I did wrong and what the correct code actually look like. Then, at the end of it, I got code that running. That's a tight feedback loop. It's still very slow. It took me two hours to write code that generate JSON data and then to write a web page that displays a knowledge graph. One thing you have to be aware is that the LLM will happily generate code for you and you have to discipline it from time to time. I notice that my reading comprehension begins to suffer if I don't write the code myself and have to understand what the LLM wrote for me as opposed to the LLM correcting where I went wrong. One thing I would like to try with an LLM is understanding a large and complex existing codebase like OpenSCAD that doesn't leverage my existing skillset(high level programming languages with OpenSCAD as primary language in the past year). That has always been a barrier to contribution for me.
• seblon 5mo ago
  I want to mention, Claude code has a command /code-review. I find it quiet useful.
• bottlepalm 5mo ago
  I've hit this point with AI where it's not a simple process, but a long drawn out back and forth. I'll use AI to design the implementation of a medium sized, cross cutting feature. Review all the details, maybe iterate on just that. Then implement with Claude 4.7 Max - which runs slower, but does a better job. Then review the implementation, then have Codex GPT 5.5 xhigh fast review it - which almost always finds corner cases. Have Claude fix those - Claude is better at writing intuitive maintainable code versus Codex overengineered/shortcut filled code. (Codex is better at finding/fixing bugs and doing reviews - it's annoyingly pedantic) Then repeat with fresh Claude/Codex instances having them both review the current staged changes and getting feedback, handling the feedback. Then covering it in tests. I mean overall I still implement the feature faster than coding it manually, but I spend a majority of the time going back and forth with reviews, handling corner cases and at the finish end up with what I feel a really solid implementation of whatever feature I'm working on. The v1 feature feels more like a v3 given the amount of iteration it already went through.
  • rootnod3 5mo ago
    And then Anthropic has an outage and you what...have a coffee break until then? All that time babysitting the AIs just to be a little faster but probably with less knowledge/control over what they did?
    • bottlepalm 5mo ago
      As the AI is working, I am working - reviewing, regression testing, thinking about if the currently implementation is too complex and how to simplify it etc.. I totally review and understand everything the AI is generating and often push back, have it re-do something, or do it myself. In the end I feel like the quality of the work is at a v3 level in the time it took to do a v1. The productivity and quality increase is real.
    • comradesmith 5mo ago
      I’ll deal with that problem when it happens
    • afavour 5mo ago
      I don’t think you’re quite getting what OP is describing. I work in a similar way… I am aware of all the code being written. If Claude had an outage I could write it myself. It would just take longer. You say “all that time” babysitting AIs but in my experience it isn’t that much time, if anything the back and forth at the planning stages is more productive than when I’m doing it by myself because I’m being asked questions and having to think things through from different angles.
      • halfcat 5mo ago
        How do you stay aware of all code being written? Maybe it’s just me, but I’ve never understood how one understands from reading code. Yes you can understand what that code does, but not why it was done that way instead of a different way. In the end I only understand it deeply if I end up writing it. Chatting through it is helpful to me, but having AI crank out code loses all of that context pretty quickly. I’m not disagreeing. Just curious how you think about this, and if there are key parts of your process that help you stay contexted in.
• npollock 5mo ago
  learn by considering critique
• alasano 5mo ago
  Instead of using a skill and having the agent own the flow for this, I've been building an external orchestrator that handles the process. By default it uses pi agent core + pi ai (from the excellent pi coding agent) as a multi model runtime but also supports a Claude Agent SDK runtime. I can have an implementation and review process of an OpenSpec change run anywhere from 2 hours to 24+ hours going through review/fix/verification rounds automatically until the implementation matches the spec and any additional reviewers are done finding issues after the fix rounds. it's going to be fully open sourced in the next two weeks and fully free to use https://engine.build https://engine.build
  • whattheheckheck 5mo ago
    Maybe we can come up with an spec for aligning asci diagrams. Can't really build anything with confidence when the attention to detail is lacking in these agentic systems https://imgur.com/a/r4fhOwy https://imgur.com/a/r4fhOwy
    • alasano 5mo ago
      What's that from? OpenSpec docs?
      • whattheheckheck 5mo ago
        Yeah not trying to pick on any particular project because its quite the mark that the writer didn't proof read the documentation and its quite widespread
    • tudelo 5mo ago
      It's interesting... Opus seems horrible at keeping text aligned. Markdown it is I suppose
• smusamashah 5mo ago
  Title of this article suggested more depth and I was expecting actual code examples. But it is like other opinion pieces. It suggests a prompt (ask AI to find bugs) that works for the author advising everyone to do it that way. I use these tools at both work and for personal side projects and I was expecting to watch and learn. But these opinion pieces without examples are way too many now.
  • vessenes 5mo ago
    Have you tried his suggested workflow? I think it's a useful workflow, and if I hadn't found a workflow like this already would appreciate the pointer. I guess he could write a code harness to do this, or gin one up really quickly, but that kind of tooling today seems like the purview of the practitioner -- you -- it's frankly faster for you to spec what you want to try this idea out if you want it automated than it would likely be to deal with his code.
• ptlan_asnh 5mo ago
  How profound! Talking points are changing from "vibe coding delivers bug free software" to "slow down and enjoy the AI". Great how the promoters are mirroring the current anti-AI sentiment. The next step is canceling all subscriptions and not using AI at all. Maybe your mind will work again.
  • CuriouslyC 5mo ago
    Not so much. People are just walking things back from the Gastown/Oh My Opencode/etc peak of trying to get 10 agents working simultaneously on a project unsupervised. They've collectively realized that you still have to understand and validate what the agents produce in some way if you want to build maintainable software.
• crabmusket 5mo ago
  The linked article about getting LLMs to critique each others' code review[1], the magpie tool[2], and also this recent article from Cloudflare about their code review stack[3] are all quite compelling. I'm fairly AI-skeptical not on grounds of "do they work" but "are they good for the world". I feel that getting AIs to do this kind of review work is a rare case that doesn't outsource thinking and deskill workers. It doesn't trigger the same alarm bells as having the AI write the code (including having the AI fix the issues it discovers). That's setting aside environmental and other ethical concerns, which are still significant to me. I have been impressed by the recent quality of AI code reviews*, but the experience of interacting with 3 separate AI reviewers via GitHub PRs is pretty terrible. Having more local-oriented and jj/rebase-aware review rounds would be great. *context: fairly large PHP/Laravel backend and Vue frontend [1]: https://milvus.io/blog/ai-code-review-gets-better-when-models-debate-claude-vs-gemini-vs-codex-vs-qwen-vs-minimax.md https://milvus.io/blog/ai-code-review-gets-better-when-model... [2]: https://github.com/liliu-z/magpie https://github.com/liliu-z/magpie [3]: https://blog.cloudflare.com/ai-code-review/ https://blog.cloudflare.com/ai-code-review/
• slopinthebag 5mo ago
  I use cheaper models (Deepseek is king, but GLM and Kimi as well) and do the planning myself. I often start a task myself, write some code to get the LLM on the right track, and then have it complete parts of the implementation that are kind of boring or repetitive. LLM's are just next token predictors, I don't mean that in a demeaning way, but I've found if I can get the LLM started on the right track with my own code, it completes what I want. Having the LLM write code just from a spec ends up with poor quality slop in my experience. I'm not 100x'ing my output like some people claim, but using it as a augmentation rather than delegating my work to it results in better code, and I don't lose context / control over my codebases. I really have read 100% of the code, because the LLM is generating smaller pieces around and inside my own written code. Works well enough for me, and open models are already both cheap enough and good enough for this workflow. This is why the big companies are so desperate to push full-on agentic hands-off workflows and developer replacement - that's the only way they won't go bankrupt.
  • foo12bar 5mo ago
    What app do you use with deepseek? I've been used claude code but pointing it at the deepseek api and it works ok, but I'm wondering if there are better options. (https://api-docs.deepseek.com/quick_start/agent_integrations/claude_code https://api-docs.deepseek.com/quick_start/agent_integrations...)
    • slopinthebag 5mo ago
      I've been using Zed and Charm Crush. I think most work with it though, any agent designed around OpenAI completions API compat will do fine. Although Zed had some problems initially with tool calls but it seems to be fixed. I'm working on my own harness to be a bit more aligned with my workflow but tbh I'm losing motivation since other harnesses are fine now. I could probably vibe code something but there's not much point imo. Unless I come up with something completely different but who knows. I think there is a Deepseek agent out there in Rust, but I've never tried it. Zed has been pretty decent with all models, not the best but certainly beats VSCode. ChatGPT 5.4 on that calls about 100 different git diffs to "verify" the changes are valid which is rubbish. I haven't tried Deepseek with it though. Honestly these models and agents are becoming commodities, as long as they don't totally fail with tool calling or some stupid system instructions the models can figure stuff out pretty well.
• justinlivi 5mo ago
  I find myself spending on average more time in LLM review/resolution loops than it would take for me to write the code by hand. Partially because once I'm in the flow I write very very quickly and the code pours out sometimes faster than I can write. But also because the LLM code on the first few tries is generally really really bad. What I find interesting though is that spending the time to personally review and direct the LLM through several iterations of review and revision on average results in higher quality code written in about the same time as I would have written it. This might be particular to me, but seeing several interations of someone else's code helps me better understand holistically my objective as opposed to whatever happens to come out of my flow-state consciousness.
  • zik 5mo ago
    If your AI is writing bad code then you need to change your AI. No current high-end AI should be producing bad code.
    • th0ma5 5mo ago
      [dead]
    • newsicanuse 5mo ago
      Source trust me bro.
    • singingtoday 5mo ago
      The tool is important but then so it's the way you use it. I've seen small LLMs produce good code and frontier LLMs produce poor quality code. Depending on context..
    • redeye100 5mo ago
      This sounds like a subjective assessment. I counter with the opinion that most LLMs write technically correct, but bad code. When I read it, it makes me want to gag or poke my eyes out. I spend a lot of time wondering about what kind of person would write it like that, then I realize it’s an LLM
    • 5mo ago
• jdw64 5mo ago
  [dead]
• syntaxing 5mo ago
  Hot take, barring from special edge cases, I find using dumber models (like local Qwen 3.6) to be the best balance. Smart enough to do stuff but dumb enough where I don’t trust it and verify what it’s doing rather than letting it do the third whole code base refactoring of the day. Also forces me to know my code base and ask very descriptive tasks rather than go “something is wrong, fix it”.
• vessenes 5mo ago
  One thing that's been interesting to me over the last few years is charting the edge of my coding laziness. As a coder, I'm lazy about boilerplate code -- I hate writing it, I hate maintaining it, etc. And so I design and architect (or used to) around that preference. Sometimes that's smart, sometimes that's not. But it was my preference, and I avoided something that was hard for me to do. When LLMs started being somewhat useful for coding a few years ago, and I found they were in fact great at boilerplate, in fact pretty much only good at boilerplate ca 2023 or so, it got me thinking about all the accommodations we make in design and systems architecture that are sort of tacitly understanding who we're working with and their strengths and weaknesses. The modern models have their own very different strengths and weaknesses compared to humans, and deploying them is a really interesting exercise of different architectural and engineering skills. I've enjoyed it, and hope I continue to.
  • foobarbecue 5mo ago
    The thing about boilerplate is that a good library or framework makes it optional, and / or automatically written. I'd much rather django-admin startproject, npm init, or meteor create and get deterministic output than prompt an LLM and get who knows what. In a mature web ecosystem, boilerplate is minimal. I worry now that we've given this task to LLMs, less development effort will go into startproject-esqe CLIs and good opinionated defaults.
    • ehnto 5mo ago
      I wonder this in general, what's the impetus for writing new frameworks and such? Are we already seeing a slow down in that space? HN front page certainly paints that picture. You're better off plonking down an existing framework and getting all the structural boilerplate benefits the LLM can leverage. LLMs are far better at frameworks they have a lot of training data for, if have been around for a while. They write more idiomatic, ecosystem friendly code. Does that still matter?
    • zahlman 5mo ago
      I feel like, if an LLM can one-shot a say 500 LOC project from a single-line prompt, and doesn't require the user to make any choices, and the result is actually acceptable, then 499 of those LOC are definitionally "boilerplate". They have been demonstrated, by this process, to have no more design-information content than the prompt, except perhaps a few constants where effectively random / statistically likely values were good enough. > In a mature web ecosystem, boilerplate is minimal. I don't think I even have words for my level of disagreement here. > I worry now that we've given this task to LLMs, less development effort will go into startproject-esqe CLIs and good opinionated defaults. I certainly hope not. I feel like an LLM-powered project could very much benefit from having those kinds of pieces to work with.
• zhxiaoliang 5mo ago
  [dead]
• TACIXAT 5mo ago
  This article doesn't address writing code with AI, just code review. My issue with agentic coding is that I make numerous micro-architectural decisions while programming. I almost never have a full spec up front and develop one as I consider what I am writing. When using Claude Code or Codex, that is all gone. Claude Code is extremely eager to reach the end goal to the point that it feels like a fever dream to write code with it. In the end, I have low confidence about edge cases and fit into the project's architectural and design goals. On top of that, I enjoy programming, reverse engineering, etc. and I feel that the LLMs, while able to solve some problems or deliver some features, take that fun away. I'm trying really hard to find a workflow with them that I'm confident in, but I fear that workflow is just chat, search, and being a rubber duck for my thoughts.
  • teaearlgraycold 5mo ago
    A lot of programming work is well represented in the training data. For that kind of stuff there’s not much to do regarding architectural decisions. I love to run the LLMs on auto for that work. But for anything not well represented in the training data, which could be anything from mundane stuff in PyQT or a truly novel application, keep them on a short leash or forget them altogether.
    • redeye100 5mo ago
      > represented in the training data This isn’t a binary is/isn’t thing though. What if only 80% of my task is, how would I know that the other part isn’t, if I haven’t worked it through fully What if my task is generally represented, but for my specific context, there are specific details that aren’t? How would I know until I’ve reasoned through it myself? At that point having the LLM do the work doesn’t add much value
  • aakresearch 5mo ago
    > I fear that workflow is just chat, search, and being a rubber duck for my thoughts This is exactly what I settled upon after my own trying really hard. It is liberating, I have no fear at all!
  • 5mo ago
• efitz 5mo ago
  Great article and right on point.
• EFLKumo 5mo ago
  https://news.ycombinator.com/item?id=48246232 https://news.ycombinator.com/item?id=48246232 This reminds me the article above. Now people have diverse ideas on agentic coding. Some suggest human-in-the-loop while others suggest giving a detailed specification and let the agent run freely; some suggest leveraging LLM's high productivity and here we get an opinion that LLM can actually slowly write good code. It's happy to see opinions that are more practical and variant emerging, turning LLM into literally a tool instead of something to be hated or hyped. In my own practice, I find LLMs (SOTA ones) good at medium-level tasks, those needed to reason and plan for a while. However, the design taste on architecture is unexpectedly disgusting. Sometimes writing interfaces myself and asking LLMs to fill in implementations, alongside context-completing tools like context7, deepwiki, docs.rs MCPs, etc. and giving a escape hatch (e.g. encouraging it to use the AskUser tool in Claude Code), may be considered my best practice.
• ai_fry_ur_brain 5mo ago
  Just dont use it lol, it does nothing you cant do by yourself. You're nerfing parts of your brain by relying on it.
  • ianm218 5mo ago
    There is things you really can't do by yourself. I've been working on porting some large codebases to Rust lately to experiment with fixing memory safety bugs. There is just no way you can write 100k LOC in a week of production code with tons of tests etc. Even "10X" engineers just can't type that fast.
    • halfcat 5mo ago
      How would one even know if the port of 100k LOC was successful? Are there language-agnostic tests (CLI STDIN/STDOUT) or similar involved?
      • bigfishrunning 5mo ago
        Vibes, man!
      • ianm218 5mo ago
        I was using large official test suites + lots of tests I generated that test input/ output is byte identical over thousands of commands. You wouldn’t want to ship it straight to prod but it’s a start.
    • ultimaweapon 5mo ago
      What language you are trying to port from?
      • ianm218 5mo ago
        C to Rust. c2rust exists but isn’t particularly helpful if you want it to be safe/ performant code anyway.
    • 5mo ago
• knuckle 5mo ago
  Stop being reasonable! This is a hypecycle!
• reactordev 5mo ago
  This is the approach I take, with many guardrails and nested CLAUDE.md's to keep things sane.
• tonymet 5mo ago
  Are we overcomplicating AI by approaching top down, so naturally there are trillions of variations and too many ways to fail? Supervising a component-level scope, with emphasis on quality control (regression, perf testing, benchmarking, etc), seems to produce great work.
• Waterluvian 5mo ago
  I think my current conclusion is that AI makes <foo> more important than ever. I’m not exactly sure what <foo> is but I feel it. I think it’s quality and authenticity and craftsmanship. That difference between an expensive tool and a cheap one that you can’t easily describe but you just know it. Is there a word for this? I bet the Japanese or Germans have a word for this. I use AI a lot now. But I also do it in small steps. It isn’t a craftsman, but it can help me be one.
  • samrus 5mo ago
    People use the word "taste" to describe that
    • Waterluvian 5mo ago
      Yeah, maybe that. I feel like AI promises a factory that can make Walmart quality tools. Which I think will make the well-crafted tools more important than ever.
  • datadrivenangel 5mo ago
    Quality as Pirsig would say in Zen and the Art of Motorcycle maintenance.
• ElenaDaibunny 5mo ago
  The bug-finding use case alone makes this worth it.
• themanmaran 5mo ago
  As I read this, I'm also working through a pretty dense feature that took a fair bit of iteration. The end result is actually significantly less code than it was about halfway through. And I was wondering if the AI actually helped me at all, since surely I could have written the code in the same time it took to iterate But! Because of AI I was able to rapidly hack out like 4 variants of this feature that I didn't like. And felt comfortable throwing them away just as quick.
  • a_victorp 5mo ago
    This has been one the most significant improvements of using AI for me. Before I would have to really think through the plan of a new feature before committing to the implementation and would only catch incompatibilities with existing code after a good portion of the implementation was already written. Now I can ask AI for detailed implementation plans and find these nitty gritty detail problems in a few hours if not less
  • halfcat 5mo ago
    So what’s the verdict? Was it worth it?
    • themanmaran 5mo ago
      Yea worth it. The original implementation ended up being the most complex, and also not a great UX. But I didn't really get it was a worse UX until I built it and tested it out a bit. And I wasn't attached to that complex implementation in the way I would be if I architected it from scratch, so it was easy to move on.
  • sharaththegeek 5mo ago
    True. I think this is the biggest help with AI. It does not necessarily help with reaching the end goal faster all the time but it helps in trying out different iterations for quick prototypes. I find it especially useful in fast moving startups where some times we just want to validate a few ideas before fleshing them out as proper features.
  • 5mo ago
• xuanlin314 5mo ago
  [flagged]
• boringstack 5mo ago
  Optimizing for code quality over raw output speed is a great approach. The time 'lost' writing it slowly is easily made up by the time saved on debugging and maintenance later.
• nibblecid 5mo ago
  [flagged]
• anuis258 5mo ago
  hmmm
• sreekanth850 5mo ago
  100% agree after building a production ready platform ground up. it took 3-4 months but without AI i would never had been done with a team of 3. one thing to note that AI is weak at Front end. So, we did the entire front end without AI.
• Lapsa 5mo ago
  [dead]
• hintymad 5mo ago
  On the other hand, some companies are pushing the idea that engineers should build robust self-evaluating agent pipeline with human feedback in the loop so that agents write most of the production code. Creao's CEO said that they rearchitected their entire production systems in two weeks this January. He also claimed that their agents implemented so many features so fast that they had to wait their business development to catch up. I wonder how we can evaluate these two options: using AI to 100X the output versus using AI to advance one's craft. In the meantime, the productivity gain of AI is real. Case in point, An engineering org of Snowflake has met all its OKRs ahead of time in the first quarter for the time in the company's history. It had never happened, and usually meeting 70% of the planned OKR would be considered an achievement. I can imagine the stress of the engineers when they see such outcome.
  • becomevocal 5mo ago
    Hopefully we can blend those two options together so it’s not a choice. Personally I find being able lean on our heavily documented standards in /review gives me back time to dive into what I want to craft next. Same with scheduling repetitive tasks an agent can do for me well once instructed well. I am freed up to do something else I want to focus actively on because I like it and want it to be great. Now stress about OKRs and OKRS in general… that’s a different issue
  • RevEng 5mo ago
    I'm always hesitant of these claims. Sure, it's possible that AI really did help them achieve the same level of quality at 100x the pace. It's also possible it generated a huge tech debt that only passes the tests but hasn't planned for future maintainability, readability, and extensibility, and a year from now their entire process will grind to a halt. I have a few people on my team who move 5-10x faster than others in writing code. They also generate 5-10x as many bugs and require that much more rework in the things that were shipped. They move fast and break things. Their code is almost malicious compliance in that it passes the tests or spec as given, while leaving glaring holes in things that weren't fully specified. A more careful developer would have asked questions, considered alternatives, and looked for ways to leverage existing solutions or plan for future work, but that takes time now and its benefits don't show up until later. So while I don't immediately disbelieve that 10x+ speedups are possible with heavily AI-augmented flows, I am skeptical of any short term success stories until we have time to see the long term effects. We already know that cutting corners can save time in the short term only to cost us several times more in the long term.
• abhis3798 5mo ago
  Love this. I use a similar "ralph-loop" approach that starts with an approved plan and then hand it off to a coordinator which does it across 2 sessions (build and review for simplicity), with each session getting its own model.
• ciconia 5mo ago
  To me the blocker with using coding agents is having to rely on a paid external service. Are there any local models that are good enough to be used for coding?
  • julianlam 5mo ago
    As of this month, Qwen3.6 (either the 27B or 35B-A3B) or Gemma 4 are talked about often. Also maybe this will help: https://hnup.date/hn-sota https://hnup.date/hn-sota The qwen model is my daily driver this week.
  • pdyc 5mo ago
    depends on how clear your instructions are, if there is no ambiguity you can even use gemma4 e2b/e4b.
• etothet 5mo ago
  “A lot of people seem convinced that the point of AI coding is to write low-quality code as fast as possible.” A lot of people think a lot of things, but I don’t think the majority of people think the point of using LLMs is so they can produce low-quality code. Do they produce low-quality code sometimes or often? Of course. But they also produce high-quality code very often. And sometimes they just a “fine” job. One of the promises - and there are plenty of cases where it’s met and where it falls drastically short - is that agentic coding tools can help us code faster that is just as good or better than what a human can. One of the other big ideal payoffs is that agentic coding can allow non-programmers to create things that previously required programmers to create. We can debate as to how successful we’ve been toward the two goals above, but I think it’s misguided to say that the majority of people think LLMs should produce lower quality code.
  • goatlover 5mo ago
    Hopefully not, but there was recent thread with multiple posters arguing that code quality doesn't matter, and quality produced by humans in the past was often terrible. So who cares, ship it was the sentiment. Let the AIs handle the growing maintenance cost, I guess? Kind of a shocking thing to see argued on HN. Maybe it's just the vibe coders.
    • dozerly 5mo ago
      The vast majority of corporate-employed programmers write bad code. I think maybe 10% of the people I’ve come across have shown any interest or care in the quality of code they write. There will be a large majority of people who hold these opinions, because they weren’t capable of or didn’t care enough to write good code in the before times
      • sarchertech 5mo ago
        The real problem with these conversations is that code quality isn’t something we have any kind of consensus on. To a lot of engineers code quality means upper-case C Clean Code. Other engineers are in the Grug brain camp where they think that premature abstraction is the worst kind of code. But to your point I think the majority of engineers think they high quality code is anything that compiles or passes their (almost definitely insufficient) test suite.
• alexwwang 5mo ago
  So I am figuring out how to let LLM write code automatically as long as I clarify the requirements. I have made a set of skills to deal with this and it called tdd-pipeline. I eat this dog food and by several rounds of iterations to fix bugs, it works better and better. Now I feel much relax while it is working. I open sourced it on GitHub, you may search alexwwang/tdd-pipeline to find it if you are interested in it.
• _ZeD_ 5mo ago
  Basically you're using AI as very costly linters... what's wrong with (depending on the language) checkstyle, sonarlint, ruff, mypy, xmllint, and/or eslint?
  • lukebitts 5mo ago
    The quick answer is that even in the workflow described by the author these tools don’t do the same thing AI does. And a good programmer/agent will be using these tools as well
• p0w3n3d 5mo ago
  Thank you. That is really important to remind this to people especially in the upper management
• dahuangf 5mo ago
  [dead]
• bad_username 5mo ago
  We may be in the last Golden age of AI, where experienced professionals still exist who can code manually, and AI already exists who can code automatically, and when the former use the latter skillfully, wonders happen. This magical intersection may not exist iin the future, or become very rare.
  • dozerly 5mo ago
    I think as long as it continues to be tangibly better these people will still exist and the intersection will continue to be valuable enough to survive.
    • josephg 5mo ago
      > as long as it continues to be tangibly better these people will still exist Sure. But how long will that last? LLMs are getting better at programming much faster than I am. Imagine a plot with time on the X axis and LLM skill on the Y axis. The line goes up and to the right. On the left is GPT3, or GPT3.5 with the very first glimmers of programming ability just a few short years ago. In the middle is Opus 4.7 now. Where's the intersection point, where AI skill is higher than that of humans? Less than 10 years. I'd guess less than 5 years.
      • _under_scores_ 5mo ago
        I think the problem is is that coding is not wholly a 'writing code' problem. It's a translation from idea to outcome. Often I think the bad code generated by an LLM is less to do with it's 'ability' and more to do with an instruction that hasn't adequately accounted for the possibility of what code satisfies the criteria. I'm not sure how a newer model can improve on this per se - sure there will be imrpovement on outright mistakes but for me at least, that's been and gone with more or less with any model released in te last 6 months.
        • josephg 5mo ago
          I was coding something with claude the other day. It got the program working by all externally observable metrics, but when I went into the code it was full of DRY violations. It made a bunch of interrelated - but separate - traits for some concepts which simply didn't fit together. I asked it to look at the code and come up with better factorings, but it failed. I ended up manually reworking several thousand lines of code myself, via my IDE. It took days. I'd like a claude-of-the-future to be able to come up with beautiful ways to factor the code itself. Amongst the correct solutions, pick one which is conceptually simple. Write the code in a way that it makes subsequent changes easier to write. If I were doing RL with claude, I'd consider directing it toward solutions which allow subsequent changes to be implemented with as little effort as possible.
• futuredevtech 5mo ago
  AI makes senior engineers slower in the same way code reviews make teams slower: locally inefficient, globally beneficial.
• shevy-java 5mo ago
  > But the thing is, LLMs are very flexible. And you can use them just as effectively to write high-quality code more slowly. There is a reason it is called slop. On first sight it is often not noticeable but when you dig deeper, you realise that it is often spam-slop. Of course this can be improved upon, but often there is no real improvement and you waste your own time in hope that things get better. Which high quality projects exist that are AI slop generated? Can people name something that is used by many people? The linux kernel? Something in that range? Including documentation? To me it seems people are chasing a dream here: skynet should write the code and they can sit on the beach, enjoying sunshine and fruits.
• vemv 5mo ago
  Another day, another AI-related thinkpiece (that people upvote to post their own thinkpieces in the comments)
  • uncivilized 5mo ago
    This is the HN way. Never is there actual discussion about the contents of an article. Instead, a Hacker News will read the headline and will write a diary post in the comments.
• kaluga 5mo ago
  [dead]
• pineapple_opus 5mo ago
  > This is the opposite of the “10x productivity” slop-cannon style of development that most people imagine when they think of vibe coding, but I find it very satisfying. I can relate to this. When I spend time on writing unit test , even the one which takes 1% of code coverage, it will be honestly wholesome moment for me to ship it confidently.
• wartywhoa23 5mo ago
  The screechless wind vane of AI narratives be like - Using AI to write the best code ever faster than any human ever could - Using AI to write better code more slowly - Using AI to write code that sucks even more slowly - Using AI to stockpile horrendous ball of spaghetti code no one fucking understands which grows faster and faster despite going even more slowly - Using Natural Intelligence to try and fail to untangle the mountain of spaghetti code - Look guys, down with that AI, we've got a brand new shiny thing to throw trillions of VC dollars at!
• Garoro0920 5mo ago
  [flagged]
• Hfuffzehn 5mo ago
  The main insight here I think is that LLMs are great tools for iterative development and iterative problem solving in general. You can very effectivly iterate alone using the LLM as a mirror, rephrasing what you put in and adding a bit. You can use LLMs to quickly create prototypes to give to other human beings to help you with the next iteration. If you get something from someone else to iterate on you can use the LLM to help you with understanding to rephrase things in a way more suitable for your understanding. But instead everything anybody seems to be talking about seems to be one shoting things and AI iterating with other AI. The big problem here is that the one thing AI does not have is agency. The naming AI agent is wishful thinking and marketing.
• peepee1982 5mo ago
  Yes! That's what I've been doing at work for the last few weeks! And while it doesn't appear to be super fast, I'm already pretty certain that the next round of testing will come back with fewer unexpected issues because together with my agent and the right usage, I was already able to catch stuff that I would have missed otherwise. Also feels much better than pure vibe-coding (which I still do for personal projects that aren't mission critical for anyone).
• ilhanvalani 5mo ago
  [flagged]
• anon7000 5mo ago
  [flagged]
• jsxyzb9 5mo ago
  [dead]
• knuckleheads 5mo ago
  Very much agreed. Something specific that has helped me a lot (beyond just automatic formatting, linting and testing) was putting a hard fail on any file with more than 1500 lines or so, with an allowlist for specific files with specific reasons for their length. I realized the agents were squirreling away code without wanting to do any sort of refactor. Every time one of these rat's nests has turned up, the codebase has been much improved with a small refactor, to the point it doesn't feel like such a pile of slop anymore.
  • rhubarbtree 5mo ago
    200 is my preferred limit, and I think you can find that in a few highly regarded books on coding.
    • knuckleheads 5mo ago
      Matters of taste. I don't mind bigger files where it makes sense, and sometimes for the nature of the domain, it is nice to have more things in one file. As well, they write so many comments that 200 lines doesn't feel right to me.
• deleted 5mo ago
  [deleted]
• kieckerjan 5mo ago
  Another thing that I feel is underappreciated about agentic coding is that you can actually learn from it. I am a programmer with 25+ years of experience and I tend to do a lot of stuff according to fixed patterns/habits. Seeing how my coding agents do stuff helps me break out of these patterns, lets me consider new approaches, helps me pick up idioms and teaches me new hacks and tricks. That is very satisfying in its own right.
  • vascocosta 5mo ago
    I'm exactly in the same boat. 25+ years of experience and I use agentic coding exactly to learn better patterns. I often let it implement something, read the code, learn the pattern, confirm it's a good practice and then code myself manually another section of the code. I think many people that blindly say you cannot learn anything from vibe coding have some sweeping assumptions. It obviously depends. If you just let it do everything without even reading the code and understanding it, then yes. But the act of reading code is one of the best ways to actually learn, no matter if you read code from a human or from an LLM. I tend to learn way better by example than by reading a theoretical book.
• delis-thumbs-7e 5mo ago
  I think AI exists to make humans better, not to replace us (which it can’t anyway). I use LLM’s with new topics answer questions and tutor me (for instance with multivariable calculus -course this spring I asked Claude to create 10 practice exercises, which I then did and it reviewed. Harder ones it did with me step by step.) hopefully not needing them after awhile, when I gain proficinency. Automating humans away is not going to work. There’s a reason why we are the apex predator and ruled this planet for million years.
  • abustamam 5mo ago
    > which it can’t anyway I agree, but it doesn't change the reality that AI is the stated reason for many layoffs.
  • majorbugger 5mo ago
    You have very optimistic assumptions about AI. Of course AI will not "replace you" on its own, but some person in the company will decide it.
    • delis-thumbs-7e 5mo ago
      That’s first time I hear I’m optimistic about AI. I am as optimistic as I am about a hammer or a liquid scale. They are tools and they are good for particular jobs, if ypu know how to use them. I am in careers that is one of the more sheltered from automation. Present tech layoffs I suspect are more due to insane overhiring during covid as well as outsourcing. I am sure some companies have gone to full AI psychosis -mode, but they are taking a massive risk. Time will tell.
• hansmayer 5mo ago
  > But if you’re the kind of developer who uses agents to write multi-hundred-line PRs that you barely understand yourself, I’d invite you to slow down a bit and try this other, slower style of “vibe coding.” Ask an agent how your PR works and how it might fail. Have it write Markdown docs with Mermaid charts if necessary. Use Matt Pocock’s /grill-me skill until you understand the entire PR front-to-back. Man so much work to retrofit something that obviously, simply, plainly - just does not work. How about just writing the code yourself? You can even consult AI on the libraries or whatever, but how about just building that model in your head YOURSELF and not loading up on AI slop and trying to memorise that crap. The names of the functions will ring different in your memory once you spend some time thinking over whether you picked the right and clear name vs. just going with whatever statistical median the slop machine picked for you.
• bob1029 5mo ago
  I think using speed to describe the rate of progress in software development is where the frustration comes from. Software isn't a velocity thing. It's a space thing. It's memory. Information in some media. You can transfer a billion bits in less than a second. The time domain is largely irrelevant in business terms. Having taste and the ability to author high quality prompts is still the most important thing. It was always the most important thing if you think abstractly about how all of this works.
• jixter_apps 5mo ago
  [flagged]
• FacelessJim 5mo ago
  I’ve landed on a very similar usage in my last pet project. I’ve used the llm mainly as a glorified refactoring tool/LSP/rubber duck. I can define custom skills that act as specific passes over the codebase that are hard to do with traditional tools, I am using Julia, so I have a skill that is only about doing a semantic and type analysis pass to catch potential type instabilities. Or another that is just about documentation reporting. The workflow for me is always: talk the problem to death/get a report. Triage, decide what I can and should do on my own, what can be left to the llm as mundane boring refactoring tasks, what instead needs me to figure out the correct shape first and then ask the llm to propagate the new pattern in the codebase. Then act. A lot of the time I am implementing the llm suggestion by hand on my own to get a feel of how the codebase is shifting under my feet and stay on top of things. This indeed makes things more slow, but allows for an overall higher quality codebase. Especially the refactoring part.
• Ayush_Khati1 5mo ago
  [flagged]
• gitgud 5mo ago
  Finding bugs in PR’s are exactly what GitHub copilot, GitHub cursor bot and tonnes of other PR bots already do…
• olafmol 5mo ago
  This is exactly the reason why I like to work with local models on a regular specced machine. The fact that the agent moves slower allows me to stay in the loop much better, compared to skimming through a huge amount of generated content and data and then going to the end really fast to make sense of it all, in the interest of time (and thus losing track and quality). The fact that I can run it locally makes it (much) cheaper too.
• ammar_x 5mo ago
  I usually do this for complex features: - Opus 4.7 writes the code - I make GPT-5.5 in Codex to review it (given context) - I provide the review back to Opus and ask it to verify the review findings - Make Opus plan the fixes then execute them - Ask GPT-5.5 to review the fixes and check if they solve the problems
• jillesvangurp 5mo ago
  Regardless of what model you use, agentic coding tools are indeed pretty good at finding issues if you target them a bit. And they have no respect for their own code or any sense of shame. So, you can just point them at their own code with a new thread. Many AI models seem biased to cutting corners by default when generating code, even when you ask them not to. But a few simple follow up prompts can address that. Simply ask for covering corner cases with tests, test all the known non happy paths, look for weaknesses, verify adherence to SOLID principles, do security audits, etc. It will find issues. With bigger projects, you can actually make it file those issues in gh with labels and priorities. And then you can make it iterate on fixing issues with separate PRs. On a recent project, I made it implement a simple benchmark test for measuring throughput. I had a hunch it was doing very sub optimal things. I then asked it to look for potential performance bottlenecks and use the benchmark to verify improvements. At that point I already had a lot of end to end tests to verify correctness. So, these performance tweaks were relatively low risk. I got about two orders of magnitude improvement and a lot more graceful behavior when pushed to the limit. If you have a bit of experience engineering systems, just treat these tools like they are junior developers. Competent but likely to skip some essential steps. So, just double check with a lot pointed questions "did you do X? If not, do it now". Anything that needs repeated asking, turn it into a guard rail / skill. There's a bit of effort and skill involved with this. I imagine a lot of less experienced developers might struggle to get good results because they aren't asking for the right things.
  • KronisLV 5mo ago
    > Regardless of what model you use, agentic coding tools are indeed pretty good at finding issues if you target them a bit. And they have no respect for their own code or any sense of shame. So, you can just point them at their own code with a new thread. Many AI models seem biased to cutting corners by default when generating code, even when you ask them not to. But a few simple follow up prompts can address that. That's more or less all of them, they do just generate the likely combinations of tokens, there is no critical thought involved. If you want to approximate that, review iterations are probably the right way to go about it, without the full conversation context either so there's no model output like "I'm doing X because it seems like the correct way to go about Y." but rather a fresh context which allows for more critical predictions. Here's what works for me, can be made into a skill in whatever you use: I would like you to do a review loop! How this works: * once implementation is done, all tools must be run and pass: whatever is configured in the project like Ruff, Oxlint and Oxfmt, depending on the tech stack (also don't run such tools directly, look at package.json or similar project files/configurations/run scripts first; like if it's a stack that has compilation, compile the app, if there are tests, then run those; just know that you DO NOT generally need to stand up the whole app); if there is a projectlint-rules folder then that means you probably should run ProjectLint as well (local tool, use projectlint --help or projectlint --docs, or better yet, look at whether package.json or README.md have any instructions on how to run it) * once all the code seems okay, you will run THREE parallel sub-agents for code review: each looking at ALL changed code (not each having a different sub-section) and looking for CRITICAL/SERIOUS issues (not nitpicks), with the goal of not missing anything and building consensus * whatever CRITICAL/SERIOUS issues are found, if you can confirm that they're real and not false positives, you will then fix and remember to run the tools after, after which you will do another review iteration, followed by a fix iteration if needed and so on * remember that the review and fix loop must END with an iteration of the review agents returning that there are no CRITICAL/SERIOUS issues - you cannot just do fixes and say that there is nothing remaining yourself (and also remember that the reviews are done when all of the tools pass, like when the code is linted and formatted etc.) * at the end, produce a summary post that has a table, the rows being iterations, the columns for each of the agents (A, B, C) showing FIX/OK and then a column called Iteration summary; the goal for this is to show a summary how many iterations it took and what was fixed, you can also include text alongside the table as normally The ProjectLint references might need to be removed (replace with whatever higher level linting/architecture tools you have, if any), but that's the overall idea. It does use a LOT of tokens though, but almost always there's something to fix. Of course, the problem is that sometimes there will be nitpicks or the fixes themselves won't be fully okay, though in general this trends towards slightly better code, even with something like Opus 4.7.
• huzaifasinan 5mo ago
  [dead]
• machuz 5mo ago
  [flagged]
• cladopa 5mo ago
  Exactly. That is what we do. We do software that can kill people and it is very sophisticated, like controlling robots and we prototype using LLMs and it is amazing. People believe that you can only use LLMs for sloppy programming. But you can also use it for writing ten times more code of Swiss cheese model tests, and domain specific languages. You write ten times more code than necessary and all that extra code is testing. Projects like SqlLite do that because they need to be perfect. Before LLMs we had to use engineers for that and it was a painful and repetitive work, and they were always late and made much more mistakes than LLMs, specially because it was dull and tedious for great engineers to spend their time into. Now we write tests and when all test pass we write new test for checking the tests. We divide each complex problem in small subproblems and we warrantee each of them by formal means. We have multiple ways of solving the same problem, usually with one brute force solution that is simple and warranted to work but inefficient, and we can use it to compare with more efficient methods. Before machines could do that, people doing that were burned down and exhausted, and always leaved pending work to complete.
  • hackerthemonkey 5mo ago
    > Now we write tests and when all test pass we write new test for checking the tests Care to expand on how is this accomplished?
• embirdating 5mo ago
  [dead]
• jwpapi 5mo ago
  The greatest part of this approach is that you actually become better in the process. The downside is you use less tokens.
• mlpicker 5mo ago
  The anchoring thing is what gets me. Once I've seen the AI's first try, even when it's wrong, I can't really write fresh in my head anymore. I end up editing instead of starting over. Code quality usually ends up fine. Time-wise it's a wash or worse, you just don't feel it until you look at the clock at end of day.
• lofaszvanitt 5mo ago
  .
• jaspanglia 5mo ago
  [flagged]
• bonoboTP 5mo ago
  I find that it really is effective when you iterate and plan and review, but the problem is more psychological on the human side. It's just too easily available to take the lazy option and just let it do the thing, postpone the thorough reviewing and you end up in a similar situation as tech debt. In an ideal world with no deadline pressure and infinite discipline, AI can be used in productive ways for sure. But when you actually write the code, there is more of a "do you do it or not" switch, and with AI it's a smooth ramp, you can be just a bit less involved or just a bit more. And I end up feeling like I'm not fully involved, I'm halfway working and my whole mind isn't tuned into it properly. I'm not sure how to express it. Also, now several months in, I just don't get the same feeling of accomplishment from the little wins. It's too automatic, doesn't feel earned.
  • convenwis 5mo ago
    "It's just too easily available to take the lazy option and just let it do the thing" This seems to me to be one of the key problems for AI usage in general. Students have this problem where it can be incredibly helpful in actually learning but late at night with the assignment due early tomorrow the temptation is just too strong to have it do the thing.
    • bonoboTP 5mo ago
      Somehow I find that interacting with AI doesn't make me feel the same way as diving through Wikipedia rabbit holes. With AI it feels more like, it starts saying how there is indeed an answer to some science question I was unsure about, about some phenomenon or about how some technology works, and it starts explaining it but I feel disinterested in actually reading it's answer. I see it's general shape and I feel satisfied in the existence of the answer. It may be the glazing sycophancy too, but it seems that I get the "satisfaction" from just getting the answer, while with Wikipedia I only got it once I dug up the info that I needed. And the AI answer is ephemeral, while the Wikipedia page is there for everyone, it's a thing, even if it can change. Same with AI images. It feels good for 2 seconds to see what I asked for and I'm immediately disinterested. Same way, I've generated many Suno songs, but I don't care about them after a few listens.
  • 5mo ago
• mocamoca 5mo ago
  Does anyone have good recommendation for ai auto completion? My goal is to draft the solution with ai, write it myself but faster with auto complete, then throw ai review.
  • kordlessagain 5mo ago
    So your "goal" is to find an existing ai-auto completion that allows you to draft with AI then "write it yourself" by hitting tab? Sounds like the goal is actually to build that, then use it on projects....
    • mocamoca 5mo ago
      I get pretty good results by writing specs and prototype with a LLM, through more or less managed conversations. But once the prototype is done, I spend too much time refining the details, fixing everything going wrong (bas design details, wrong implementation, half done testing ...) A full agentic setting would be too expensive for me (I wonder how much Garry tan spends...) So I'd like to take a more balanced approach with: 1. usual LLM specs and prototyping to get the bases of the feature and boilerplate done 2. Write myself the code, with the help of an ai auto complete (this is Where I look for recommendations) 3. Use a setup as OP mentioned to review code
      • RevEng 5mo ago
        Cursor with its tab completion. Iterate with the agent part to research, design, and plan. Let it generate boilerplate and scaffolding, perhaps with placeholders for you to fill in. Then fill in as you normally would, but with an auto-complete that uses all of your code and design docs and everything else to inform that completion rather than the limited set of info that shows up in an LSP. I believe JetBrains IDEs have something similar too, but I don't have as much experience using theirs since my employer hasn't blessed their AI tools yet.
  • adam_patarino 5mo ago
    I like Zed for this. We are considering autocomplete for Rig after we launch our agent. Local would be 1000x faster.
• alansaber 5mo ago
  Input sequence mutation >>> novel token generation in LLMs. Why? IDK, there must be a good theory article someone could point me to.
• throwatdem12311 5mo ago
  Would love to but my boss wants 15 features delivered yesterday
• stuaxo 5mo ago
  Yep, it definitely can help with being an 0.1x developer, it's a long drawn out process but the output is actually good.
• galactus 5mo ago
  [flagged]
• TimoKn 5mo ago
  [flagged]
• contextcost 5mo ago
  [flagged]
• galaxdb 5mo ago
  [flagged]
• marcusholt 5mo ago
  [dead]
• chris_st 5mo ago
  Another way I'm "going slower" is to have the AI implement individual sub-steps of the current task, and review each one. It's slower than having it yolo out the whole thing, but it's much smaller incremental bits to review, so my brain doesn't glaze over in a huge review, like I had if I had it do the whole task. I'm following an Ideas -> PRD -> Issues -> Tasks methodology, where each task has a bunch of sub-tasks. I have it just do one (or a few, I'm having it do Red/Green/Refactor as separate sub-steps, so I review the Red case, and then once that's good, do the Green and Refactor steps, and review those).
• pawelduda 5mo ago
  This is one of the most sane takes on shipping code using AI where it's being actively reviewed and it respects your colleagues' time and attention. I like it.
• marcusholt 5mo ago
  The goal was better code. The result is a new full-time job reviewing your robot's homework. Progress is not the word I would use here.
• kingofalldevs 5mo ago
  The bottleneck moved. It used to be writing code. Now it's knowing what to ask for, in what order, and how to validate what comes back. That's a fundamentally different skill than coding.
  • mlinhares 5mo ago
    Only if your job was to write code alone, which isn't what most people do. Most of my job for the past 10 years was explaining to people what had to be done, how and then verifying they did it. Any senior/staff engineer was already doing this, if they weren't they were on the wrong job or had the wrong title.
• abalashov 5mo ago
  I'm pretty intensely disinterested in "agentic" coding. However, this was very much the inspiration behind the custom Claude-backed Goose agent I deployed into some of our Gitea repositories over Christmas--the less sensitive ones, of course, I'm not sending our proprietary code to Dario. It does short and sweet code reviews, and going back and forth with it is, as often as not, slower than just typing and merging the code. I'm quite pleased with it as a middle ground.
• shadowbip 5mo ago
  [flagged]
• danielcasper 5mo ago
  This. Go slow. Use principles. Argue. Refactor. Improve before you commit. It is the way.
• miki123211 5mo ago
  Each time a new technology comes around, we seem to forget all the lessons we learned before. We them re-learn them again, much more quickly and just as painfully. The same thing happened with crypto. Crypto started with some correct assumptions like "online services that stop working when it's a holiday are ridiculous", "it should be possible to send money to a friend without your government knowing about it", or "money transfers cost nothing to execute, so they should cost nothing." It then promptly threw out the entire framework of banking regulations, quickly re-learning why most of those regulations existed in the first place.
  • deleted 5mo ago
    [deleted]
  • zuzululu 5mo ago
    > it should be possible to send money to a friend without your government knowing about it except the majority use case for this is crime and if you send it to the wrong person there is no way to reverse it by calling the bank (who also doesn't know where you are spending it under $10,000)
• hrideshmg 5mo ago
  As a junior, i do actually enjoy going back and forth with the AI discussing different ways to implement something and exploring alternatives. More often than not, I'd have an architectural idea that I'm not that confident in. The process of talking with the LLM takes a long time but it helps me sharpen the initial approach or even come up with a new one depending on the requirements.
  • lubesGordi 5mo ago
    As a senior, I do the same.
  • ChicagoDave 5mo ago
    This is how I do it to and I’m an architect/senior dev. Keep it up!
  • imadierich 5mo ago
    [dead]
  • apsurd 5mo ago
    Same. My total agentic session time/effort is about 70/30 discussion vs code-gen. I've got 12 years experience.
  • alfiedotwtf 5mo ago
    This used to be called Pair Programming. And just letting you know, it’s not just juniors… we’re all do this :)
  • tyrust 5mo ago
    Be sure to explicitly ask for critiques or alternatives. In my experience the machine is really susceptible to a sort of anchoring effect.
    • goolz 5mo ago
      In this vein, I have a system level memory for Claude to push back and give me direct feedback when possible. So far a success as it helps cut through the sycophancy.
• paol_taja 5mo ago
  [dead]
• qwertox 5mo ago
  I noticed that sometimes discussing the code with a chat instance, and having it write prompts for an in-IDE-agent, then posting the result back to the instance to discuss the results and repeat this loop yields not only good results, but also makes me understand the codebase better. I let both agents know I'm proxying and take part in the conversation.
• maxothex 5mo ago
  [flagged]
• cardmates 5mo ago
  [flagged]
• swordlucky666 5mo ago
  [flagged]
• qaq 5mo ago
  My workflow now 1) While walking voice chat with ChatGPT about architecture and various interesting angles for a feature or product 2) Have it create summary of things we talked about 3) use that to seed spec development phase 4) write comprehensive specs using both Claude Code and Codex 5) create todos from specs 6) implement todos using both Claude Code and Codex to check each others work 7) run focused code check prompts e.g. specifically for error handaling, concurrency issues etc. They tend to find more issues in these focused passes.
• NickC25 5mo ago
  I believe this thinking can be abstracted to software design via AI in general. If you are thoroughly prepared, and keep things simple, it's incredible what help Claude or GPT can be. I have Claude basically doing all the coding for me for a simple game I am making. However I don't consider this vibe coding. I spent several hours thinking out the design on a piece of paper, playtesting it in person. I came up with a list of potential mechanical issues within the game, and asked Claude to come up with more. It found more issues, and we solved them all together. Once the game was mechanically sound and edgecases were solved for, it built an MVP. I ran the program, and found more bugs. I came up with my own solutions, and Claude did the same, and we figured out which were best to implement. Claude then wrote more code, and raised issues when they came up, and we worked through them together. I'm incredibly happy with how its turned out so far.
• sailfast 5mo ago
  This approach works well, and leads to better code being shipped. The key disconnect for me is not always the code being of high quality, but ensuring my understanding of the "Why" of the bug and the fix is good enough to justify it and then also explain it if the time comes. That said, I'm learning to let go as much as I can and trust these things when it's "safe" and seeing how that shakes out. The risk is something falls over and I don't know how to fix it (of course) but I know it's a risk and I'm trying to avoid it so it probably won't be as bad as I catastrophize.
  • RevEng 5mo ago
    I think we can do both. Ask the AI to summarize it, but to show examples and point out where things happen. Let it make you a Coles Notes. You still need to look at the code yourself and understand it, but an initial outline and explanation can really jump start the process and save a lot of time. Likewise, it's hard to find a bug and come up with a fix, but those same things are often oblivious in hindsight. Once we have an idea of what the bug is, we can often look at the code directly or write tests to confirm in a fraction of the time it took to discover in the first place. Once we have an idea for a fix with code and an explanation for how it fixes the bug, we can often review that explanation, think through any implications, and test the fix in a fraction of the time it takes to come up with it in the first place. I'm happy to let the AI explore possibilities for me, eliminating the search problem. It's still on me to understand the solution, verify it works, and handle any other considerations I know of that the AI wouldn't. It gives me the insight, but I'm responsible for the final solution.
• halis 5mo ago
  This was a really good article. I typically code with Sonnet or Opus, but I'm going to start using Codex to review local changes before I do a PR. It does a great job at identifying issues and then patching them. I just feel weird having Anthropic review it's own code so this will be my workflow for now. For complex features I also use Opus to cook up an implementation plan ahead of time that a lot of the time I have Sonnet implement. I may also have Codex start devil's advocating the plan before I start too, just to catch issues earlier.
• madbo1 5mo ago
  [flagged]
• yinma_indie 5mo ago
  [flagged]
• zuzululu 5mo ago
  if you are getting paid hourly, what incentive is there to use AI and get paid for less hours?
  • XCSme 5mo ago
    Work same amount of hours -> more productive -> client happier
• funny19840218 5mo ago
  [flagged]
• m_barsukou 5mo ago
  [dead]
• ath3nd 5mo ago
  [dead]
• waqarjaved 5mo ago
  Using AI to find bugs rather than write features is an underexplored mode. The incentives in most teams push toward generation speed, but "AI as the skeptic that reads your PR" has a much better quality to risk ratio for established codebases.
• 78Degrees 5mo ago
  [flagged]
• thomasnowhere 5mo ago
  One area where AI is reliably faster with no quality tradeoff is writing E2E tests. You can cover a ton of edge cases in an afternoon that you would normally skip, and if something breaks you see it immediately.
• juanre 5mo ago
  This sounds very right. My rule of thumb is at least 50% of the AI work is supervising, reviewing, guiding and bug-finding. A codex session that started a pretty significant chunk of work this morning has just informed me that it thinks that it's done, Final usage: 5,245,839 tokens over about 10 hours 3 minutes. It's quite remarkable that the result looks actually correct. But through all this time two more agents (one claude code and another codex under pi) were working alongside reviewing, criticising code, and finding bugs. It would have been impossible otherwise.
• RevEng 5mo ago
  I do something similar. Design reviews are an extremely valuable part of the process but they take a long time and people are busy and who really has enough expertise to provide meaningful feedback? Well, the AI is always available and it can rip through my entire codebase in just a few minutes and it has seen more code than I could in a thousand lifetimes. Asking it to review my ideas, my proposals, my implementation, my documentation - anything I can think of - generates a wealth of good insights. That's not to say that I follow every suggestion it gives any more than I accept every line of code it generates. I'm still the engineer and I still have my reasons for some decisions that may not make sense to an outsider. But as a rubber duck or a second set of eyes or a sober second thought, it can offer a lot of good feedback that I can consider, and most of it is quite good. I'd say about 8/10 suggestions it makes I agree with and accept, maybe with some small tweaks. I don't think I've ever seen it suggest anything stupid. The last 2/10 are generally either things that would make sense if not for the rest of the context in my head that says it is that way for a reason, or because it's too minor to worry about changing. All of this extra review takes more time and it usually results in me making a bunch of extra changes I wouldn't have otherwise made, but that's all I'm the make of much better quality and reliability and that pays off in multiples in the future.
• 3vo-ai 5mo ago
  [flagged]
• eldho123 5mo ago
  The interesting shift is that coding is becoming less of a bottleneck than judgment. Generating code is easy now; deciding whether the generated approach is maintainable 6 months later is harder.
• HarHarVeryFunny 5mo ago
  If you have code chock full of bugs (hand written, or LLM generated?) then I guess any tool that helps find them is good. I find that traditional static analysis tools like Fortify are next to useless because of the low signal to noise ratio - flagging things that aren’t errors or vulnerabilities just because someone decided that certain standard library calls should be flagged etc. I wouldn’t be praising an LLM for it’s voluminous output unless it is doing a much better job of finding actual bugs, and if the code really is that buggy then it might be worth asking why!
• shanewei 5mo ago
  [flagged]
• max_fs_dev 5mo ago
  [flagged]
• willXare 5mo ago
  [flagged]
• frankdlc222 5mo ago
  [dead]
• willXare 5mo ago
  [flagged]