10 ms·

The AI coding trap

• maxglute 1y ago
  Trap for whom. It helped me finish a bunch personal projects that made my work flow more efficient, as someone with very basic knowledge in coding.
• LeroyRaz 1y ago
  Maybe I haven't worked on tricky enough problems, but I swear people massively hype-up the difficulty of coding. The vast majority of the time there is little difficult problem solving
• tptacek 1y ago
  It's a fine post, but two canards in here: First, skilled engineers using LLMs to code also think and discuss and stare off into space before the source code starts getting laid down. In fact: I do a lot, lot more thinking and balancing different designs and getting a macro sense of where I'm going, because that's usually what it takes to get an LLM agent to build something decent. But now that pondering and planning gets recorded and distilled into a design document, something I definitely didn't have the discipline to deliver dependably before LLM agents. Most of my initial prompts to agents start with "DO NOT WRITE ANY CODE YET." Second, this idea that LLMs are like junior developers that can't learn anything. First, no they're not. Early-career developers are human beings. LLMs are tools. But the more general argument here is that there's compounding value to working with an early-career developer and there isn't with an LLM. That seems false: the LLM may not be learning anything, but I am. I use these tools much more effectively now than I did 3 months ago. I think we're in the very early stages of figuring how to get good product out of them. That's obvious compounding value.
  • dpflan 1y ago
    > Most of my initial prompts to agents start with "DO NOT WRITE ANY CODE YET." I like asking for the plan of action first, what does it think to do before actually do any edits/file touching.
    • james_marks 1y ago
      I’ve also had success writing documentation ahead of time (keeping these in a separate repo as docs), and then referencing it for various stages. The doc will have quasi-code examples of various features, and then I can have a models stubbed in one pass, failing tests in the next, etc. But there’s a guiding light that both the LLM and I can reference.
      • dpflan 1y ago
        Sometimes I wonder if pseudocode could be better for prompting than expressive human language, because it can follow a structure and be expressive but constrained -- have you seen research on this and whether this an effective technique?
        • LunaSea 1y ago
          I had good success with prompting using the fully complete code.
  • badsectoracula 1y ago
    > the LLM may not be learning anything, but I am Regardless of that, personally i'd really like it if they could actually learn from interacting with them. From a user's perspective what i'd like to do is to be able to "save" the discussion/session/chat/whatever, with everything the LLM learned so far, to a file. Then later be able to restore it and have the LLM "relearn" whatever is in it. Now, you can already do this with various frontend UIs, but the important part in what i'd want is that a) this "relearn" should not affect the current context window (TBH i'd like that entire concept to be gone but that is another aspect) and b) it should not be some sort of lossy relearning that loses information. There are some solutions but there are all band-aids to fundamental issues. For example you can occasionally summarize whatever discussed so far and restart the discussion. But obviously that is just some sort of lossy memory compression (i do not care that humans can do the same, LLMs are software running on computers, not humans). Or you could use some sort of RAG but AFAIK this works via "prompt triggering" - i.e. only via your "current" interaction, so even if the knowledge is in there but whatever you are doing now wouldn't trigger its index the LLM will be oblivious to it. What i want is, e.g., if i tell to the LLM that there is some function `foo` used to barfize moo objects, then go on and tell it other stuff way beyond whatever context length it has, save the discussion or whatever, restore it next day, go on and tell it other stuff, then ask it about joining splarfers, it should be able to tell me that i can join splarfers by converting them to barfized moo objects even if i haven't mentioned anything about moo objects or barfization since my previous session yesterday. (also as a sidenote, this sort of memory save/load should be explicit since i'd want to be able to start from clean slate - but this sort of clean slate should be because i want to, not as a workaround to the technology's limitations)
    • didibus 1y ago
      You want something that requires an engineering breakthrough. Models don't have memory, and they don't have understanding or intelligence beyond what they learned in training. You give them some text (as context), and they predict what should come after (as the answer). They’re trained to predict over some context size, and what makes them good is that they learn to model relationships across that context in many dimensions. A word in the middle can affect the probability of a word at the end. If you insanely scale the training and inference to handle massive contexts, which is currently far too expensive, you run into another problem: the model can’t reliably tell which parts of that huge context are relevant. Irrelevant or weakly related tokens dilute the signal and bias it in the wrong direction, the distribution flatten or just ends up in the wrong place. That's why you have to make sure you give it relevant well attended context, aka, context engineering. It won't be able to look at a 100kloc code base and figure out what's relevant to the problem at hand, and what is irrelevant. You have to do that part yourself. Or what some people do, is you can try to automate that part a little as well by using another model to go research and build that context. That's where people say the research->plan->build loop. And it's best to keep to small tasks, otherwise the context needing for a big task will be too big.
  • boredemployee 1y ago
    DO NOT WRITE ANY CODE YET. haha I always do that. I think it's a good way to have some control and understand what it is doing before the regurgitation. I don't like to write code but I love the problem solving/logic/integrations part.
    • tptacek 1y ago
      I'm surprised (or maybe just ignorant) that Claude doesn't have an explicit setting for this, because it definitely tends to jump the gun a lot.
      • ctoth 1y ago
        Plan mode (shift-tab twice) might be what you want.
        • tptacek 1y ago
          See, I called it! Ignorance it is!
        • jaggederest 1y ago
          A gentle warning to people who are overly trusting: Claude code can and will modify files in plan mode. Before I switched to a different agent, I routinely ran into situations where I would say "write a plan to do x", it would start planning, and I would steer it by saying something like "update such and such a file, instead of other-file" and it would immediately update it, even though it was in plan mode. Then I would point out "you're in plan mode, don't update files", and it would go absolutely ham undoing changes and furiously apologizing "You're right! I'm in plan mode, let me undo those changes I wasn't supposed to make!" - meaning that now it's broken the rules twice. Plan mode does not disable any writing tools, it just changes the system prompt, judging by my experience anyway.
      • mccoyb 1y ago
        Is that not exactly plan mode?
  • AlexCoventry 1y ago
    > figuring how to get good product out of them What have you figured out so far, apart from explicit up-front design?
  • closeparen 1y ago
    >First, skilled engineers using LLMs to code also think and discuss and stare off into space before the source code starts getting laid down Yes, and the thinking time is a significant part of overall software delivery, which is why accelerating the coding part doesn't dramatically change overall productivity or labor requirements.
    • tptacek 1y ago
      This logic doesn't even cohere. Thinking is a significant part of software delivery. So is getting actual code to work.
      • swiftcoder 1y ago
        ideally there is an order of magnitude difference between, and the latter is trivially delegable (where the former is not)
        • tptacek 1y ago
          No there isn't.
          • yoz-y 1y ago
            This harkens back to the waterfall vs agile debates. Ideally there would be a plan of all of the architecture with all the pitfalls found out before any code is laid out. In practice this can’t happen because 30 minutes into coding you will find something that nobody thought about.
            • swiftcoder 1y ago
              In the micro, sure. In the macro, if you are finding architecture problems after 30 minutes, then I’m afraid you aren’t really doing architecture planning up front.
              • 1y ago
  • yggdrasil_ai 1y ago
    Self disciplined humans are far and few between, that seems to be the point of most of these anti-ai articles, and I tend to agree with them.
  • surgical_fire 1y ago
    > Most of my initial prompts to agents start with "DO NOT WRITE ANY CODE YET." I really like that on IntelliJ I have to approve all changes, so this prompt is unnecessary. There's a YOLO mode that just changes shit without approval, that I never use. I wonder if anyone does.
    • dvratil 1y ago
      It's more about having the LLM give you a plan of what it wants to do and how it wants to do it, rather rhan code. Then you can mold the plan to fit what you really want. Then you ask it to actually start writing code. Even Claude Code lets you approve each change, but it's already writing code according to a plan that you reviewed and approved.
    • t0mas88 1y ago
      I use YOLO mode all the time with Claude Code. Start on a new branch, put it in plan mode (shift + tab twice), get a solid plan broken up in logical steps, then tell it to execute that plan and commit in sensible steps. I run that last part in "YOLO mode" with commit and test commands white listed. This makes it move with much less scattered interactions from me, which allows focus time on other tasks. And the committing parts make it easier for me to review what it did just like I would review a feature branch created by a junior colleague. If it's done and tests pass I'll create a pull request (assigned to myself) from the feature branch. Then thoroughly review it fully, this really requires discipline. And then let Claude fetch the pull request comments from the Github API and fix them. Again as a longer run that allows me to do other things. YOLO-mode is helpful for me, because it allows Claude to run for 30 minutes with no oversight which allows me to have a meeting or work on something else. If it requires input or approval every 2 minutes you're not async but essentially spending all your time watching it run.
  • pron 1y ago
    > LLMs are tools With tools you know ahead of time that they will do the job you expect them to do with very high probability, or fail (with low probability) in some obvious way. With LLMs, there are few tasks you can trust them to do, and you also don't know their failure mode. They can fail yet report success. They work like neither humans nor tools. An LLM behaves like a highly buggy compiler that too frequently reports success while emitting incorrect code. Not knowing where the bugs are, the only thing you can try to do is write the program in some equivalent way but with different syntax, hoping you won't trigger a bug. That is not a tool programmers often use. Learning to work with such a compiler is a skill, but it's unclear how transferable or lasting that skill is. If LLMs advance as significantly and as quickly as some believe they will, it may be better to just wait for the buggy compiler to be fixed (or largely fixed). Presumably, much less skill will be required to achieve the same result that requires more skill today.
  • onion2k 1y ago
    Most of my initial prompts to agents start with "DO NOT WRITE ANY CODE YET." Copilot has Ask mode, and GPT-5 Codex has Plan/Chat mode for this specific task. They won't change any files. I've been using Codex for a couple of days and it's very good if you give it plenty of guidance.
• dpflan 1y ago
  I think this would benefit from examples of including coding assistants in the stages enumerated; how can the agent be included in each stage? I've seen posts about successful collaboration with agents at say Google, where there is tons of upfront work among humans to agree on design, then work with the agent to build out parts of the project and ensuring thorough test suites are included. Does including an agent at each stage of this cycle mean "context engineering"? Is this then just more text and assets to feed in at each stage of LLM ussage to provide the context for the next set of tokens to generate for the next stage of the cycle? Is there something deeper that can be done to encode this level of staged development into the agent's weights/"understanding"? Is there an established process for this yet? - Specification - Documentation - Modular Design - Test-Driven Development - Coding Standard - Monitoring & Introspection
• abrichr 1y ago
  > While the LLMs get to blast through all the fun, easy work at lightning speed, we are then left with all the thankless tasks: testing to ensure existing functionality isn’t broken, clearing out duplicated code, writing documentation, handling deployment and infrastructure, etc. I’ve found LLMs just as useful for the "thankless" layers (e.g. tests, docs, deployment). The real failure mode is letting AI flood the repo with half-baked abstractions without a playbook. It's helpful to have the model review the existing code and plan out the approach before writing any new code. The leverage may be in using LLMs more systematically across the lifecycle, including the grunt work the author says remains human-only.
  • kevin42 1y ago
    That's my experience as well. The LLM is great for what I consider scaffolding. I can describe the architecture I want, some guidelines in CLAUDE.md, then let it write a bunch of stubbed out code. It saves me a ton of time typing. It's also great for things that aren't creative, like 'implement a unit test framework using google test and cmake, but don't actually write the tests yet'. That type of thing saves me hours and hours. It's something I rarely do, so it's not like I just start editing my cmake and test files, I'd be looking up documentation, and a lot of code that is necessary, but takes a lot of time. With LLMs, I usually get what I want quickly. If it's not what I want, a bit of time reviewing what it did and where it went wrong usually tells me what I need to give it a better prompt.
• jsmith99 1y ago
  > lack in-depth knowledge of your business, codebase, or roadmap So give them some context. I like Cline's memory bank approach https://docs.cline.bot/prompting/cline-memory-bank https://docs.cline.bot/prompting/cline-memory-bank which includes the architecture, progress, road map etc. Some of my more complex projects use 30k tokens just on this, with the memory bank built from existing docs and stuff I told the model along the way. Too much context can make models worse but overall it's a fair tradeoff - it maintains my coding style and architecture decisions pretty well. I also recommend in each session using Plan mode to get to a design you are happy with before generating any code.
• fabmilo 1y ago
  one axis that is missing from the discussion is how fast they are improving. We need ~35 years to get a senior software engineer (from birth to education to experience). These things are not even 3.5 years old. I am very interested in this space, if you are too dm me on X:@fabmilo I am in SF.
  • deleted 1y ago
    [deleted]
• reb 1y ago
  I would love to see an anti-AI take that doesn't hinge on the idea that technology forces people to be lazy/careless/thoughtless. The plan-build-test-reflect loop is equally important when using an LLM to generate code, as anyone who's seriously used the tech knows: if you yolo your way through a build without thought, it will collapse in on itself quickly. But if you DO apply that loop, you get to spend much more time on the part I personally enjoy, architecting the build and testing the resultant experience. > While the LLMs get to blast through all the fun, easy work at lightning speed, we are then left with all the thankless tasks This is, to me, the root of one disagreement I see playing out in every industry where AI has achieved any level of mastery. There's a divide between people who enjoy the physical experience of the work and people who enjoy the mental experience of the work. If the thinking bit is your favorite part, AI allows you to spend nearly all of your time there if you wish, from concept through troubleshooting. But if you like the doing, the typing, fiddling with knobs and configs, etc etc, all AI does is take the good part away.
  • EGreg 1y ago
    Most of my anti-AI takes are either: 1) Bad actors using AI at scale to do bad things 2) AI just commodifying everything and making humans into zoo animals
    • specproc 1y ago
      My anti AI take is that it's no fun. I'm on a small personal project with it intentionally off, and I honestly feel I'm moving through it faster and certainly having a better time. I also have a much better feel for the code. These are all just vibes, in the parlance of our times, but it's making me question why I'm bothering with LLM assisted coding. Velocity is rarely the thing in my niche, and I'm not convinced babysitting an agent is all in all faster. It's certainly a lot less enjoyable, and that matters, right?
    • add-sub-mul-div 1y ago
      More specifically for (1), the combined set of predators, advertisers, businesses, and lazy people using it to either prey or enshittify or cheat will make up the vast majority of use cases.
• james_marks 1y ago
  > Test-Driven Development: generating extensive test cases prior to implementation to guide implementation and prevent regression. I’ve found this concept trips CC up—- assertions are backwards, confusing comments in the test, etc. Just starting a prompt with “Use TDD to…” really helps.
• dkural 1y ago
  This article is a great example of how the human is struggling to extrapolate what happens next. There won't be any humans anywhere near this part of the tech stack, just like no one building a SAAS writes assembly code; or has to put together their own server cluster a datacenter (remember pre-cloud?) for their company anymore. He's dead Jim. No one is telling anyone to ship the ML code without any testing. Human coders also make mistakes. I'll bet that in a few years product managers / QA people would rather work with an ML stack to generate code than a human engineering team. It'll not just be cheaper and faster, but a lot less hassle & more accurate. As an example, Python has roughly ~100 or so "keywords", and extensive public libraries and open source algorithms to call upon. Anyone who thinks this presents any sort of challenge for an LLM to profoundly master is is delusional. They can do IMO-grade math, and help proving novel theorems. They can code your YC startup just fine.
  • chrisloy 1y ago
    Author here - I agree and have written about this before, though focusing a bit more on how far down the stack they might go, rather than up: https://chrisloy.dev/post/2025/03/23/will-ai-replace-software https://chrisloy.dev/post/2025/03/23/will-ai-replace-softwar... Article being discussed in this thread isn't intended to be a luddite rejection of AI. It's just a mistake I see people keep making (and have made myself) and some thoughts on how to avoid it with the tools we have today.
    • dkural 1y ago
      This is a nice article, I misunderstood some of your vision in the original article; thank you for pointing it out.
      • chrisloy 1y ago
        Thank you, glad you enjoyed it!
  • retinaros 1y ago
    Pm and qa people would go before devs. Llms are already better pms than the best pms.
• epolanski 1y ago
  First time I have to accept cookie profiling on a personal website blog. Also, the cookie banner isn't GDPR-compliant.
• AnotherGoodName 1y ago
  I do appreciate that this article moves past absolute negativity on LLMs and actually speaks to the fact that they are extremely useful for well defined programming tasks. I'm a bit sick of articles that are just pure negativity on these tools. I will raise that LLMs are pretty good at some of the non-coding tasks too. eg. "I'm currently creating an AI for a turn based board game. Without doing any implementation, create a plan for the steps that need to be done including training off real world game data". The LLM creates a tasklist for iterative steps to accomplish the above. It usually needs correction specific to the business/game needs but it's a great start and i recommend doing this just so the LLM has a doc with context on what its trying to achieve in a bigger picture as you have it complete tasks.
• danmaz74 1y ago
  LLM coding agents can't learn from experience on our code, but we can learn from using them on our code, and in the context of our team and processes. I started creating some harnesses to help get more of what we want from these tools, and less of what we need to work too much on - eg, creating specialized agents to refactor code and test after it's been generated, and make it more in line with our standards, removing bogus tests, etc. The learning is embedded in the prompts for these agents. I think that this approach can already get us pretty far. One thing I'm missing is tooling to make it easier to build automation on top of, eg, Claude Code, but I'm sure it's going to come (and I'm tempted to try vibe coding it; if only I had the time).
• deleted 1y ago
  [deleted]
• inciampati 1y ago
  Effective coding is not code first think later. LLMs aren't effective when used this way. You still have to think. IMO a vibe coder who is speaking their ideas to an agent which implements them is going to have way more time to think than a hand coder who is spending 80% of their time editing text.
  • ryoshu 1y ago
    A lot of times coding is thinking. It's like sketching out an idea on paper, but with code.
• babyshake 1y ago
  Especially with junior engineers it is helpful to ask them to provide a Loom video or other proof that they have verified a feature or bug works as intended. I have tried setting up Claude Code with playwright to verify it's work, but so far am not very satisfied with the results. Any tools that are helpful with this end to end testing for web apps using Claude Code and other AI assistants? Feel free to share your product if it is relevant.
  • t0mas88 1y ago
    I've seen reasonable results from letting Claude Code apply test driven development and having a good e2e test suite on top of that (with Playwright). In that setup giving it Playwright MCP to access the app and verify why e2e tests are working or not working, and for writing new tests helps. Just giving it an MCP to test changes also didn't work for me. But the combination with e2e tests was better.
  • yeasku 1y ago
    I will go to work anywhere else if I had to review code with videos.
• bikamonki 1y ago
  Not in my experience. I still spend much of the time thinking before prompting. Then I spend time reviewing the AI written code before using it. Does not feel like a trap. It mostly feels like having a super experienced pair programmer. I may be using it differently than others since I do not have it integrated to my IDE. I use it like I used google + stackoverflow before it.
  • kjkjadksj 1y ago
    To be fair you can’t really appreciate if you’ve been trapped unless you test yourself without the ai agent for some time and see if there is a difference in output. If there is, you’ve been trapped.
• itsnowandnever 1y ago
  the flaw in the article is acting like engineers always have a choice. the writers presents the contrasts of "fair delegation vs mollycoddling" mirroring "ai-driven development vs vibe coding"... but that sacrifice for short-term gain at the expense of scale is often draconically enforced. obviously good and experienced engineers aren't going to be vibe coders/mollycoddlers by nature. but many good and experienced engineers will be pressured to make poor decisions by impatient business leaders. and that's the root of most AI anxiety: we all know it's going to be used as irresponsibly and recklessly as possible. it's not about the tech. it's about a system with broken incentives.
• dpflan 1y ago
  Has anyone read up on the recent paper from Meta/FAIR -- CWM: An Open-Weights LLM for Research on Code Generation with World Models Which looks to attempt to give better "coding" understanding to the model instead of mere tokens and positioning and hence improve the coding capabilities of these "brilliant but unpredictable junior engineer" coding agents: - https://ai.meta.com/research/publications/cwm-an-open-weights-llm-for-research-on-code-generation-with-world-models/ https://ai.meta.com/research/publications/cwm-an-open-weight...
• mmaunder 1y ago
  If you know, understand that you are in possession of a massive and temporary information asymmetry advantage, and you should run with it as hard and fast as you can to gain the biggest lead possible, before the author and the rest of the world gain that advantage too. Go, go now, go fast, do it in parallel, and don’t stop until you win. Opportunities like this are extremely rare not just in your life, but in the history of our society. Best of luck.
  • meindnoch 1y ago
    What are you talking about?
    • mmaunder 1y ago
      He doesn’t know.
      • Biganon 1y ago
        Careful, you should be even more cryptic, your comments are almost useful
        • meindnoch 1y ago
          t. knower
    • arandomhuman 1y ago
      Probably something about how using LLMs for coding is such an amazing opportunity or something judging by how he implies the author would be surpassed due to information asymmetry.
    • iammrpayments 1y ago
      Could be either to keep using AI or to give up AI all together, we will never know. This man should probably be a poet.
    • protocolture 1y ago
• pedrellimath 1y ago
  What I don't like about using AI is doing something without planning it first. All software engineering is left aside in exchange for coding -> fixing -> coding -> fixing.
• mordymoop 1y ago
  Broadly the critique is valid where it applies; I don’t know if it accurately captures the way most people are using LLMs to code, so I don’t know that it applies in most case. My one concrete pushback to the article is that it states the inevitable end result of vibe coding is a messy unmaintainable codebase. This is empirically not true. At this point I have many vibecoded projects that are quite complex but work perfectly. Most of these are for my private use but two of them serve in a live production context. It goes without saying that not only do these projects work, but they were accomplished 100x faster than I could have done by hand. Do I also have vibecoded projects that went of the rails? Of course. I had to build those to learn where the edges of the model’s capabilities are, and what its failure modes are, so I can compensate. Vibecoding a good codebase is a skill. I know how to vibecode a good, maintainable codebase. Perhaps this violates your definition of vibecoding; my definition is that I almost never need to actually look at the code. I am just serving as a very hands-on manager. (Though I can look at the code if I need to - have 20 years of coding experience. But if I find that I need to look at the code, something has already gone badly wrong.) Relevant anecdote: A couple of years ago I had a friend who was incredibly skilled at getting image models to do things that serious people asserted image models definitely couldn’t do at the time. At that time there were no image models that could get consistent text to appear in the image, but my friend could always get exactly the text you wanted. His prompts were themselves incredible works of art and engineering, directly grabbing hold of the fundamental control knobs of the model that most users are fumbling at. Here’s the thing: any one of us can now make an image that is better than anything he was making at the time. Better compositionality, better understanding of intent, better text accuracy. We do this out of the box and without any attention paid to promoting voodoo at all. The models simply got that much better. In a year or two, my carefully cultivated expertise around vibecoding will be irrelevant. You will get results like mine by just telling the model what you want. I assert this with high confidence. This is not disappointing to me, because I will be taking full advantage of the bleeding edge of capabilities throughout that period of time. Much like my friend, I don’t want to be good at managing AIs, I want to realize my vision.
  • kristianbrigman 1y ago
    I had the AI implement two parallel implementations of the same thing in one project. Was lots of fun when it was 'fixing' the one that wasn't being used. So yeah, it can definitely muck up your codebase.
• BowBun 1y ago
  For now, my mind is still made up. I leave the door open to be shown any serious piece of software that is built primarily through agentic workflows. Having tried to use these tools over the past month to build a critical piece of infrastructure for my company, I agree with OP. I spent so much time wrangling back unnecessary garbage that the LLM found was important, that I wondered if just writing it in one shot would have been actually faster. Simple things like 'test all this workflow logic' resulted in the LLM inserting a non-sensical mock at the top of the test file that took me an hour or two to unwind. Other than that, I keep hearing the same arguments - "LLMs free up more time for me to think about the 'important things'." Son, your system is not durable, your tests are misleading, and you can't reason about what's happening because you didn't write it. What important things are left to think about??
  • ukuina 1y ago
    > Son, your system is not durable, your tests are misleading, and you can't reason about what's happening You just described the majority of pre-LLM enterprise software.
    • ares623 1y ago
      So let’s make things worse?
  • djeastm 1y ago
    >resulted in the LLM inserting a non-sensical mock at the top of the test file that took me an hour or two to unwind Why didn't you just not accept the change?
    • BowBun 1y ago
      Let's step through the flow: 1. Write up a detailed spec as a prompt, including a bunch of detail about the actual functionality. Add in some details about wanting to test everything. At this point I did not specifically say "Hey LLM, in my tests, do not mock one of the key idempotency functions in this system". This is obvious to me since 1/4 of the system was concerned with idempotency, and this was super clear in my original spec 2. LLM works for 30 minutes, spits out 2.5K lines 3. I review the product functionality and the test cases at a glance, and then start running tests and iterating on the software. If I have to mentally split every line of the LLM output and decide whether it's correct or not (remember, I didn't write the rest of the system), then I lose all the productivity gains that the LLM offers. You don't do this, no one does this unless they're modifying a few lines at a time. My point is that you cannot build robust software from scratch with LLMs right now. They walk right into footguns we've spent decades learning about and building solutions for.
• iLoveOncall 1y ago
  > LLMs are lightning fast junior engineers I cannot express how tired I am of seeing this beyond stupid take. If you truly believe that, you have either only ever worked with the most piss-poor junior engineers, or you simply have never worked with junior engineers. LLMs do not learn, LLMs do not ask clarifications, LLMs do not wonder if they're going in the wrong direction, LLMs do not have taste, LLMs do not have opinions, LLMs write absolutely illogical nonsense, LLMs do not ask themselves what is the best for the customer, LLMs have no context beyond what you have explicitely fed them for that one specific task, and much more.
  • b_e_n_t_o_n 1y ago
    > LLMs do not have taste This is the fundamental issue with LLM's imo.
• jonahx 1y ago
  This diagram (which resonated): Traditional Coding: [ Thinking & Coding ....................... | Fixing ] AI-Assisted Coding: [ Coding | Thinking & Fixing ................ ] suggests a workflow where AI is used almost exclusively to speed up the writing of known, targeted code whose structure has already been thought out. And possibly as a (non-coding) sounding board during the thinking out.
  • sph 1y ago
    The thinking part is the same, yes, but I doubt the fixing is. Fixing something you have written is much easier than fixing something someone else (or an AI) has written, just because you don't have the mental model for the code, which is the most important part of debugging and refactoring.
    • jonahx 1y ago
      Agree completely -- that's what my suggestion was getting at.
• rdrd 1y ago
  Even outside of AI coding I have found a tremendous amount of value in using AI to produce a requirements and spec document for me to code from. The key unlock for me is asking AI to “interview” me about how this system/feature should work. As part of that process it will often ask a question that gets me thinking about interesting edge cases. I will say I always provide an initial context document about the feature/system, to avoid us starting with trivial questions. After about 45minutes I’ll often feel I’ve covered enough ground and given the problem enough thought to really put pen to paper. Off the back of this I’ll ask it to summarise the spec and produce a document. This can be a good point to ditch AI if you are so inclined but still get value from it.
• OutOfHere 1y ago
  Effective AI coding is actually extremely slow if you take into account an exhaustive planning stage where the task specification is laid down in sufficient and unambiguous detail. I had to get the LLM to review my spec over twenty times, always freshly, before I thought it was good enough to be implemented well. Also, it really helps for multiple diverse LLMs to review the spec, as they all have their unique insights. In this way, AI coding also helps me avoid numerous bugs that could have left me in trouble if not for the AI. Once the planning is done, the actual coding is very fast. The human review that follows is again slow, often also leading to minor new tickets.
• polskibus 1y ago
  I think the post, while extensive, missed one important issue. The fact then when we read others' code, we don't remember/integrate it into our thinking as well as we do when we're the authors. So mentoring "AI Juniors" provides less growth then doing the job, esp. if it is mostly corrective actions.
  • ares623 1y ago
    I guess we’ll see the effects in 1 year. I’m personally going to keep myself sharp, only using LLMs very very sparingly.
• budro 1y ago
  I think what the article gets at, but doesn't quite deliver on, is similar to this great take from Casey Muratori [1] about how programming with a learning-based mindset means that AI is inherently not useful to you. I personally find AI code gen most useful for one-off throwaway code where I have zero intent to learn. I imagine this means that the opposite end of the spectrum where learning is maximized is one where the AI doesn't generate any code for me. I'm sure there are some people for which the "AI-Driven Engineering" approach would be beneficial, but at least for me I find that replacing those AI coding blocks with just writing the code myself is much more enjoyable, and thus more sustainable to actually delivering something at the end. [1] https://youtu.be/apREl0KmTdQ?t=4751 https://youtu.be/apREl0KmTdQ?t=4751 (relevant section is about 5 minutes long)
  • dcre 1y ago
    "learning is maximized is one where the AI doesn't generate any code for me" Obviously you have to work to learn, but to me this is a bit like saying learning is maximized when you never talk to anyone or ask for help — too strong.
    • budro 1y ago
      I don't think it was that strong of an over-generalization. AI doesn't seem to help out in the same way a human would. My teammates will push back and ask for proof of effort (a PR, some typedefs, a diagram, etc.). And sometimes they'll even know how to solve my problem since they have experience with the codebase. On the other hand you have AI which, out of the box, seems content to go along with anything and will happily write code for me. And I've never seen it have a single insight on the same level as my teammates. All of which is to say, AI doesn't really feel like something you can properly "ask" something. It's especially far away from that when it's just generating code and nothing else.
  • pietz 1y ago
    Interesting take. I think it boils down to personal preference where some people want to use AI while others don't. I also learn when coding with my AI agent. I learn about using the tool more effectively. As someone who has been coding for 10 years, I find more pleasure in AI assisted coding. But aside from taste, the product and the business don't care about what I like. It's about shipping quality updates more quickly. And while there might be some tension in saying this, I'm convinced that I can do that much more quickly in AI assisted coding.
• vinni3rait 1y ago
  [dead]
• qazxcvbnmlp 1y ago
  What these articles miss: 1) not all coding is the same. You might be working on a production system. I might need a proof of concept 2) not everyone's use of the coding agents is the same 3) developer time, especially good developer time has a cost too I would like to see an article that frames the tradeoffs of AI assisted coding. Specifically without assigning value judgments (ie goodness or badness). Really hard when your identity is built around writing code.
  • mehagar 1y ago
    This article explicitly mentions your first point.
• DrNosferatu 1y ago
  I don't understand why some people are so upset with AI coding - no one forces them to use it. Now, if you say the problem is that you don't want to be inflicted with other people's AI code, just enforce more meaningful tests. There has always been bad code in the past, and there always will be. I, for one, am doing great with AI coding - and my feeling is that more emphasis on project structure is the way forward for better end to end results.
  • phyzome 1y ago
    > I don't understand why some people are so upset with AI coding - no one forces them to use it. You might be a little bit out of touch with the current zeitgeist -- and what's happening in a lot of corporations.
    • yeasku 1y ago
      Time to find a gig in the defense sector.
• dxxvi 1y ago
  There is this statement in the article: LLMs are lightning fast junior engineers. I don't know if that is right or wrong. To me, good LLMs are a lightning fast better version of me. That means that I can write code like some LLMs but it'll take me days to do it (if I use a language that I'm not good at, for example Rust) but with carefully crafted prompts, LLMs take maybe half an hour or less.
  • deleted 1y ago
    [deleted]
  • yeasku 1y ago
    If it took you 2 days and now half hour that is a x32 speed up.
• prostheticrazor 1y ago
  The article is pretty interesting, perhaps some marmite takes, but the bit that chimed with me is the vibe coding vs AI-driven engineering. Senior management at my work is obsessed with vibe-coding and are constantly pushing engineers to promote vibe code to PROD. It’s dispiriting to see parts of our code base begin to fill with manager+LLM slop …
• anotheryou 1y ago
  This omits the deep knowledge required for traditional coding. This opens up coding to non devs, e.g. product managers. For vibe coding you need systems thinking, planning and logic, but less craftmansship. For PO's the chart looks different, here the traditional flow contains: "polish concepts, make mocks, make stories, dailies, handovers, revisions, waiting for devs busy with other things" The vibing PO has none of that. Not saying this is sustainable for big projects already, but it is for ever growing "small" projects (especially if it's a techincal PM that can code a bit). It's just so much faster without devs -_-. Disclaimer: I am such a PO. What I now wonder: how can I mix vibe coding and properly developed foundations (ai assisted, but not 99% vibed). One answer in my view is splitting services in vibecoded and core, but dependencies on the core already slow you down a lot. Curious to hear how others mix and match both. What I actually do right now: - fullstack PoC vibecoded - specifications for core based on PoC findings - Build proper vibecoded V1 mocking what moves to core. But here already a more structured vibecoding approach too. - replace mocks with actual core Not yet done but planned: build throwaway PoC in a branch of the core so I can also vibe on top of the core directly, including modification of the core.
  • kjkjadksj 1y ago
    The deep knowledge really isn’t all that deep. A couple years in the weeds and you have it. What this really hurts is outsourced devs. In the past a non coding person could come up with the spec and hire someone from a developing nation to make it on the cheap to that spec. It is still possible to work like this of course, resulting in working code compared to llm that might hallucinate a passing test condition that you can’t appreciate with your lack of coding chops. It is just the ai seems “faster” and the way it is paid for less in front of your face. Really in practice, nothing new was really gained. Pm always could hire code. Now they hire nondeterministic generated code but they are still essentially hiring code, submitting spec, having something else write the code.
    • anotheryou 1y ago
      But the feedback cycle wait time and the communication workload is almost eliminated.
• system2 1y ago
  This is why you do not use Claude Code for complete project overhaul. For example, if you are writing in Python, categorize your functions and modules very well so that when you ask Claude's help, it won't get lost and start screwing up the entire project. I use modular design with Claude Code very often, and this is the only way I have found it useful. I won't let it change the code of preexisting projects, and only make it analyze individual files/functions for improvements. People without a true coding background get stuck after a single function because the context window is still so narrow, and code assistants do not get the full picture of the project. It reminds me of the offshore developer's work ethic: "But sir, you told me to add this button there like that, so I deleted the entire codebase". Without thinking about why in general. It keeps saying, "You are absolutely right! I shouldn't have done that!" I just like working with a crappy coder from Fiverr or another freelancer site.
• iambateman 1y ago
  I spend more time thinking now that I use Claude Code. I write features that are often 400-600 word descriptions of what I want—-something I never would’ve done beforehand. That thinking does result in some big tradeoffs…I generally get better results faster but I also have a less complete understanding of my code. But the notion that Claude Code means an experienced developer spends less thinking carefully is simply wrong. It’s possible (even likely) that a lot of people are using agents poorly…but that isn’t necessarily the agent’s fault.
• 6thbit 1y ago
  Jumping straight into coding is a very junior thing to do. Using Plan mode in Cline or other agent based workflows is day and night in the outputs. Alas, at least in Cline it seems plan mode doesn’t read files just works off context which is insane to me and hinders its usefulness, anyone know why that happens?
  • consumer451 1y ago
    > Using Plan mode in Cline or other agent based workflows is day and night in the outputs. Agreed. My tool agnostic workflow is to work up a planning/spec doc in the docs/feature-plans folder. I use one chat thread to make that. First it creates the basic plan, then then we pick it apart together, I manually fix bad assumptions, then in a new chat, we implement. Before and after implementation, I run my /gilfoyle command for a constructive roast, then my /sec command for a thorough security review. After implementing this, and a bit more, the final LLM output quality is much higher. edit: adding "make sure we are applying known patterns used in our app for our solution, don't reinvent the wheel." helped a ton. I am on mobile atm, and that might not be the exact wording.
  • jsmith99 1y ago
    Cline plan mode doesn't tend to read files by default but you can tell it 'read all files necessary to establish a detailed plan'. GPT5 also seems more eager to read files.
    • WalterSear 1y ago
      You can just add the files to the prompt with the @ sign.
  • vayup 1y ago
    When it tells me that I need to switch to act mode for it to read files and create a detailed the plan, I just chide gently and ask it to read the damn files in plan mode. Works every time. I wish I dont have to do that.
• indiantinker 1y ago
  It is an interesting take. I teach programming to designers as a part of a course called "Emerging technologies". Although, it is fun to see what students create, but it is not fun to solve doubts. When you are teaching basics, the students would quickly fire up ChatGPT and make some slop up. In the end, I have to fix their codes. I think, the learning output is reduced as they have not written any code. I am genuinely concerned as an educator. One thing that is missing is differentiating AI output and understanding what to keep and what to ignore. The sheer "aesthetic" of it. I feel, many do not take time to develop this very "human" skill and become very output oriented from the very start. This, IMO, affects learning. These tools are also quite addictive due to the sense of 'manufactured' certainty they offer, which is something that hinders learning. What is the point of learning how to add when you have the cheatsheet next to you?
• atleastoptimal 1y ago
  AI coding is more like being a PM than an engineer. Obviously PM’s exist and don’t know as much about the tech they make as the engineers, but are nevertheless useful.
• HellDunkel 1y ago
  The post starts with some valid observation on how to help dev teams mature. And then, all of a sudden the junior devs are replaced by agents. That’s it. End of story.
• shortrounddev2 1y ago
  A friend of mine who is newer to coding than me is worried that by using AI so much, he's losing his ability to code, and its also killing his motivation because using AI to generate code is just not fun. We do "analog coding sessions" together where we code together without LLM assistance. Its much more enjoyable!
  • yeasku 1y ago
    To become an expert in something having feedback is key. With classic coding the feedback loop is very straigth forward and fast. More so with and IDE, you get instant feedback as you write. With LLMs the loop is not as clear.
• crnkofe 1y ago
  Looks like another BS article that tries to compare a junior dev. to an AI. And its not even close. Anyone that actually tried to use AI tooling should know better. Feels like the CEOs that got sold this ideas are force-feeding this idea to senior devs and sadly senior devs are trying to gulp it down instead of rejecting the entire idea. LLMs are more like a lightning fast pseudo-random text generator at this point. To see that though you'd need to run it a few times, test it and understand the output. Something that's a bit beyond the casual amateur ability. Maybe what we need is the AI bubble to burst first. Its sad that we've gotten here though. Every tried having a coffee with your preferred AI as opposed to doing it with a highly motivate junior? Maybe you're not even going to get a chance to experience this.
• alshival 1y ago
  Every day I think to myself: "Just fake it like you want to be here for 30 more years and then you can retire." I have been working in machine-learning for 10 years. I am tired of the computer. I am tired of working. I just want to lay in the grass.
  • djeastm 1y ago
    It sounds like you need a sabbatical.
  • Herring 1y ago
    I’ve been grassing for 7 months. That gets old too.
  • _ink_ 1y ago
    The how-to-become-a-gardener meme comes to mind. But I feel you. Feels like a golden cage currently. It's very comfy, but you waste your life in front of screen.
  • metachris 1y ago
    Can you work less (maybe for some time)? Getting yourself bigger chunks of free time might help. All the best!
• ash_091 1y ago
  The "thinking & coding" vs "thinking & fixing" graph is interesting. I've found this to be the case recently as I've been trying out Codex. I expected to spend a lot of time fixing the AI's code. Weirdly that has led to me spending a long time fixing issues which turn out to be nothing to do with the code. Most recently I was struggling to get an authentication setup working. I spent at least an hour combing through the code looking for the mistake. The issue turned out to be that the VM I was working on had a broken ipv6 configuration.
• strangescript 1y ago
  I appreciate these takes, but I can't help to think this is just the weird interim time where nothing is quite good enough, but in a year an article like this would clearly be "overthinking" the problem. Like when those in the know could clearly see the internet's path to consuming everything but it just hasn't happened yet so there were countless articles trying to decide if it was a fad or not, a waste of money, bad investment, etc.
  • yeasku 1y ago
    I have been folowing the things Open AI does for 10 years. Now it works, not like before, gets old after a while.
• Sleaker 1y ago
  Article seems to cherry pick Microsoft marketing to claim 10% gains, when the Harvard ran study from earlier this year showed a 10% slowdown. Id rather articles point first at the research being done that's agnostic of any corporation trying to push its propaganda if possible.
• jalopy 1y ago
  Every time I read stuff like this I honestly wonder if the author is using the same tools I am. I can have Claude Code bang out everything from boilerplate to a working prototype to a complex algorithm embedded in a very complex and confusing code base. It’s not correct 100% of the time but it’s pretty damn close. And often times it comes up with algorithms I would have never thought of initially. These things are at least a 10x multiple of my time.
  • Herring 1y ago
    Popular != true. Galileo found that out by spending the last ~decade of his life under house arrest. Thankfully today we mostly just get downvoted.
  • komali2 1y ago
    The difficulty is we skeptics have read claims like yours tens of times, and our response is always, "please share a repo built this way and an example of your prompts," and I at least have never seen anyone do so. I'd love for what you say to be possible. Comments like yours often cause me to take another crack at agentic workflows. I'm disappointed every time.
    • deleted 1y ago
      [deleted]
    • yeasku 1y ago
      Most AI evangelist commenters here end up with the same arguments every time. You are just not a true scotsman. And when they link something is one of those repos full of sloop and no code. I am becoming paranoid and wonder how many people here can even code.
      • komali2 1y ago
        It is a bit funny that 4 hours on and still no replies from the evangelists. I want them to be right and me wrong! Please someone show I am wrong.
• rgarcia 1y ago
  The article assumes that AI coding is thoughtless, but prompting is writing, and writing is thinking. If you approach AI coding the same way as regular programming, your thinking phase involves crafting a prompt that describes your thoughts.
• malshe 1y ago
  Does anyone know how to make the diagrams and charts in this blog post? I liked the style.
  • Brajeshwar 1y ago
    Looks like done in https://excalidraw.com https://excalidraw.com
    • chrisloy 1y ago
      Correct!
    • malshe 1y ago
      That's wonderful. Thanks a lot!
• topherPedersen 1y ago
  I agree with this. My bosses boss thinks that AI is going to end up doing 95% of our work for us. From my experience (so far) AI coding follows the 80/20 rule, it can get you 80% of what you want for 20% of the time/effort. And the ratio might be more like, it'll get you 80% of what you want IMMEDIATELY, but it can't get you the last 20%, it needs a human to get it over the finish line. It's super impressive in my opinion, but if you think it's going to straight up replace humans right now, I think you probably aren't a software developer in the trenches cranking out features. I'm sort of a Neanderthal when it comes to understanding AI, but I don't think AI in it's current form works like a human. Right now, it kind of just cranks out all the code in one fell swoop. A human on the other hand works more iteratively. You write a little bit of code then you run it and look at an iPhone simulator, look at Figma designs, and see if you're getting closer to what you want. AI doesn't appear to know how to iterate, run code, look at designs, and debug things. I imagine in 100 years it will know how to do all that stuff though. And who knows, maybe in 1 year it will be able to do that. But as of right now, September 28th, 2025 it can't do that yet.
  • closeparen 1y ago
    I agree about the 80/20 part. On the workflow front, there’s been enormous progress from Copilot to Cursor to Claude Code just in the last 2 years. A lot of this is down to the plumbing and I/O bits rather than the mysterious linear algebra bits, so it’s relatively tractable to regular software engineering.
  • sothatsit 1y ago
    This tracks with my AI usage as well. I often use AI to get the first 80% of the work done (kinda like a first draft), and then I finish things off from there.
  • DustinKlent 1y ago
    It depends on which application you're using. Applications like "RooCode", which is a free extension for VSCode, have several "modes" which allow the user to create an outline of the project using an "architect" LLM, followed by coding the project with a "Coding" LLM, followed by debugging the project with a "Debugging" LLM if there are bugs. There's also an LLM that answers questions about the project. Only the coding and the debugging LLMs do actual coding but you can set it so you have to approve each change it makes.
• TuringNYC 1y ago
  The article writes "“Code first, ask questions later” AI coding agents such as Claude Code are making it astonishingly fast to write code in isolation. But most software lives within complex systems, and since LLMs can't yet hold the full context of an application in memory at once, human review, testing, and integration needs will remain." But this is the case also with human teams. Plenty of human teams cannot understand "the full context of an application [sometimes ever]" -- same with contractors who roll on and off teams or entire contracting firms who roll on and off.
• jwpapi 1y ago
  Honestly whilst I started vibe coding I don’t want ai to touch my codebase anymore. AI has been insanely helpful for a couple of reasons, but not for writing code. I discuss my plans with AI and check if I missed out on edge cases I develop to the most common conventions, I ask AI for better naming, ideas for abstractions, to explain me frameworks, find me packages. But the lease couple of days I’m having sanity problems because there is one AI tool after the other coming up with a new plan on how to use AI efficiently but once you’ve solved a problem is it really much work to type it out? It shouldn’t be too much code if correctly using orchestration. It’s almost like all the beautiful conventions and patterns are forgotten. Good Code is most of the time less code. Yes imho most important is readability or digestibility or even diagnosability like all of these things get completely forgotten when we start talking about AI and I see AI far off in writing such code. Good frameworks and packages will be faster. AI is a good sparring partner and encyclopaedia especially living in terminal but I just don’t see it should writing a lot of code (except maybe landing pages with css animations) that don’t live in a complex application
• woah 1y ago
  > While the LLMs get to blast through all the fun, easy work at lightning speed, we are then left with all the thankless tasks: testing to ensure existing functionality isn’t broken, clearing out duplicated code, writing documentation, handling deployment and infrastructure, etc. These chores are exactly what AI is best at
• i-chuks 1y ago
  Are we all going to pretend there's not some subtle Claude Code marketing taking place?
• BatteryMountain 1y ago
  I've been using claude code for the past 2 months and I spend most of my time in it's planning mode, which is just amazing to flesh out a good plan. After having a very good/specific plan, it usually one-shots the implementation. If I have a bad plan, it executes poorly. The other thing that makes a big difference is using a language that has strong typing and a strict compiler. You can allow claude to call the complier, analysers, debuggers and so forth and it works amazing to keep code quality consistent if you tell it always follow your existing patterns. Lastly, I figured out recently, quite by accident, that claude can call adb/logcat on a connected android device, to ingest real debug logs while my app is running, which can be a firehose of logs. It cuts through it like candyfloss and spots runtime errors significantly faster than a human can read all those log. It found a bug for me that was nearly impossible to find with the IDE & breakpoints, just by ingesting the debug/logcats outputs directly. So overall the article is great, I do think the way we work can and will fundamentally change in the coming years.
• classicmotto 1y ago
  Software will be fully replaced with adaptive AI systems that shift form based on multimodal input & interaction. Current AI models, especially small ones, are quite smooth-brain by themselves. But, if we can refine them to a point where thinking AI systems can run on smart glasses and smartwatches in a usable, stable state, we can assume by then larger AI systems with higher compute are bound to be much more capable. We can claim AGI milestone then. And, the real race for superintelligence begins.
• karlkloss 1y ago
  My impression is, that AI is currently used to get rid of the junior coders, while burning out the senior coders. Later, you'll realize that there are no new senior coders to burn out, because you got rid of the junior coders, but we're not there yet.
  • DustinKlent 1y ago
    Why should we assume that LLMs would be stagnant at current levels when, so far, they haven't stopped improving? I remember when simply using Copilot to just auto-complete 1 line of code was a groundbreaking unimaginable advancement. That was only a few years ago. New and improved models are being released nearly every week. The open-source models are nearly as advanced as the closed source models (if you have the hardware to run them at full capacity).
• capestart 1y ago
  [dead]
• pietz 1y ago
  I don't know how the author uses AI coding tools, but all agents I've been using recently (Codex and Claude Code) do planning and exploration before writing code. I don't even know how it would work the other way around. I do see different behavior whether planning or exploration comes first though.
• Michael_Keller 1y ago
  [dead]
• earth2mars 1y ago
  cert error
• hunkmuller0 1y ago
  [dead]
• stareatgoats 1y ago
  Another day, another anti-ai coding post hits the HN front page. Meanwhile, reality makes a whooshing sound.
• valeriaortiz 1y ago
  [dead]