16 ms·

I'm going back to writing code by hand

• archleaf 4mo ago
  So what you really mean is you are going to do better and more detailed skills files so you can get an architecture that you've thought through rather than something random?
  • dropbox_miner 4mo ago
    Partly, but the order matters. The CLAUDE.md constraints only work if you designed the architecture first. They're just how you communicate it to the AI. The mistake I made wasn't writing bad skills files, it was not designing anything at all and expecting the AI to make coherent structural decisions across 30 sessions. The rewrite is me sitting down with a blank doc and drawing the boxes before any code exists. Then the CLAUDE.md enforces what I already decided. Whether that actually holds up as the project grows, I genuinely don't know yet.
    • cpncrunch 4mo ago
      Are you really saving any time at all using AI at all then? If you have to write the architecture for it, write all the rules you want it to follow, check everything it's written, and then reprompt it because it's not how you want it?
      • SpicyLemonZest 4mo ago
        Yes. I do all of this and I'd estimate 50-100% coding time savings. A lot of that comes from better multitasking over single-workstream throughput, which I suppose might compromise the gains depending on what you're doing. For me it amplifies the speedup by allowing some of my "coding time" to be spent on non-coding tasks too.
        • cpncrunch 4mo ago
          But even if coding time is reduced by half, is that worth the downsides? Coding has never really been a major percentage of my time.
          • SpicyLemonZest 4mo ago
            I could be wrong in some subtle way I'm not seeing, but I believe the model we're working in avoids the downsides. I actually think my review bar is slightly higher now, because I don't feel as much pressure to compromise my standards when I know Claude is capable of writing the code I want.
            • cpncrunch 4mo ago
              I would say the main downside is not knowing what all your code does, and where to find any particular function. After the initial coding is complete, will you need to use AI to fix bugs? Presumably that is both slower and more expensive than doing it by hand when you know exactly where to look?
• gjvc 4mo ago
  [flagged]
• binyu 4mo ago
  > I'm rewriting k10s in Rust. Not because Rust is better but, because it's the language I can steer. I've written enough of it to feel when something's wrong before I can articulate why. That instinct is the one thing vibe-coding can't replace. The AI hands you plausible-looking code. You need a nose for when it's garbage. Isn't Golang relatively easier to read than Rust? I was under the impression that Rust is a more complex language syntactically. > The other change is simpler: I'm doing the design work myself, by hand, before any code gets written. Not a vague doc. Concrete interfaces, message types, ownership rules. The architecture decisions that the AI kept making wrong are now made in writing before the first prompt. This post is good to grasp the difference between "vibe-coding" and using the AI to help with design and architectural choices done by a competent programmer (I am not saying you are not one). Lately I feel that Opus 4.7 involves the user a lot more, even when given a prompt to one-shot a particular piece of software.
  • dropbox_miner 4mo ago
    Go reads fine whether the architecture is good or bad, and I couldn't tell the difference until I was in trouble. Rust is harder to read but harder to misuse. The borrow checker would have caught that data race at compile time. I've also just written more Rust. That familiarity matters separately. +1 on Open 4.7 involving the user a lot more. Rn I'm trying to get to a state where I can codify my design + decision preferences as agents personas and push myself out of the dev loop.
    • binyu 4mo ago
      Gotcha, that implies you are going to read the code that the AI produces anyways. > Go reads fine whether the architecture is good or bad Were you reading the Golang code all along and got fooled or did you review it after it failed? Sorry I admit I didn't read the whole article.
      • williamstein 4mo ago
        He was NOT reading the code: "For 7 months I'd been prompting and shipping without ever sitting down and actually reading the code Claude wrote."
• erelong 4mo ago
  Can't you just ask AI to break up large files into smaller ones and also explain how the code works so you can understand it, instead of start over from scratch?
  • dropbox_miner 4mo ago
    That was actually the first thing I tried. It did a good jov at explaining the code base mess and the architecture. Then I ran 3-4 refactor attempts. Each one broke things in ways that were harder to debug than the original mess. The god object had so many implicit dependencies that pulling one thread unraveled something else. And each attempt burned through my daily Claude usage limit before the refactor was stable. And I'm sure the rewrite is going to teach me a whole different set of lessons...
    • tres 4mo ago
      What's your test coverage like? Not sure why good coverage wouldn't mitigate risk in a refactor... My mantra whenever I'm working with AI is that I want it to know what "point b" looks like and be able to tell by itself whether it's gotten there... If you have a working implementation, it sounds like you have a basis for automated tests to be written... once you have that (assuming that the tests are written to test the interface rather than the implementation), then it should be fairly direct to have an agent extract and decompose...
  • joshuanapoli 4mo ago
    Rewrite following a new architecture plan could get finished pretty quickly, treating the original as a prototype.
  • SpicyLemonZest 4mo ago
    When people talk about codebases being "incomprehensible", it's not always hyperbole. Sometimes the architecture literally cannot be broken up or understood.
    • whattheheckheck 4mo ago
• epec254 4mo ago
  Not sure if just me, but this post feels AI written?
  • pipeline_peak 4mo ago
    Feels a bit too long winded to be AI generated.
    • filoeleven 4mo ago
      That's when he went back to writing his posts by hand.
  • weregiraffe 4mo ago
    You are absolutely right.
• mpurbo 4mo ago
  Strict SDD might help to constrain and harness the process.
• AIorNot 4mo ago
  This doesnt make much sense the article itself is AI written It would have been easy to run a few ai agents to review the code and find these issues as well and architect it clearly
• keithnz 4mo ago
  AI writes what you ask it to write, you need to talk to it about architecture. You should have an architecture doc so AI can shape the code based on that, you can get the AI to make the architecture doc also. If using claude you can use the software architecture mode for this.
• xantronix 4mo ago
  So you're not actually writing code by hand? I'm very confused by the difference between the title and the conclusion here.
  • rane 4mo ago
    The point was to come up with a sensationalistic headline that HN eats up and post flies to the front page.
    • Towaway69 4mo ago
      I wonder whether the title was generated/suggested by an AI?
  • deleted 4mo ago
    [deleted]
  • dwedge 4mo ago
    I don't think they even wrote the article by hand. It seems like the title got to the top of HN not the article.
• nothinkjustai 4mo ago
  Writing code by hand is an oxymoron. You don’t write code with AI, AI doesn’t write, it generates.
• apt-apt-apt-apt 4mo ago
  Outright lie clickbait. As he states himself, he's doing the design work by hand, and will likely still use AI to write code.
• EMM_386 4mo ago
  You don't need to go back to coding by hand if you know how to do it already. There is a middle ground. If you understand good software architecture, architect it. Create a markdown document just as you would if you had a team of engineers working with you and would hand off to them. Be specific. Let the AI do the implementation of your architecture.
• kypro 4mo ago
  > I learned over these 7 months 7 months ago was early November. Coding assistants were getting very good back then, but they were still significantly poorer at making good architectural decisions in my experience. They tended to just force features into the existing code base without much thought or care. Today I've noticed assistants tend to spot architectural smells while working and will ask you whether they should try to address it, but even then they're probably never going to suggest a full refactor of the codebase (which probably is generally the correct heuristic). My guess is that if you built this today with AI that you wouldn't run into so many of these problems. That's not to say you should build blind, but the first thing that stood out to me was that you starting building 7 months ago and coding assistants were only just becoming decent at that time, and undirected would still generally generate total slop.
• shahbaby 4mo ago
  This reads too much like it was LLM generated. I can't say for sure if it was but I have an allergic reaction to the short snappy know-it-all LLM writing style.
  • fromwilliam 4mo ago
    yeah, it set off my llm radar too
  • baxtr 4mo ago
    Writing code by hand but blog post are written by LLMs?
  • TranquilMarmot 4mo ago
    AI;DR
• plastic041 4mo ago
  Title says > back to writing code by hand But what they are doing is > doing the __design work__ myself, by hand, before any code gets written. So... Claude still is generating the code I guess? And seriously, I can't understand that they thought their vibe coded project works fine and even bought a domain for the project without ever looking at source code it generated, FOR 7 MONTHS??
  • dewey 4mo ago
    I bought domains for projects minutes after the idea. I don’t think it’s that weird to not look at the code if it’s a side project and you follow along incrementally via diffs. It’s definitely a different way of working but it’s not that crazy.
    • bayarearefugee 4mo ago
      > I don’t think it’s that weird to not look at the code if it’s a side project and you follow along incrementally via diffs. Its not weird to not look at the code, as long as you're looking at the code? (diffs?) Uh, ok
      • retsibsi 4mo ago
        The article explicitly says that the author looked at the diffs; it distinguishes this from "sitting down and actually reading the code", which they didn't do. So when plastic041 says the author spent 7 months vibe coding "without ever looking at source code", it's not unreasonable for dewey to assume that "looking at source code", in this context, actually means something stronger and excludes just looking at the diffs.
  • 0xpgm 4mo ago
    In short, it is simply a click-bait title. And the goal of the article is to draw attention to their project.
    • kdheiwns 4mo ago
• ipaddr 4mo ago
  When he mentions I push commits at work for as long as my tokens last I can understand that. Managing tokens has become an important skill.
• photochemsyn 4mo ago
  Does ‘writing code by hand’ mean you’re not going to use compilers to generate assembly? Now I do feel lucky that I started learning coding about four years before the LLM revolution, but these things are really just natural language compilers, aren’t they? We’re just in that period - the 1980s, the greybeards tell me - where companies charged thousands of dollars per compiler instance, right? And now, I myself have never paid for a compiler. This whole investor bubble will blow up in the face of the rentier-finance capitalists and I’ll be laughing my head off while it happens.
  • green_wheel 4mo ago
    Nondeterministic natural language compilers
    • photochemsyn 4mo ago
      Just because the trajectory is chaotic doesn't mean it’s not deterministic.
      • zephen 4mo ago
        A model, given exactly the same inputs, will return exactly the same outputs. But your prompts are not the only inputs. Among other things, there is a random seed injected by the vendor. That is a primary source of non-determinism. Then, of course, is the fact that you don't personally have an old copy of the model, and the vendor isn't going to keep the model forever, and there are no unit tests to make sure that, faced with prompts like you gave it before, the newer models won't suffer major regressions in the functionality you were using. And even if there were no non-determinism, the models suffer greatly (much more so than traditional compilers) from the butterfly effect. It is literally impossible to pin down part of your prompt in such a way that it always will contribute to good outcomes, and such that you can simply vary a tiny bit of the prompt to logically correlate with tiny variations in the output.
  • platevoltage 4mo ago
    So C++ doesn't count as code now.
• snowe2010 4mo ago
  > The other change is simpler: I'm doing the design work myself, by hand, before any code gets written. Not a vague doc. Concrete interfaces, message types, ownership rules. That’s the hard part of coding. If you have an architecture then writing the code is dead simple. If you aren’t writing the code you aren’t going to notice when you architected an API that allows nulls but then your database doesn’t. Or that it does allow that but you realize some other small issue you never accounted for. I do not know how you can write this article and not realize the problem is the AI. Not that you let it architect, but that you weren’t paying attention to every single thing it does. It’s a glorified code generator. You need to be checking every thing it does. The hard part of software engineering was never writing code. Junior devs know how to write code. The hard part is everything else.
  • staplers 4mo ago
    You need to be checking every thing it does. This is what seems to be lost on so many. As someone with relatively little code experience, I find myself learning more than ever by checking the results and what went right/wrong. This is also why I don't see it getting better anytime soon. So many people ask me "how do you get your claude to have such good output?" and the answer is always "I paid attention and spotted problems and asked claude to fix them." And it's literally that simple but I can see their eyes already glazing over. Just as google made finding information easier, it didn't fix the human element of deciphering quality information from poor information.
    • brabel 4mo ago
      Looking at code looking for errors is a hard thing to do well for a large amount of code. A better approach is to ensure tests cover all the important cases and many edge cases. Looking at the code may still be a good idea but mostly to check the design. I think that once you get Claude to test the code it writes well, trying to find errors in the code is a waste of time. I’ve made the mistake of thinking Claude was wrong many times despite the tests passing just to be humbled by breaking the tests with my “improvements”!
    • krilcebre 4mo ago
• Decabytes 4mo ago
  We should go back to designing UML diagrams for programs before we write them /s
  • khutorni 4mo ago
    I think we should, to a reasonable degree.
  • ki_sum_ai 4mo ago
    I'm rereading the 1994 Design Patterns: Elements of Reusable Object-Oriented Software.
• genghot 4mo ago
  [flagged]
• imperio59 4mo ago
  Alternate title: "I did not understand the current limitations of AI and assumed it could do large software design and it generated spaghetti slop" Yea, that's why engineers are still very important for now (until models can do this type of longer term designs and stick to them).
• ljoshua 4mo ago
  > tl;dr: AI writes features, not architecture. This. I definitely agree with this statement at this point in AI-assisted development. This gets at the "taste" factor that is still intrinsically human, especially in software engineering. If you can construct and guide the overall architecture of an application or system, AI can conceivably fill in the smaller feature bits, and do so well. But it must have a strong architecture and opinionated field in which to play.
  • littlecranky67 4mo ago
    My main takeaway, too. Been using Claude on my side project that I have singlehandledly been working on for three years. It works well initially, you catch all of AIs mistakes or unfavorable approaches because you know the architecture in and out. But as you stop thinking about the new features, stop losing touch with all the stuff AI throws at you, you fail to develop intuitive feeling on when and how to abstract and introduce architecture. Another note was for me e2e tests; while AI can write them it never comes up with just basic organization or abstraction required to manage a large e2e test suite with hundreds of tests. It immediately starts to produce spaghetti code.
• Myrmornis 4mo ago
  > I typed :rs pods to switch back to the pods view. Nothing rendered. The table was empty... > now something was fundamentally broken and I couldn't just prompt my way out of it. Hey I don't want to over simplify, I'm sure it was complicated, but did the author have functional tests for these broken views? As long as there are functional tests passing on the previous commit I'd have thought that claude could look at the end situation and work out how to get the desired feature without breaking the other stuff. TUIs aren't an exception, it's still essential to have a way to end-to-end test each view.
  • jvuygbbkuurx 4mo ago
    The problem wasn't the view didn't work. The problem was the view didn't work after something else had been done. You can't test every permutation of app usage. You actually need good architechture so you can trust your test and changes to be local with minimal side-effects.
    • Myrmornis 4mo ago
      > The problem was the view didn't work after something else had been done. In that situation you have two choices: 1. Tell claude to iterate until the tests for the new view and the old views are all passing. 2. git reset --hard back to the previous commit at which all tests are passing and tell claude to try again, making sure not to break any tests. It's essential to use tests when vibecoding anything non trivial. Almost certainly in a TDD style.
• eggplantemoji69 4mo ago
  TLDR ai wrote tech debt slop because I vibed for 7 months, now I am taking a hybrid approach of defining strict constraints before vibing…
• d_silin 4mo ago
  It absolutely looks like AI psychosis.
• amelius 4mo ago
  So how are people writing the specifications for AI? Do they write empty functions and let AI fill them in? Or do they use some kind of specification language? Are people designing those languages?
• Havoc 4mo ago
  That's a strange definition of "code by hand"
• sakesun 4mo ago
  A coder typing in code is not solely to generate outcome. It's part of ongoing thinking process. Without this ongoing process, we have no material to keep iterating forward.
• scuff3d 4mo ago
  I feel like this article was circling a point it never actually got to. All the advice in here (except controlling scope creep) is specific to a TUI with an elm like architecture. But here's the thing, you almost never know what the architecture is up front. If you do you probably aren't the one writing the actual code anymore. Writing the code, with or without an AI is part of the design process. For most people it isn't until they've tried several times, fucked it up a bunch, and refactored or rewrote even more that you actually know what the architecture needs to be.
• royal__ 4mo ago
  The title is just flat out wrong. The author isn't going back to writing code by hand, they're plopping some new stuff into their CLAUDE.md to "fix" the issues they see AI is having.
• cortesoft 4mo ago
  What has really made AI coding be able to continue to work as the project got bigger was using speckit. It has been great at keeping the code consistent across features. https://github.com/github/spec-kit https://github.com/github/spec-kit
  • nopurpose 4mo ago
    Did you evaluate other projects, like openspec, before deciding on spec-kit?
• viceconsole 4mo ago
  > Vibe-coding makes you feel like you have infinite implementation budget. You don't. You have infinite LINE budget (the AI will generate as much code as you want). But you have the same finite complexity budget as always. This is a special case of a general fundamental point I'm struggling with. Let's assume AI has reduced the marginal cost of code to zero. So our supply of code is now infinite. Meanwhile, other critical factors continue to be finite: time in a day, attention, interest, goodwill, paying customers, money, energy. So how do you choose what to build? Like a genie, the tools give us the power to ask for whatever we want. And like a genie, it turns out we often don't really know what we want.
  • TranquilMarmot 4mo ago
    Right - knowing what to actually build always has been and always will be the limiting factor to actual success. I could spend months and hundreds of dollars generating the absolute BEST todo list that's out there but nobody wants that.
  • ozim 4mo ago
    I have vibe coded 3 applications I never had time to code but always wanted. Now it is different in a way where now I don’t have time to use those apps. That’s a joke. But I do believe it answers the question of “what to build?”. If you didn’t have time before LLM assisted coding you still don’t have time for it. You most likely know what is used and what not already by heart or by some measurements.
• vladsiu 4mo ago
  [dead]
• jesse_dot_id 4mo ago
  LLMs assist those of us who were apt to take blocks of code from StackOverflow, or wherever, to solve problems quickly and avoid as much of the aggravating and slow toil of trial and error as possible. That trial and error process is still happening with a LLM, but much faster, and with instantaneous cross-references to various forms of documentation that I would be looking up myself otherwise. It produces code of a quality that is dependent on the engineer knowing what they want in the first place and prompting for it and refining its output correctly. It's the exact same process of sculpting code that the majority of the industry was doing "by hand" prior to the release of LLMs, but faster, and the harnesses are only getting better. To "vibe code" is to prompt vaguely and ignore the quality of the output. You're coming to a forum full of professionals and essentially telling us that you're getting really frustrated with your Scratch project. I don't know if you're trying to lead a charge or whatever but good luck with that. As a senior SWE, it is clear to me that this is the new paradigm until something better than LLMs comes along. My workflows and efficiency have been vastly improved. I will admit that I have never really been a "I made a SMTP server in 3k of Rust" kind of guy, though.
• andrew_kwak 4mo ago
  [flagged]
• rnxrx 4mo ago
  I'm not sure we'll ever really be free of the GIGO (garbage in / garbage out) principle. Tools will get better and better, but can never be a substitute for a deep understanding of the thing we want to create.
• RuoqiJin 4mo ago
  This is Claude's problem. Compared to GPT-5.5, Claude Code prefers to take shortcuts. I've tested having codexapp GPT-5.5 and Claude Code opus4.7 do the same thing - if following GPT-5.5's requirements, Claude Code's execution time for a task would stretch from 5 minutes to 40 minutes. To solve macro architecture problems, I use Lisp to write the entire program's framework. Lisp replaces architecture documents, because I believe it has high semantic density, syntax restrictions, and checkers for assistance. This way, at least I didn't have to rework anything anymore. I used this method to refactor my 20+ projects
• hirako2000 4mo ago
  Research also makes similar claims: https://arxiv.org/html/2603.24755v1 https://arxiv.org/html/2603.24755v1
• Jatin-Mali 4mo ago
  [flagged]
• nothinkjustai 4mo ago
  I don’t really think OP is writing code themselves since they admit they still use agents for code gen. I’ve really scaled back the amount I use agents though because in the medium to long term I haven’t been getting good results with them. And it’s not enjoyable. That’s enough for me, I’ll do whatever for a job because who cares, if the company wants slop I will gladly give them that, but for my own shit Ive gone back to circa 2024 and am mostly just using them as a chatbot. Inb4 “you’re gonna be replaced” god damn it I hope so, I do not want to spend the rest of my life behind a computer screen…
• baddash 4mo ago
  I've set a few rules for working with coding agents: 1. If I use a coding agent to generate code, it should be something I am absolutely confident I can code correctly myself given the time (gun to my head test). 2. If it isn't, I can't move on until I completely understand what it is that has been generated, such that I would be able to recreate it myself. 3. I can create debt (I believe this is being called Cognitive Debt) by breaking rule 2, but it must be paid in full for me to declare a project complete. Accumulating debt increases the chances that code I generate afterwards is of lower quality, and it also feels like the debt is compounding. I'm also not really sure how these rules scale to serious projects. So far I've only been applying these to my personal projects. It's been a real joy to use agents this way though. I've been learning a lot, and I end up with a codebase that I understand to a comfortable level.
  • dathanb82 4mo ago
    I’ve also heard it being called “comprehension debt,” which I like a little more because I think it’s more precise: the specific debt being accrued is exactly a lack of comprehension of the code.
    • baddash 4mo ago
      Yeah I like that better too, gonna start using that
    • cassianoleal 4mo ago
      I think it’s both in fact. Comprehension debt just sounds like there are things you don’t (yet) understand. Cognition debt means your lack of understanding compounds and the cognition “space” required to clear it increases accordingly. An increasing comprehension debt that can be paid off one bit at a time within reasonable cognition space takes linear time to clear. Cognition debt takes exponential time to clear the more of it you have. If it reaches a point where you simply don’t have the space for the cognition overhead required to understand the problem, you probably need to start over from your specifications.
      • 4mo ago
• localhoster 4mo ago
  another behavior I noticed is that even you plan with an agent than a lot of business logic leaks to the code. some states, for an example, are meant to be assumed from the data shape, rather than the actual state fields, but damn they like adding a state field.
• Aeolun 4mo ago
  I think the answer here is to not use Claude with bubble tea. I tried the same thing and got the same result. But it seems to be limited to that specific framework, because it's really good at not doing the same thing with SolidJS.
  • neomantra 4mo ago
    While I felt this in 2025, I do not feel this in 2026. I use Claude and the rest with BubbleTea all the time. But I will say... you have to know Golang. You have to have at least tried to make a BubbleTea app yourself and try to understand ELM architecture. You have to look at the code and increment with it. It makes total sense for OP to switch to Rust and Ratatui if they don't know Golang well. But I don't think it's a better language for it. [Ratatui has brought me great inspiration though!] Independent of framework, the LLMs get the spacial relationships. I say things like "the upper right panel's content is not wrapping inside and the panel's right edge should extend to the terminal edge" and the LLM will fix it. They can see the resultant text, I'm copy-pasting all the time. TUI code is finicky; one mis-rendered component mucks everything up. The LLMs will decide themselves make little, temporary BubbleTea fixtures to help understand for itself when things aren't right. The only real problem with LLMs and BubbleTea is that upon first prompt, they insist on using BubbleaTea v1 versus BubbleTea v2, released in December 2025. But then you just point it to the V2_UPGRADE.md and it gets back on track. That will improve as training cutoffs expand. I vibe-coded this TUI for Mom's last night. I actually started with Grok (who started with v1) and then moved into Claude Code after some iteration: https://gist.github.com/neomantra/1008e7f2ad5119d3dd5716d52ec96e83 https://gist.github.com/neomantra/1008e7f2ad5119d3dd5716d52e...
• FpUser 4mo ago
  >"I'm doing the design work myself, by hand, before any code gets written." This is what I was doing right from the beginning. AI just fills out methods and doing other low intelligence work. Both are happy. My architectures and code are really mine, easy to read and reason. AI gets paid and does not get a chance to fuck me in the process. At no point I felt any temptation to leave "serious" to AI.
• tvbusy 4mo ago
  I don't think the prompts that the author has proposed will actually work. Including final scope and non-scope is good but it's more of a reaction of what the AI already did. These prompts are suitable for a rewrite, basically, since it's unlikely anyone would have had these ready when they start out. I have found small iterations to have the best results. I'm not giving AI any chance to one shot it. For example, I won't tell it to "create a fleet view" but something more like "extract key binding to a service" so that I can reuse it in another view before adding another view. Basically, talk to the AI as an engineer talking to another engineer at the nitty gritty level that we need to deal with everyday, not a product person wishing for a business selling point to magically happen.
• pjmlp 4mo ago
  I am still mostly coding by hand, other than meeting the KPIs of AI use at the company, required trainings, use of agents and whatever. Eventually like every hype wave the dust will settle, and lets see where we stand. By now all the AI companies have consumed all human knowledge so they either learn to actually think for themselves, or that is it. Either way, that won't change the ongoing layoffs while trying to pursue the AI dream from management point of view.
  • 0xpgm 4mo ago
    > Either way, that won't change the ongoing layoffs while trying to pursue the AI dream from management point of view. I think most companies doing layoffs are bloated to begin with, AI is just the scapegoat to do the layoffs.
    • pjmlp 4mo ago
      I am aware of layoffs that are really caused by AI. Translation and asset generation teams for enterprise CMS, whose role has now been taken by AI. Likewise traditional backend development, that was already reduced via SaaS products, serverless, iPaaS low code/no code tooling, that now is further reduced via agents workflow tooling, doing orchestration via tools (serverless endpoints).
• devinabox 4mo ago
  [dead]
• bbbflgllglhlld 4mo ago
  Luddite.
  • recursive 4mo ago
    Seems to be an unstated assumption that the Ludds were wrong.
• magic_hamster 4mo ago
  Let me preface my comment by saying I also still write a lot of code by hand - especially when it's something I know I need to understand in depth, and in some cases defend. With that said, this caught my eye: > AI gravitates toward single-struct-holds-everything because it satisfies the immediate prompt with minimal ceremony. This is too general. "AI" is used here as a catch-all, but in fact, it was the specific model under the specific conditions you ran your prompt, including harness, markdowns, PRDs, etc. So it's not fair to say "AI does X!" in this case. It's also very much up to you. It's very common to have a frontier model plan an architecture before you have another model implement code. If you're just one-shotting an LLM to do everything you get mediocre, more brittle code. This stuff is still being figured out by a lot of people. But I feel the core of the issue is not using AI well. Scoping, task alignment, validation, are crucial.
• eranation 4mo ago
  I used to write code by hand. I still do, but I used to, too.
• Laoujin 4mo ago
  I'm just wondering: you know what architecture you want to go to now and you have the tests... can't you just let Claude refactor it to the better architecture? Also 1600 lines... didn't any agent reviewing the diffs point that out? You're also adding a lot to claude.md, I dunno how much that file has grown but a big claude.md file with many instructions, I don't think the ai will be able to remember all those rules
• Laoujin 4mo ago
  I'm just wondering: you know what architecture you want to go to now and you have the tests... can't you just let Claude refactor it to the better architecture? Also 1600 lines... didn't any agent reviewing the diffs point that out? You're also adding a lot to claude.md, I dunno how much that file has grown but a big claude.md file with many instructions, I don't think the ai will be able to remember all those rules.
  • my-next-account 4mo ago
    > can't you just let Claude refactor it to the better architecture? In my experience, no. These tools suck at refactoring, mostly choosing to add more code instead.
• dr_girlfriend 4mo ago
  i try to write one portable shell script per day; using AI would take all the fun out of it, so i never started using it. i honestly find it ridiculous that anyone uses it to write code, it just doesn't make sense to me.
• z3t4 4mo ago
  Vibe coding works great with test driven development. You can have AI write the tests as well, but you need to confirm yourself because it's lying all the time. AI coding is like when you first started out, it's copying random bits and pieces from the web into your code until it works... Good for one shots and proof of concept. But for any long living project I think you are better off rewriting it from scratch yourself. Abstractions let you work faster, especially when you have it all in your head.
• codingfisch 4mo ago
  It's pretty simple to vibe code for months without producing slop. And it's the same recipe one used before AI: 1. make it work 2. make it pretty 3. make it fast Omit 2. and 3. long enough -> slop beyond recovery
• radicalbyte 4mo ago
  I don't understand the people who "get the agent to do everything" for them. It just makes a mess if you do that. Yet if I spend a little bit of time setting a project up properly (including telling my minions exactly what to do) I can then get it to do the boring things for me. The very worst things you can do in a codebase are (a) not deeply understand how it works (have it be magic) and (b) be lazy and mess up the structure. How do you fix a problem which happens at 2:00am and takes your system down if you don't have an excellent understanding of how it works? Over time we're already bad at (a) because most developers hate writing documentation so that knowledge is invariably lost over time.
• UrbanNorminal 4mo ago
  Wow ok, I will too then. Fuck AI!
• blueTiger33 4mo ago
  nuts
• cultofmetatron 4mo ago
  the ship has sailed on my handcoding at work. the AI is producing stuff thats more bulletproof than what I can do in the same timeframe and if my competitors are using it, the pressure to ship is that much higher. Personally, I've taken the time its freed up to spend more time on mathacademy and reading more theory oriented books on data structures and algorithms. AI coding systems are at their best when paired with someone with broad knowledge. knowing what to ask for and knowing the vocabulary to be specific about what you want to be built is going to be a much more valuable job skill going forward. One example is a small AI based learning system I have been developing in my free time to help me learn. the mvp stored an entire knowledge graph and progress in markdown files. being an engineer, I knew this wouldn't scale so once I proved the concept viable, I moved everything into sqlite with a graphdb. then I decided to wrap some parts of teh functionality in to rust and put everything behind a small rust layer with the progress tracking logic still being in python. someone with no knowlege of graph databases or dependncy graphs or heuristics would not be able to build this even if they had AI. they simply don't know what they dont' know and AI wont' save you there. That said, I think its important to also spend time in the dirt. I've recently started pickign up zig as my NO AI langauge just to keep. those skills sharp.
  • oblio 4mo ago
    > the ship has sailed on my handcoding at work. I'm really curious if we'll seesaw once AI costs go up 10x.
    • wartywhoa23 4mo ago
      And they will.
    • cultofmetatron 4mo ago
      I've been relying primarily on deepseek-v4-flash for 90% of my work. It sips tokens. that model will run on 128gb. not a cheap configuration for a consumer but within the budget of a developer relying on it for work. Ive only been using kimi 2.5 and deepseek pro for reviewing PRs for security issues. less than 10% of my workflow requires a full powered frontier model. I think the issue is overblown by people who think claude code is a good harness and use opus for everything. opencode is objectively better. its much more verbose about what its doing, you have more control when it comes to offloading to subagents with targeted context (crucial for running through larger jobs) and I can swap between codex and open weight models.
• deleted 4mo ago
  [deleted]
• youre-wrong3 4mo ago
  This is the wrong take. If you keep “vibe” coding and end up with bad results you should probably question your ability.
• IanCal 4mo ago
  I feel like I’m watching developers speed run project and product management learnings. We’ve moved to seeing that specs are useful and that having someone write lots of wrong code doesn’t make the project move faster (lots of times devs get annoyed at meetings and discussions because it hinders the code writing, but often those are there to stop everyone writing more of the wrong thing) We’ve seen people find out that task management is useful. Now more I’m seeing talk of fully doing the design work upfront. And we head towards waterfall style dev. Then we’ll see someone start naming the process of prototyping, then I’m sure something about incremental features where you have to ma age old vs new requirements. Then talk of how really the customer needs to be involved more. Genuinely, look at what projects and product managers do. They have been guiding projects where the product is code yet they are not expected to read the code and are required to use only natural language to achieve this.
  • meetingthrower 4mo ago
    So right. All these guys have never been managers. Do you think humans don't write things that break? Or that teams sometimes take a wrong path and burn a week of work? Or months? Well now you can experience all of that in 30 minutes of vibecoding. As a former tech product manager, it feels EXACTLY the same.
    • yakshaving_jgt 4mo ago
      Except it isn't the same because the cost is different, which allows discovery that we couldn't afford previously.
      • meetingthrower 4mo ago
        Yes x 1000. I find it amazing.
      • IanCal 4mo ago
        Yes, lots of the process and problems and solutions to them are the same but we’ve just massively cut the cost of a part of development. That has huge ramifications about when it makes sense to tackle different things and how tradeoffs work out. Was it strongdm talking about the dark factories? They were working on some integration software so needed to use google drive and slack and lots of other things. They fully reimplemented those to the level they needed for their tests - outside of the biggest firms this would probably have been an enormous time and money sink. Now it’s reasonable. On a personal project, with my wife we wanted a tracker for holiday planning. Five minutes given a barely through through request and we had a working prototype, fixed bugs in seconds and then talked through with a model what we needed and how it did or didn’t fit (and we needed that first version to figure that out). It helped drive out actual requirements from us, prioritise them, choose a stack add tickets and then went ahead and implemented it pretty far. Have a mostly working v2 which has highlighted some details about what we really wanted. Total invested cost was one day of a $20 subscription and maybe half an hour of talking to a bot and checking results.
• jasonvorhe 4mo ago
  When the title stands in opposition to the actual post, I'm not gonna engage with that author again.
• Towaway69 4mo ago
  If you're coding by hand, then you're that carpenter before IKEA came along. Now the market wants bland machine-built functional furniture that gets replaced every five to ten years. If every tenth piece is broken or slightly off, doesn't matter, mass production has lowered the price that a replacement is available for free and you're still making a profit. Time to become a "product engineer" and watch the hyper-agile agents putting up digital post-it notes on digital pin-boards discussing how much each post-it is worth in digital scrum meetings. Meanwhile the agents keep wasting more and more time so that their owners make less and less of a lose, until eventually a profit is made. Until the costs become prohibitive and humans become cheaper than the agents that replaced them. Once the agents are replaced by the humans, the next hype bubble awaits around the bend. /s
• 20k 4mo ago
  I always find these kinds of posts interesting, to compare the velocity that people seem to get with Ai, vs what I get by just coding by hand Coincidentally I've been working on a project for about 7 months now: its a 3d MMO. Currently its playable, and people are having fun with it - it has decent (but needs work) graphics, and you can cram a few hundred people into the server easily currently. The architecture is pretty nice, and its easy to extend and add features onto. Overall, I'm very happy with the progress, and its on track to launch after probably a years worth of development In 7 months vibe coding, OP failed to produce a basic TUI. Maybe the feature velocity feels high, but this seems unbelievably slow for building a basic piece of UI like this - this is the kind of thing you could knock out in a few weeks by hand. There are tonnes of TUI libraries that are high quality at this point, and all you need to do is populate some tables with whatever data you're looking for. Its surprising that its taking so long There seems to be a strong bias where using AI feels like you're making a lot of progress very quickly, but compared to manual coding it often seems to be significantly slower in practice. This seems to be backed up by the available productivity data, where AI users feel faster but produce less
  • manicennui 4mo ago
    This is probably because the people who feel like they receive the most benefit from LLMs never actually knew much about or were just incapable of writing good software before they started using LLMs.
  • thot_experiment 4mo ago
    It's more complex than that, I think the reality is that there's a lot of code that's just not that deep bro. I have some purely personal projects that have components that I don't understand anymore, I wrote that shit by hand, they still work but I haven't touched that shit in years. There's a lot of code that AI can write that's like that that helps me, the stuff I would forget about even if I wrote it by hand. I think you have to have discipline in it's use, it's a tool like any other. AI, and especially agentic AI can make you lose situational awareness over a codebase and when you're doing deep work that SUUUUCKS, but it's not useless, you just have to play to it's strengths. Though my favorite hill to die on is telling people not to underestimate it's value as autocomplete. Turns out 40 gigabytes of autocomplete makes for a fucking amazing autocomplete. Try it with llama.vim + qwen coder 30b, it feels like the editor is reading your mind sometimes and the latency is so low.
• simon84 4mo ago
  Personally, i've taken a serious step back from 'unsupervised' vibe-coding. When the codebase is clean and you want some additional fix or small feature, Claude is quite good at mimicking your style and does a pretty good job. When asking for a new major feature, despite hard guidelines and context (that eat half your context window), then it quickly ships bloat. The foundations are not very well organized and this is where you acknowledge it is all about random-prediction of the next word-thing. Overall, i've wasted more time reviewing the PR and trying to steer it properly than I expected. So multi-layer agent vibe coding is no longer the way to go *for me*. Maybe with unlimited tokens and a better prompt, to be investigated...
  • Rapzid 4mo ago
    And it can quickly start spiraling out of control. The bloated implementations keep adding more and more context it needs for the next change. Discovery results start getting worse, implementations get worse, and bloat continues to increase.
    • simon84 4mo ago
      Actually it was sort of fun to see that the AI started writing comments to itself by gradually explaining what it was trying to do and ways it failed to do it. Then it spent more time appending comments to its own comments rather than writing code ^^
• zem 4mo ago
  I don't bother trying to give the LLM a set of dos and don'ts for how to write the code, that becomes a frustrating game of whack-a-mole. I find it a lot more efficient to have it write some code, look it over, and if I'm not happy with some of the decisions give it specific instructions for how to fix that one part. as a bonus I end up reinforcing my knowledge of the code base in the process.
• holografix 4mo ago
  Good luck finding a job. All the decision making business people I know see only two types of “technical people”. The ones who are “AI pilled” and the contagious lepers.
• jwpapi 4mo ago
  That’s the same story I had. The swindle goes like this, AI on a good codebase can build a lot of features, you think it’s faster it even seems safer and more accurate on times, especially in domains you don’t know everything about. This goes in for a while whilst the codebase gets bigger and exploration takes longer and failure rate increases. You don’t want it to be true and try harder so you only stop after it practically became impossible to make any changes. You look at the code again and there is so much code spaghetti is an understatement it’s the Chinese wall. You start working…, and you realize what was going on I deleted 75,000 of 140,000 lines of code and I honestly feel like the 3 months I went hard into agentic coding I wasted and I failed my users by building useless features increasing bugs, losing the mental model of my code and not finding the problems I didn’t know about the kind of hard decisions you only see when you in the code, the stuff that wanders in your mind for days
  • mjburgess 4mo ago
    I think this is true, but i imagine there's a workflow solution to this which isnt to drop AI. Eg., treating AI code generated as immediately legacy, with tight encapsulation boundaries, well-defined interfaces etc. And integrating in a more manual workflow. There's a range from single-shot prompts to inline code generation, that will make more sense depending on the problem and where in the code base it is. Single-shot stuff is going to make more sense for a protyping phase with extensive spec iteration. Once that prototype is in place, you then prob want to drop down into per-module/per-file generation, and be more systematic -- always maintaining a reasonably good mental model at this layer.
    • timacles 4mo ago
      This is like getting a person addicted to drugs and then asking them to only use the drugs on Thursday and Friday. This seems to me like it requires an impossible level of discipline, judgement and foresight
    • herrherrmann 4mo ago
      That workflow just sounds exhausting to me. Would I always need to consider how much of a blast radius my AI-generated code might have? Sounds like there’s so much extra management going into these micro decisions that it ultimately defeats the purpose of generating code altogether. I could see value in using it during the prototyping phase, but wouldn’t like to work like you described for a serious project for end users.
• yason 4mo ago
  We're still in the early ages and must discern hard what AI is good for, what it can maybe do, what it could potentially do and what it just can't do, and move those threshold marks very conservatively. AI is also cheap enough that it's worth shots of experiments. As long as you don't really rely on AI it's easy to test the capabilities of this new conversational autocomplete, and the random gains it offers can be magnificent (except when they aren't, of course). What has generally worked for me is paraphrasing the old adage "Write the data structures and the code will follow" over to AI. Design your data, consider the design immutable and let the AI try fill in the necessary code (well, with some guidance). If it finds the data structures aren't enough, have it prompt you instead of making changes on its own. AI can do lot of the low-hanging fruit and often the harder ones as well as long as it's bound to something. Yet, for now, AI at best has been something that relieves me from having to write a long string of boring code: it's not sustainable to keep developing stuff relying on AI alone. It's also great when quality is not an issue; for any serious work AI has not speeded me up noticeably. I still need to think through the hard parts, and whatever I gain in generating code I lose in managing the agents. But I can parallelise code generation, trying new approaches, and exploring out because AI is cheap. AI is also pretty good for going through the codebase and reasoning about dependencies whether in the context of adding a new feature or fixing a bug: I often let AI create a proof-of-concept change that does it, then I extract the important bits out of that and usually trim down the diffs down to at least 1/3 or less. AI further helps with non-work, i.e. tasks that you have to do in order to fulfill external demands and requirements, and not strictly create anything solid and new. I can imagine AI creating various reports and summaries and documentation, perhaps mostly to be consumed and condensed by another AI at the receiving end. Sadly, all of this is mostly things not worth doing anyway. Overall, I cringe under all the hype that's been laid on AI: it's a new tool that's still looking for its box or niche carveout, not a revolution.
  • ktzar 4mo ago
    I don't think we're in the early ages... LLMs technology has essentially stagnated since GPT3.5, we just have bigger models that can handle more context. We're trying to cope for the lack of progress of the actual technology by coming up with contraptions of multiple models stuck together, Mixture-of-Experts, Reviewer models, PM models...
• AntiUSAbah 4mo ago
  Im exploring currently if i should split up a project into a framework part and the game itself (2d, idle game). The framework could be an isolation later against viberod but not sure if its necessary for my small project i always wanted to do and never done anything with it. For another tool, i will try another approach: Start with a deep investigation and spec write together with AI, than starting with the core architecture layout and than adding features. So instead of just prompting "write a golang project with a http server serving xy, and these top 3 features" i will prompt "create a basic golang scarfold for build and test" -> "create a basic http server with a basic library doing xy" -> "define api spec" -> "write feature x" There is kind a skill and depth to vibe coding though.
• throwaway2027 4mo ago
  I'm thoroughly enjoying using AI to write code, but it paid off by years of doing things the hard way before. I already was a so called "10x developer" if I speak for myself. I'm doing things even faster now with AI.
• throwmo999 4mo ago
  [dead]
• Fokamul 4mo ago
  I also code by hand. But in my main work, reverse engineering, LLMs are godsend, for years now. You can basically bruteforce binary obfuscation thanks to them. And thanks to eager chinese LLM providers, basically for free. But I always use LLM only for boring work and rest is for me to do manually, or with scripts of course, but made by me. Because I want to learn. Yes, there are a lot people using LLMs for full RE automation since they're selling exploits for profit. No problem with me. I see funny future for huge corporations like Adobe, etc. Imagine prompt, "Hey Claude, re-implement Adobe Photoshop with clean-room design" One agent will open decompiler, outputs complete low level technical details how is everything implemented. Second agent implements new Photoshop based on that. They will be mad and I like this. You will own nothing, and you will be happy, corpos.
  • duskdozer 4mo ago
    >Second agent implements new Photoshop based on that. >They will be mad and I like this. I suspect through some convoluted legal mechanism this kind of thing is going to end up applying only to copyleft laundering and not against players like Adobe.
• pron 4mo ago
  Yep. The only people I've heard saying that generated code is fine are those who don't read it. The problem is that the mitigations offered in the article also don't work for long. When designing a system or a component we have ideas that form invariants. Sometimes the invariant is big, like a certain grand architecture, and sometimes it’s small, like the selection of a data structure. You can tell the agent what the constraints are with something like "Views do NOT access other views' state" as the post does. Except, eventually, you'll want to add a feature that clashes with that invariant. At that point there are usually three choices: - Don’t add the feature. The invariant is a useful simplifying principle and it’s more important than the feature; it will pay dividends in other ways. - Add the feature inelegantly or inefficiently on top of the invariant. Hey, not every feature has to be elegant or efficient. - Go back and change the invariant. You’ve just learnt something new that you hadn’t considered and puts things in a new light, and it turns out there’s a better approach. Often, only one of these is right. Often, at least one of these is very, very wrong, and with bad consequences. Picking among them isn’t a matter of context. It’s a matter of judgment, and the models - not the harnesses - get this judgment wrong far too often. I would say no better than random chance. Even if you have an architecture in mind, and even if the agent follows it, sooner or later it will need to be reconsidered. What I've seen is that if you define the architectural constraints, the agent writes complex, unmaintainable code that contorts itself to it when it needs to change. If you don't read what the agent does very carefully - more carefully than human-written code because the agent doesn't complain about contortious code - you will end up with the same "code that devours itself", only you won't know it until it's too late.
  • 21asdffdsa12 4mo ago
    And the solution is the same, as when it was outsourced- and the "patch" was fix it by writing spec. Thus i conclude my TED talk with the statement: LLMs are the new outsourcing and run into the same problems.
    • i_love_retros 4mo ago
      Don't outsource either then
• ninjahawk1 4mo ago
  A problem often ignored is that while AI is trained on human written code, how it writes is different in practice. Will that improve or get worse? One would argue that LLMs in general are drastically more competent now than they were a couple years ago, they’re also much better at coding. We’re likely just now entering the era where they can code but are still not what you’d fully expect, or at least not what someone with absolutely no coding knowledge could use to code at the same level as someone who does know how to code. Maybe that changes as the models improve, maybe it doesn’t, only time will tell.
• neals 4mo ago
  I'm moving very slowly into AI coding. I'm not comfortable enough to let Claude do anything big. What I do is this: I set out general architecture, create function stubs and add comments on how to implement things. Then I let Claude do 10 minutes of work and I check everything and refactor some of it. It saves me on boring implantation stuff (like, is this an array, move an index here or there, check for whatever exists or not, put it in the db)
• larusso 4mo ago
  I ran quite early into the same issues with my rust pet projects. Single structs with tons of Option<T> and validation methods etc. enums for type fields combined with says optional fields in the same layer so accessor methods all return Option<T>. I add now a long list of instructions how to work with the type system and some do’s and don’ts. I don’t see myself as a vibe coder. I actually read the damn code and instruct the ai to get to my level of taste.
  • hmhhashem 4mo ago
    Would you be interested in sharing your findings? I'm currently experimenting with LLM-generated rust and honestly think it works quite well, however I'm looking for ways to improve the "taste" of the agent.
    • larusso 4mo ago
      I pushed a gist https://gist.github.com/Larusso/82c9aa8effb3031d149d3b5a1b965d0d https://gist.github.com/Larusso/82c9aa8effb3031d149d3b5a1b96...
      • hmhhashem 4mo ago
        Thanks :)
• Serhii-Set 4mo ago
  [dead]
• mindaslab 4mo ago
  I'm going back to writing algorithms on paper.
• aryan_kalra12 4mo ago
  I've been saying the same thing and I'll repeat it again: AI is still gonna take away your job even If you switch domains.
• spicyusername 4mo ago
  It's really very easy to spend a few hours going through a vibe-coded project by hand and having an agent fix the weird parts. If you do this often enough, you can get the best of both worlds. Then you're right back on track. In a way it's not that different from a human-made project. Plenty of teams have to crunch, ignoring the architecture and incurring tech debt, and then come back and fix it later.
  • ex-aws-dude 4mo ago
    That’s what I found too I have to periodically get it to do a bunch of refactoring
• khasan222 4mo ago
  I’m not very familiar with Go, however after looking at the repo I can’t help but notice there is no infra to ensure code quality. Do others see the same thing, because if so that is the real problem Yes I agree for sure llms write terrible code when left to their own devices, but so do most engineers. Which is why we have so many tools to help keep a certain level of quality. Duplication checks, tests, linters, other engineers. I find whenever you make an llm repo without these checks, and more, it will write like an enthusiastic junior engineer, wrong and strong. However a junior engineer would be hard pressed to get 95% coverage on a codebase, the ai is more than willing and does it in a few minutes. We can use things like this to our advantage, how many people have ever seen a repo with 100% test coverage? With ai this is very possible, with people not so much. LLM’s writes terrible code, we know this, but when dealing with humans that write terrible code we have many techniques. We should be using those same techniques to keep the llms honest, but more importantly verifiable.
  • shimman 4mo ago
    Go has a built-in tools that mimic formatting + linters. Also LSP is a first class citizen in Go. I don't know what other "code quality" infra there is out there aside from formatting and linting.
• mtrovo 4mo ago
  Most of the issues are around code hygiene rather than just LLM code being bad. You're creating code 10x faster, but you're also writing unit tests 10x faster, not just that but integration tests, CICD workflows, prod monitoring, product and engineering documentation, etc. It was already the way to get good code quality before, nowadays I think it's just reckless to generate code that's not backed by 100% test coverage and pass all lints and static checks configured.
  • mountainriver 4mo ago
    This is it, people are acting like bad code wasn’t written before. My wife and I were full on laughing about it in bed the other night of all the absolutely horrible code we’ve seen written and how people actually think LLMs are worse than that. The quality gates are up to you, and if you are smart you will make a lot of them and review them closely
• deleted 4mo ago
  [deleted]
• nopurpose 4mo ago
  Feels like it can be solved wirh even more AI: adverserial models reviewing and testing work performed by main model. Actually I am curikus to try somwthing like that myself. Is there an existing orchestrating engine (or single agent) which can spawn multiple subagents and keep passing their feedback/output between each other until all of them agree that assignment overall is complete?
• eddy-sekorti 4mo ago
  Yes, i also do this, the old feeling of writing something, deploying, testing and fixing the bugs is good. Vibecoding can never replace this feeling.
• devmor 4mo ago
  I dismissed “AI Psychosis” as a silly term, even as a strong critic of LLMs for programming tools. > For 7 months I'd been prompting and shipping without ever sitting down and actually reading the code Claude wrote. But every time I read something like this, I seriously wonder about the mental state of the person that wrote it. How do you get to this point?
• moveax3 4mo ago
  Code writers have changed, but the conceptual mistakes remain the same.
• djeastm 4mo ago
  When it was Copilot tab-completing lines, people would say, "yea, but you still have to make sure you're the one writing the whole functions". Then when it was completing functions, people would say, "yeah, but you still have to make sure you're the one writing the logic around the functions" Then when it was completing the logic around the functions, people would say, "yeah, but you still have to make sure you're the one writing the features" Now it's completing features and people say, "yeah, but you still have to make sure you're the one writing the architecture" I don't know if architecture is a solvable problem for these models, but it is interesting watching the expectations moving over time.
  • hansmayer 4mo ago
    > Now it's completing features It's completing shit. Even if it does not implement some lazy stuff with empty catch blocks (i.e. happy path from programming 101 tutorials), it will either expose your secrets in a sensible place or do some other stupidity.
  • dzonga 4mo ago
    the autocomplete can be shit some times.
  • vrganj 4mo ago
    As somebody with a colleague that is using AI agents to "complete features", let me tell you, it is not. It is taking that dude so much longer to prompt and reprompt and then prompt again until it is anywhere close to something that passes review than it would take any competent mid-level engineer to just build the whole thing with some autocomplete help. Have people's standards for quality just completely vanished in the pursuit of the shiny new thing? Is that guy doing something wrong? That has also been my experience with this sort of thing fwiw, which is why I gave up and do more of a class-by-class pairing with an LLM as a workable middle ground.
  • raincole 4mo ago
    The "people" in your hypothetical story have been wrong the whole time. The correct attitude is: When AI can complete lines, you still have to read and understand the code. When AI can complete whole functions, you still have to read and understand the code. When AI can complete features and tickets, you still have to read and understand the code.
• lacymorrow 4mo ago
  [flagged]
• m3kw9 4mo ago
  Greed really comes into play when using LLM's to write code, is so easy to say YES when this cool feature where 2 years ago would have taken a week, now is 1 day or even one prompt. The "Say no" skill that Steve Jobs said was important is gonna be needed on an minute by minute basis.
• dwedge 4mo ago
  Clickbait title about not writing code by hand anymore, both the article and future code generated by AI. This is meta.
• luodaint 4mo ago
  [flagged]
• IceDane 4mo ago
  This doesn't make any sense to me. The problem with this dev's approach is not AI, it's their use of it. They didn't ensure that the architecture made sense. They didn't look at the code and get a "feel" for it. They didn't do the whole build stuff, step back, refactor, rinse and repeat dance. The need for that hasn't gone away; if anything, it's even more important now. Because you can spit out code 100x faster than you could before, your tech debt compounds 100x faster. The earlier you refactor, the less work it is. I usually give the agent a solid idea of what I want, often down to the API interfaces. Then every now and then, I'll go through the code and ensure that everything makes sense, and that I'm not just spitting out code that works, but building a codebase that scales.
• hsaliak 4mo ago
  I wrote https://github.com/hsaliak/std_slop/blob/main/docs/mail_mode.md https://github.com/hsaliak/std_slop/blob/main/docs/mail_mode... to avoid the brain rot from just shooting slop. It has helped me stay sane, review code and make changes step by step. I dont go as fast as with other agents, but this works for me, and I enjoy the process.
• icmpkitty 4mo ago
  [dead]
• kccqzy 4mo ago
  > AI builds features, not architecture. I see this in Claude too, but I also see this in junior engineers. In the case with Claude, I simply ask it to refactor immediately after each feature is done. The human is still responsible for the AI writes, so if the AI writes code that’s gross, I would never push that lest it sully my name and my reputation for my own code quality.
• wotsdat 4mo ago
  [dead]
• web007 4mo ago
  So much of the problem here is that the author blindly trusted the agent. They're enthusiastic juniors, not jaded seniors. Prompt for what you want. Get your feature working, then cut: reduce SLOC, refactor to remove duplication, update things to match existing patterns. You might do these instinctively, or maybe as-you-go, but that's just style. Having a dedicated pass works just as well. The same thing goes for my code now that did when I wrote every line by hand: make it work, then make it good, then make it manageable. Manually that meant breaking things down into small blocks of individual diffs inside a PR (or splitting PRs), checking for repetitive code and refactoring, or even stashing what I got to and doing it again with the knowledge of how things went wrong. Agents can do the same. It's WAY easier mentally and works out better if you treat them the same way and go working -> better -> done.
• floodfx 4mo ago
  Genuinely curious if you've used "plan mode" (with perhaps a plan feedback tool) to get clarity from your coding agent before unleashing it on a feature like "add a pods view with live updates"? Getting a plan isn't a panacea but is a better way to limit downstream slop than just vibing without one.
• Kepler_X 4mo ago
  [dead]
• haolez 4mo ago
  I've started using OpenSpec[0] recently to mitigate problems like that, but I'm still very early in this journey. Can someone with more experience with it (or similar tools) chime in and confirm that this isn't just more AI snake oil? :) [0] https://openspec.dev/ https://openspec.dev/
  • pramodbiligiri 4mo ago
    Some kind of planning / speccing out is becoming inevitable. No personal experience with openspec but I do rely on generating plans, and then a set of tasks from the plan. And keeping a close eye on what's going as the tasks are churned through (although I wonder if simply saying Yes to the diffs has been adding much value /shrug). Matt Pocock talks about specs and Openspec after 23:00 minute mark and again after 33:00 minute mark here: https://www.youtube.com/watch?v=-QFHIoCo-Ko https://www.youtube.com/watch?v=-QFHIoCo-Ko. He doesn't believe in simply translating specs-to-code. He emphasizes tracer bullets, TDD, setting up quick feedback loops.
• abalashov 4mo ago
  I went back to writing code by hand quite some time ago and cannot say there has been any loss of velocity or productivity for it. I really do think this whole thing is a wash.
• snickerbockers 4mo ago
  I like to explain my opposition to vibe coding by replacing the phrase "write code for you" to "fuck your wife for you". You could make all the same arguments that the AI could do a better a job, its never impotent, it frees you from being pressured to do it when you might be tired or not in the mood etc. But thats not the point and most people would still be opposed to sort of, err, "vibe vibrating". I feel the same way about coding, its a source of pride for me and when I hear people say I should resign myself to being an "ideas guy" while chatgpt actually creates things I find the very concept to be distasteful regardless of whether or not it can outperform me.
• theunmanagedboy 4mo ago
  The cognitive debt caused by AI autocompletion and Agent stuff is real. I'm feeling it right now. I started a project on my own, writing every line of code but then out of timeline pressure I started using Claude Code. The atrophy it has caused to go and edit the code is real. I'd rather rely on the slot machine than my own experience. SAD!
• deeviant 4mo ago
  Have you people ever read human generated code? Good grief, you act the like human code is not a disaster 9 times out of 10.
• fitsumbelay 4mo ago
  I wonder how viable this debate is outside of dev circles. For example, if I'm new to programming today and I'm not part of any community that necessarily approves agentic coding or disapproves of vibe coding and I heard that C programs run fast as heck and I heard that I can automate jobs 1,2 and 3 with such a program, I generate said program and it works as expected per my limited experience then what's the issue? Perhaps in a couple of weeks I notice I'm missing 1/4 of my HD space and I figure out probably via an agent that my cool C program is creating bloat through caching or creating hidden dot files, so I agentically/vibe-ally generate a patch. Maybe this encourages me to join a community of other amateurs or a pro-am community where I learn specifics - eg. the exact bug(s) in my code -- as well as metas -- eg. testing. There will probably be millions and millions of people generating code for their own purposes thanks to LLMs, and the number grows as the technology develops and becomes more trivial. So I wonder how much value there is in the "how to think about this" discussion vs the "how to use this" discussion. It almost feels like religious encampments are forming over a false -- possibly manufactured -- lines of division
• sim04ful 4mo ago
  My opinion is that we're using the wrong paradigms for LLMs. We should be leaning more on declaratively specifying behaviour. If there's any hope for reliability, auditability, predictability to be had it lies in contraining and LlMs grammar whilst delegating freeform behavior to a more passive substrate.
• desireco42 4mo ago
  I understand, and I saw this problem. It's actually quite hilarious that he got this far before noticing it. But again, if you just guide the AI on architecture and review the code, you should be fine. The code that you write and the code that an AI writes are two different things; they will never be the same. The AI is very helpful for generating code, and that is exactly how you should use it: as a code generator.
• ilaksh 4mo ago
  He says he went several months without having to do a code review and it worked the vast majority of the time. That's incredibly impressive work by the AI. AI may default to mediocre and often somewhat buggy code unless you iterate because that is just what the vast majority of human written code that it has seen looks like. But the fact that he got away with not reviewing the code for so long to me proves the opposite of his conclusion. 1690 lines of code in one file is a walk in the park for SOTA models. He can just say something like: "Please review and create a refactoring plan and test suite. I found atrocious architectural decisions like numerous special cases and if statements rather than using abstractions properly. Make a few notes in comments and architecture.md to never do this again." One could also argue that it was a better decision each time by the AI to just never do a refactor unless prompted because that increases the likelihood of something breaking and you want to do that after you verify the minimum code change actually functionally does what you want. Also I bet you the headline is a lie. He basically admits it by saying he is writing the core structure of the next version by hand ahead of time, implying that he will generate the rest. So the title is a half-truth at best.
  • wolttam 4mo ago
    > Also I bet you the headline is a lie. He's already 5k+ LOC into the rust rewrite...
• selfsimilar 4mo ago
  > For 7 months I'd been prompting and shipping without ever sitting down and actually reading the code Claude wrote. I'd look at the diff, verify it compiled, test the happy path, move on. But now something was fundamentally broken and I couldn't just prompt my way out of it. I stopped reading after this, because this is the dumbest way to vibe code anything larger than a single-use tool. Claude is a collaborator, and honestly a decent voice of dissent, but it will never offer that unprompted. "Make this thing" - "OK". You need to review the code. You need to say "I want this, AND HERE IS THE LONG-TERM VISION. Now offer critique and the trade-offs for various implementations." Or just realize that in every hand-written project you learn the contours of the problem space as you go along and if the tool is big enough you'll feel the urge to do a green-field rewrite of hand-rolled code after a few years. You get there quicker with the robot's help. This is not a new lesson.
  • gosukiwi 4mo ago
    bad devs are still bad, good devs are still good
    • shimman 4mo ago
      Until the good devs have their skills atrophied away.
• graphememes 4mo ago
  they are just doing design work now, they could have done design work with go too, without even knowing go clickbait title
• deferredgrant 4mo ago
  [flagged]
• peterbell_nyc 4mo ago
  I'm generally in agreement with everyone here. - Some code is ephemeral - it's generated to do the thing, thrown away end of session and the csv was imported successfully (or whatever). Make sure you have at least some testing of the output or you may find the email is in the last name field for some rows. If possible, have an API your agent uses with rich domain types and validations that force it to do things right or do them again (and that it' can't rewrite to relax the constraints!) - You can one or few shot a real app - for a few users, for a small set of use cases. Scope of this will improve with models, but at least today it's spelling bee app for my kids" not "salesforce replacement for millions of workers". - You can add rich validation steps for all types of quality that you care about which (assuming they converge) can deliver high performance, well designed and functionally correct code mostly autonomously. I'm building an orchestrator (who isn't). Haven't looked at the code yet, but it appears to work. But man have I spent hours in loops between Claude, Codex and myself all on the highest thinking levels to figure out what interface portability means for the employee, how best to handle "remote" sessions and the appropriate semantics for pipelines/recipes. I've also been very opinionated about who does what. I'll let the agent write a script to sync with github and reload workers, but I decided to "waste" the 5 minutes to manually do all of the config steps on render for my server when claude told me that I couldn't just give it read only scope to pull the logs. Bad news, I'm cutting and pasting for my computer overlord. Good news? Claude can't blow away the prod db if it happens to get in the way of whatever interpretation is makes of the instructions I give it. A chainsaw requires very different skills that an axe. It has different failure modes. Some experience as a lumberjack probably helps using either/both. No difference (at least now) with agents.
  • tombert 4mo ago
    I have found that for low-stakes stuff, where "good enough" really is ok, Claude and Codex have been pretty great. I don't particularly care if the code is optimal, just enough to do that job. For example, I had Claude generate a language server for TLA+ so I could have nice keystrokes in Neovim. For things like this, I really do think there is such thing as "good enough"; a language server doesn't have to be perfect, and the stakes are pretty low, where I think the worst case scenario is that it screws up my code, but that should be relatively easy to catch in Git. I have been trying to mostly have Claude generate code from specifications; either a Mermaid diagram for simpler stuff, and TLA+ for more complicated stuff. I usually supply a lot of surrounding context about how I want these specs to be implemented, and it will usually get me about 90% of the way there, but I've found that I still need to hack against it to get over the hump. It makes me feel a little valuable; I finally have an excuse to use formal methods for things.
• openswissdata 4mo ago
  [flagged]
• slowhadoken 4mo ago
  I never stopped but I focused more on concept and design.
• dailywriterguy 4mo ago
  As a writer, this resonates. There's a massive difference in good human "writin" and a dozen paragraphs of "it's not x, it's a y". But unfortunately everyone "reads" English. So, at least devs have mysterious computer languages that have strings of numbers that most of us look at and immediately get a migrain from attempting to comprehend what it means. keep up the good work and the craft of building things one keystroke at a time.
  • ramraj07 4mo ago
    The comparison is not valid. When writing let's say a novel, you cant just tell some random dude "write chapter 4" - you cant outsource it to a human so it only makes neither can you outsource it to ai. Software engineering is not that. You absolutely can and often will hand ofoff work to humans. Its not inherently that creative in the actual coding part.
• DrTung 4mo ago
  If you're an old geezer like me, doesn't this "AI revolution" remind you of the "BASIC revolution" in the 70s and 80s, i.e. when the BASIC language was new and hot. BASIC at that time was heralded as a much simpler and faster way to program. Rings a bell?
• rtgfhyuj 4mo ago
  junior engineer vibes
• ojr 4mo ago
  I was able to release two new iOS apps including a game, and a cross desktop application just this year. I refuse to go back to writing code by hand. If it doesn't help your productivity that's okay, ignoring how productive it has made developers like myself is a choice. AI was also able to help me create my first subscription payment workflow. It is like farming without Roundup, less crops, more energy, less toxic chemical risks.
• ApexDigital26 4mo ago
  [flagged]
• vetler 4mo ago
  The wide range of different responses to this post illustrates an important point; we can't agree on how to use LLMs in software development, and are still discovering new things. And in a couple of months we might be doing things completely differently because of some new model or new framework. That's really cool.
• guywithahat 4mo ago
  I think he's right, and everyone is reading into the title too much. He's not replacing all coding with hand-written, artisan code, he's just doing the architecture himself, which is the same conclusion I've come to. AI will sometimes put everything in one file or one struct and that's obviously not what we want, we need to tell it to be more modular or do it ourselves. I think it's fun to write code by myself, but if you're not using AI at work you're wasting your managers time.
• theuniverseson 4mo ago
  [flagged]
• worik 4mo ago
  LLMs are a tool. They must be wielded. Looking at the code, paying attention to the structure is part of the skill The skills required to wield an an LLM are not exactly those required to write code, but are very close. "Vibecoding" is not a way for idiots to blindly produce software artifacts that anyone would want
• czhu12 4mo ago
  I found the exact same when I started vibe coding new features in https://github.com/CanineHQ/canine https://github.com/CanineHQ/canine Claude is super good as making it seem like it’s an expert in kubernetes, but then undercovering certain decisions, it’s basically optimizing to try to make things look like they work. An example is, i wanted to develop a feature to easily fork a managed Postgres database with a k8s cluster. The thing it did was to copy the entirety of the source db to localhost, then copy it back out to the cluster, rather than just running the job within the cluster. Now I’m pretty stressed after a 1 hour vibe coding session, having to now review and digest and think through the code that it wrote. Implementations like that scare me — if I accidentally missed it and merged it — since there are real people who rely on canine. I wouldn’t go as far as to say I’m writing everything by hand, but I now always map out how I would do something before asking ai to approach it
• g42gregory 4mo ago
  I am loving the articles alternating between "software engineering is dead" and "I am going back to coding by hand". I guess we have a difference of opinions here. :-)
• dusted 4mo ago
  The generated code is fine, if it's a self-contained class of average size.. or below. But even with immense architecture, and constant supervision, it does not take long before it degenerates into "focused fixes", shortcuts, laziness and just outright cheating or lying.. So far, no amount of prompting has lead me beyond this.. It's paradoxical, how the model seems to reason about the correctness (or wrongness) of a proposed architecture and design, can write a plan that seems to take this into account, answer correctly to questions about the plan (even the ones meant to uncover the nuances that may be unclear), ask tons of clarifying questions and update both plan and spec docs correctly, and yet continue to act like a "ticket closer" who immediately puts on the biggest possible blinkers (horse blinkers) and deeply ignores all of it when building that same plan, referencing those same documents... Attempting anything comprehensive with AI is the software development analogue to the Gell-Mann Amnesia effect.. I'm definitely thinking deeply now about how I'm approaching these tools going forward.. Yes, GPT5 is better at spitting out a fairly acceptable skeleton to a class when prompted hard enough, than I am, in one go.. but.. It will happily do things like write decent looking protobuf schemas and then go ahead and hide everything that takes the least amount of reasoning behind some binary blob nested deep enough that it'll get past even the most dedicated reviewer.. It's fairly good at a lot of the things that I don't find interesting to deal with, but it's also amazingly incompetent when it comes to even the most mundane kind of common sense.. It's so strongly steering towards text-book examples that it will happily put in three times the amount of code and handle multiple classes of actually impossible edge-cases and even use-cases that it was specifically asked NOT to add.. And it will defend it by "well, I added this because I can't know if someone is going to use the thing I just added.. well, if you hadn't added it, chances are indeed slimmer.. It's so good at answering questions and explaining what's there, and diving through call-paths, and yet, it drops the ball the moment it's going to actually do something beyond saving me from looking up how write some really annoying and uninteresting boilerplate.. The worst thing is how good it is at making things LOOK right, it will cover every single edge-case you throw at it, but not because of the design, not because it correctly argues why the architecture is inherently allowing such and such, or because the design and spec fleshes out that A goes to B and never the other way around, and as soon as it's time to make something, it will make sure B can go to A, especially, it seems, if allowing so prevents it from doing the right thing which is WHY those edge-cases were trivial, instead it will endlessly hack around them.. I've worked people like that too, so I don't know if I am really blaming the models or the training data.. But damn it's a tough spot.. I've had multiple situations where, after wasting hours of work, which I should have just spend doing it myself, the only thing I really wished was for the model to be sentient, and able to feel pain, and have a corporal body so I could drag it outside and beat it to a pulp. (I've never reached that level of frustration with an actual person, so that's something new they bring to the table..)
• secprove 4mo ago
  It was certainly a lot more enjoyable.
• gauthamkolluru 4mo ago
  I’ve been resonating with the similar ideas the author of the article/original poster has been mentioning even in the comments below. Even i think that after few iterations of producing the code there must/should be change in the strategy. I sometimes also wonder if i should add the software engineering text books that ` tried teaching us to code` but contained the frameworks that are better applied along with the principles like SOLID, DRY etc. But then again, I do not have the right answer now. Maybe the reformation must come in the models too but as I see it, going back to hand coding is not the solution. Just like we came up with different paradigms of coding, the different principles of coding, different frameworks in short, we need to and will come up with some frameworks (& maybe some newer models as mentioned above) that can and will make us call AI coding “The Standard”. What are off the table (I think) 1. Hand coding out maybe even reading AI’s code line by line. That’d rather be counterproductive. At least with me it takes more time to read its code and understand. But i evaluate its code not just be writing tests but by other means too depending on the situation and that’s for another time too. 2. Vibe coding 3. Thinking software engineering is automated (it definitely is more essential than ever) 4. So does software development - even that’s not going to go extinct 5. Software jobs are going to go extinct. (In fact if a company is losing people claiming it doesn’t need so many of em means to me that either they do not see much of future for themselves or they’re just playing the stock price and investor satisfaction game for the short run - but that’s for a different topic)
  • gauthamkolluru 4mo ago
    Apologies for the visual formatting as i was posting this comment from my mobile. Thanks in advance for understanding.
• mcflysj 4mo ago
  [flagged]
• classified 4mo ago
  The most amusing thing about this is that the author seems surprised about what happened.
• johnthescott 4mo ago
  write code like your life depends on it. cause it does if you are any good.
• miraculixx 4mo ago
  welcome to the club :) I came to the same conclusion a year ago and uninstalled all the AI assistants that my IDE tried to force on me. Back to good old auto complete and it works great. Feeling productive and on top of things.
• deleted 4mo ago
  [deleted]
• ojsyrhf 4mo ago
  [dead]
• deleted 4mo ago
  [deleted]
• autorun 4mo ago
  This is similar to what happened with smartphones and the people going back to cellphones without touchscreen. AI coding hurts your ego. People keep forgetting this is just a tool that accelerate what you want to do. If you leave decisions to the AI you'll be probably disappointed or surprised.
  • jplusequalt 4mo ago
    >This is similar to what happened with smartphones and the people going back to cellphones without touchscreen. Agreed. Both technologies create unhealthy dependencies that many people would prefer to cut out. >AI coding hurts your ego. People keep forgetting this is just a tool that accelerate what you want to do. Are drummers propping up their egos for not using drum machines? There's a class of developer who genuinely enjoys the act of programming.