10 ms·

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

by pron 6mo 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 6mo 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 6mo ago
  Don't outsource either then
  - 21asdffdsa12 6mo ago
    How about we outsource it to pakistan and they use LLMs. That way, we do what the LLM people do - many agents and stacked on top
  - bigstrat2003 6mo ago
    I mean, a lot of companies learned that lesson the hard way. It turns out that skilled workers cost money in India just like in the US, so if you pay bottom of the barrel rates you get crappy talent. So many companies wound up winding back their outsourcing initiatives when they produced subpar results. I predict that exactly the same thing will happen with the AI craze.
- pron 6mo ago
  Not quite, because the architecture often needs to evolve when you learn more as the project evolves. People will complain when they feel the constraints drive them to unnatural workarounds, the agents don't. You can try telling the agent to stop and ask when a constraint proves problematic, except it doesn't have as good a judgment as humans to know when that's the case. I often find myself saying, "why did you write that insane code instead of raising the alarm about a problem?" and the answer is always, "you're absolutely right; I continued when I should have stopped." Of course, you can only tell when that happens if you carefully review the code.
  - senordevnyc 6mo ago
    So I run a solo saas that supports my family, and so the stakes feel very high for me. I use AI heavily, and I’ve seen the exact problem you’re describing. I feel like I’m often really riding the edge in terms of trying to use AI to accelerate product development while not letting tech debt accumulate too fast, or let my mental model of the codebase slip too much. Here’s what’s working for me right now: 1. The basics: use best model available, have skills and rules that specify project guidelines, etc. 2. Always use plan mode. It works much better to iterate on the concept of what we’re going to do, then do the implementation. The models will adhere to the plan at very high rates in my experience. 3. Don’t give chunks of work that are too large in scope. This is just art, and I’m constantly experimenting with how ambitious I can be. 4. I review all code to some extent, but I have a strong mental model of what areas of the app are more critical, where hidden bugs might accumulate, etc, and I review both tests and impl more strenuously in those areas. Whereas like a widget for my admin panel probably gets a 2 second glance. 5. Have the discipline to go through periodically and clean up tech debt, refactor things that you’d do differently now, etc. I find the AI a huge help here, because I can clean up cruft in an hour that would have once taken me days, and thus probably wouldn’t have gotten done. 6. I’m experimenting with shifting my architecture to make it easier to review AI code, make it less likely it’ll make mistakes, etc. Honestly mostly things I should have always been doing, but the level of formalism and abstraction on my solo projects is usually different than on a bigger team. To each their own, but I’ve grown this from nothing to about $350k in ARR over the last ten months, and I’m very confident I never could have built this product without AI help in triple that time.
- marcosdumay 6mo ago
  It's approximately the same problems, but stretched to an insane extent that you can never expect before it arrives.
benguild 6mo ago
“The only people I've heard saying that generated code is fine are those who don't read it.” Are you sure these people aren’t busy working rather than chatting? (haha) But in all seriousness it depends on what you’re doing with it. Writing a quick tool using an LLM is much easier than context changing to write it yourself. If you need the tool, that’s very valuable.
- sevenzero 6mo ago
  Also as a webdev, it writes basic CRUD pretty good. I am tired of having to build forms myself and the LLMs are usually really good at that. Been building a new app with lots of policies and whatnot and instructing a LLM is just much faster than doing the same repetitive shit over and over myself.
  - spockz 6mo ago
    If you were tired of writing forms yourself, had you looked at https://jsonforms.io/ https://jsonforms.io/? Just specify the the data you need, or extract it from the api spec and go. Display the form uniformly every time across your site. No need to burn AI time.
    - sevenzero 6mo ago
      I typically avoid any most abstractions or third party dependencies. Yea it could be neat, but I still need a lot of custom logic here and there. Same reason I avoid stuff like GraphQL. A little update: upon viewing the page on phone, for me the "comitter" field in the demo is going out of bounds... Really not speaking for their product.
      - topaz0 6mo ago
        Sounds like you're just fine depending on an extremely imprecise abstraction (natural language) and an extremely opaque third party (anthropic).
        6mo ago
Zach_the_Lizard 6mo ago
I agree with this. I've been writing a new internal framework at work and migrating consumers of the old framework to the new one. I had strong principles at the outset of the project and migrated a few consumers by hand, which gave me confidence that it would work. The overall migration is large and expensive enough that it has been deferred for nearly a decade. Bringing down the cost of that migration made me turn to AI to accelerate it. I found that it was OK at the more mechanical and straightforward cases, which are 80% of the use cases, to be fair. The remaining 20% need changes to the framework. Most of them need very small changes, such as an extra field in an API, but one or two require a partial conceptual redesign. To over simplify the problem, the backend for one system can generate certain data in 99% of cases. In a few critical cases, it logically cannot, and that data must be reported to it. Some important optimizations were made with the assumption that this would be impossible. The AI tooling didn't (yet) detect this scenario and happily added migration logic assuming it would work properly. Now, because of how this is being rolled out, this wasn't a production bug or anything (yet). However, asking the right questions to partner teams revealed it and unearthed that some others were going to need it as well. Ultimately, it isn't a big problem to solve in a way that will mostly satisfy everyone, but it would have been a big problem without a human deeper in the weeds. Over time, this may change. Validation tooling I built may make a future migration of this kind easier to vibe code even if AI functionality doesn't continue to improve. Smarter models with more context will eventually learn these problems in more and more cases. The code it generates still oscilates between beautiful and broken (or both!) so for now my artistic sensibilities make me keep a close eye on it. I think of the depressed robot from the Hitchhiker's Guide to the Galaxy as the intelligence behind it. Maybe one day it'll be trustworthy
stingraycharles 6mo ago
> 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. Yeah I’m currently working for several months already on a harness that wraps Claude Code and Codex etc to ensure that these types of invariants are captured and enforced (after the first few harness attempts failed), and - while it’s possible - slows down the workflow significantly and burns a lot more tokens. In addition to requiring more human involvement, of course. I suspect this is the right direction, though, as the alternatives inevitably lead any software project to delve into a spaghetti mess maintenance nightmare.
- pron 6mo ago
  It's not enough to enforce the invariants because they may need to change. You need to follow the invariants when they're right, and go back and reconsider them when they prove unhelpful. Knowing which is the case requires judgment that today's models are simply incapable of (not consistently, at least).
  - stingraycharles 6mo ago
    Yeah that's what I mean with "more human involvement", so the approach is to put the human in the loop in these moments, and the LLM knowing when it should do this.
jstummbillig 6mo ago
> The only people I've heard saying that generated code is fine are those who don't read it. Well, that is problematic. I have to either assume you are disinterested or lying and neither is great for any discourse.
- nathanielks 6mo ago
  Yeah, their statement just isn't true. With enough instruction, I've been able to get great output from models. I think that's the key: with detailed, pointed instructions, the output will match.
  - rimliu 6mo ago
    how do you know it matches? You did read it then?
    - nathanielks 6mo ago
      Indeed, I'm not using LLM output without thorough review. After reading a bunch of other comments, it sounds like people are referring to letting agents go wild and code whatever off a limited prompt. I'm not using LLMs like that; I'm generally interacting only via conversations with pretty detailed initial prompts. My interactions with the chat after that are corrections/guiding prompts to keep it on point and edit the prompt output from time to time.
      - hunterpayne 6mo ago
        Which defeats the purpose of using a LLM in the first place. Same as writing by hand but with a bill for tokens.
        senordevnyc 6mo ago
        This is a fun new position to move the goalposts too, I suppose, but it doesn’t make much sense to me. If I can use AI to plan, implement, test, document, refine, release, and maintain a feature, with review, in 20% of the time it would take me without AI, how exactly does it “defeat the purpose” of using an LLM? My purpose for using the LLM is to solve problems faster, and it does that. What’s yours?
perarneng 6mo ago
If you know how to write good code you can force AI to write good code with various techniques. It's 100% doable. You just need to figure out the problems AI has and find solutions to make it easier for it. Ex: extremely small contexts Modularize to modules with clear boundaries and only allow the AI to work within those boundaries. Make modules pure from IO so they are easily testable. Hide modules behind interfaces etc .. You can write 100 tests that executes within a second. You can write benchmarks etc .. AI needs boundaries and small contexts to work well. If you fail to give it that it will perform poorly. You are in charge.
- IdiotSavage 6mo ago
  So, basically you need to micro-manage it. Where are your 10x gains now? And is it fun to work like that?
  - hansmayer 6mo ago
    Amen. Instead of freeing you up - AI enslaves you - and if it was even enslaving to a superior being at least!
  - forgotaccount3 6mo ago
    > you need to micro-manage it. It is significantly easier to micro-manage an AI than a suite of junior developers. The AI doesn't replace a principal engineer, it's replacing junior and weaker senior developers who need stories broken down extremely concisely to be able to get anything done. The time it takes to break down a story such that a junior through weak senior developers can pick it up and execute it well would have the AI already done with testing built around it.
    - gylterud 6mo ago
      Juniors learn. Some juniors are potential good seniors. Over time they will internalise good architecture and be able to make good judgments on their own. Micromanaging LLMs is like having Dory from Finding Nemo as your colleague. You find ways to communicate, but there is no learning going on.
__alexs 6mo ago
I read all the code I generate with Cursor and some of it smells a bit weird but is easily fixable and most of it is as good as what I would write or better.
- RALaBarge 6mo ago
  And it is only the beginning.
- mattw1 6mo ago
  I read a bunch of Claude-Code-generated code last week and I was pretty impressed. It followed the established service class paradigm almost as exactly as we'd originally intended. The code was mostly very clean and had copious comments. A big step up from 2025 code. For the record, I definitely don't immediately read the majority of code Claude writes these days. I just check on it periodicially. In terms of code quality it's as good as any human I know of. Can be a bumbler at times. So can people.
daishi55 6mo ago
The generated code is more than fine, it’s good in many cases. And I read it :) Indeed for the task of “jump into an unfamiliar codebase and make a requested change that aligns with existing styles and patterns, and uses existing functionality” I would say something like opus 4.7 exceeds the capabilities of most developers.
- pron 6mo ago
  I agree with both statements, but that doesn't change the problem I stated. If an agent produces reasonable code 80-90% of the time, and 10-20% of the time it makes mistakes that could render the codebase irretrievably unevolvable once they accumulate, the only thing you can do is to carefully review the agent's output 100% of the time. That it gets things right 80% of the time as opposed to 40% of the time doesn't change this calculus one iota. But agents generate code much faster, and to know slow them down, some people want to not do the only thing that can currently ensure you get good results, which is to carefully review the output. Once that happens, there is simply no way for them to know how good or bad what they're getting is.
  - Kiro 6mo ago
    And humans produce 100% reasonable code or what? The kind of mess me and everyone I've worked with produces by hand is the inverse of that. Constant shortcuts and lazy slop through and through. Never worked anywhere where the code wasn't an entangled disarray. As soon as requirements change the abstractions fall apart and everything gets shoehorned.
    - bluefirebrand 6mo ago
      > And humans produce 100% reasonable code or what? Humans can be held accountable for their own slop > The kind of mess me and everyone I've worked with produces by hand is the inverse of that Yes, it's frustrating to work with isn't it? So why are you so excited to make higher volumes of this low quality slop using AI?
      - 6mo ago
agentultra 6mo ago
The invariant, stated informally, would be hard to prove is broken by a human reviewer in the loop. Spoken language isn’t precise enough for the task. Even if you could state it in a precise formal language the LLM under the agent doesn’t have the capability to understand what the invariant is for and why it’s important. You’ll still get oddly generated code. You might get an LLM that can associate certain tokens with those in the formal language specification which can hold invariants and perhaps even write the proofs… but you’ll still get a whole bunch of other code generated from the informal parts of the prompt. I agree that simply adding constraints and prompts to you skills and specs isn’t going to prevent these things. Worse, that even if you could invent a better mouse trap the creature will still escape. The problem is… “elongation:” the addition of code for the sake of the prompt/task/etc. Often less is better. This takes a human with the ability to anticipate what other humans would want/expect. When you need a generator, they’re great but it’s a firehouse that whose use should be restrained a little more.
- pron 6mo ago
  > The invariant, stated informally, would be hard to prove is broken by a human reviewer in the loop. Spoken language isn’t precise enough for the task. That depends on the invariant. Some are behavioural, like "variable x must be even if y is positive", but some are architectural, such as "a new view requires a new class". But that's only one side of the problem because maintaining the invariant can be just as bad as breaking it. You ask the agent to add a feature and it may well maintain the invariant - only it shouldn't have, because the feature uncovers the fact that the invariant is architecturally wrong. The problem is that evolving software requires exercising judgment about when you need to follow the existing strategy and when you need to rethink it. If there is any mechanical rule that could state what the right judgment is, I don't know what it is.
  - agentultra 6mo ago
    Yes! I was trying to make this part of my point but you definitely made it much more clear and concise. With a skilled operator, it could be possible to drive an agent to handle these kinds of changes. I would be concerned that spoken language wouldn't be precise enough to handle the refactoring and changes necessary to make to a code base when an invariant changes... regardless of whether it was a property, architectural, or procedural change. It already can take several prompts and burn quite a few tokens doing large-scale rewrites and code changes. Maybe the parameters and weights can be tuned for this kind of work but I remain skeptical that what we have at present is "efficient" at this kind of work.
linuxftw 6mo ago
Try plan mode. The problems you're speaking about are already solved.
- hatefulmoron 6mo ago
  Plan mode improves results, but it doesn't solve the underlying problems. Pretty often Claude Opus 4.7 on xhigh will formulate a reasonable enough plan, churn for a while, then come back with a summary that it didn't stick to the plan because it wasn't accurate. Worse, the disclaimer is buried under a bunch of "did X, did Y on line Z of file a/b/c", as if it's just a minor inconvenience. To the extent the plan was inaccurate, you're left in an undefined state where you might as well undo what it just did..
  - linuxftw 6mo ago
    You have to review the plan and fill in any missing gaps or correct anything that's wrong. Plan mode often isn't one shot, it might take a few iterations, but once the plan is nailed down, the results are usually very good.
    - deleted 6mo ago
      [deleted]
    - hatefulmoron 6mo ago
      You're right. I think having it spawn lots of subagents, read everything, formulate a big and detailed plan, only for it to be subtly wrong while requiring me to carefully review the result and the intermediate plans that produced it is quite tiring. I suppose things slip through.
      - linuxftw 6mo ago
        If you understand these subtle pieces you perceive the AI to get wrong, you should include that in your prompt. Also, unit test and functional test coverage go a long way to ensure correct behavior.
leonaves 6mo ago
What's the difference between asking an AI to write you a module you never read and installing a 3rd-party module without auditing all its source code?
- skydhash 6mo ago
  Trust and reputation. I would use Stripe, curl, and ffmpeg without audits, because I trust them to provide good code and to respect their API. I wouldn’t trust AI to write a Fibonacci series implementation. The AI has no reputation to wager for my trust.
- frikk 6mo ago
  stars on github? I've wondered the same thing.
- Xirdus 6mo ago
  If the 3rd party module is popular, its badness will affect other people too and either the module will get improved or well known workarounds/"best practices" will develop. With AI-generated code, more often than not you're the sole user.
bicepjai 6mo ago
This is the rule I have settled on and I can feel why. Writing the first buggy working version with agents is always fun. Then making the software reliable with the agents, the way you want is very painful.
indoordin0saur 6mo ago
Write your code by hand, but AI still serves as something of a stack overflow and code completion tool. Also good for writing tedious things like regex or little one-off utility scripts as well as a first crack at unit tests. Using it to actually write big blocks of important code is a no-no in my opinion as it produces what I would characterize as slop, even if it technically works.
- abalashov 6mo ago
  This is exactly my conclusion, to the letter.
zephen 6mo ago
> What I've seen is that if you define the architectural constraints, the agent writes complex, unmaintainable code... To be fair, there are many people like this as well. One of my personal favorite examples was way back in the 80s when I inherited the code for a protocol converter that let ASCII terminals communicate with IBM mainframes via the 3270 protocol. One of the pieces of code in there, for managing indicator lights, was simply wrong. It was ca. 150 lines of Z80 assembly language that was trying to faithfully follow the copious IBM documentation of how things worked, but it had subtle issues and didn't always work. My approach was to accept the documentation as accurate (the IBM documentation was always verbose and almost never wrong), but to reason that the original 3270 had these functions implemented in TTL logic gates, and there was no way in heck that they were wasting enough gates on indicator lights to require the logical equivalent of 150 instructions. So in my mind, it had to be a really simple circuit that had emergent properties that required the reams of documentation. With that mindset, I was able to craft correct code for this in 12 instructions. Many systems are likewise fractal in nature. You want to figure out the generating equations, rather than all the rules that derive from those. And, in many cases, writing down the generating equations is at least as easy to do in code as it would be to do in English for someone or something else to implement.
tcgv 6mo ago
> "Yep. The only people I've heard saying that generated code is fine are those who don't read it." I review every line of code I generate with AI. I mainly use an MR-based approach: 1) Provide a tightly scoped technical spec to Codex as a task, and ask for 3x solutions. Usually at least one of them is on the right track, and it is better to ditch a solution that went in the wrong direction than to try to fix it. 2) Review the explanation and diff of the proposed changes line by line, file by file. If I find minor deviations from what I asked, or violations of the codebase architecture/conventions, I write comments in the diff and/or global comments, and ask again for 3x adjusted solutions. 3) Usually, by this point, the solution is ready for me to merge locally and either run local tests or do some manual fine-tuning. 4) Finally, I generate unit tests. I leave them to this stage because I can repeat the same process with the sole intent of generating case-specific unit tests. This way, I can generate/review tests against the final version of the implementation. This has been working very well for me since our repos are reasonably organized and have a well-defined architecture. In the technical spec, I include the major architectural requirements and code conventions, and I also add a catch-all like "follow the codebase's existing conventions and style", which works reasonably well. This simple process has enabled me to deliver most minor/medium tasks and bug fixes really quickly while maintaining control over the changes and without lowering the quality bar. For larger and more challenging tasks, I find myself "driving the wheel" (i.e. coding by hand) more often, and using AI code generation in a much more scoped and specific way. So that becomes a different process altogether.
- senordevnyc 6mo ago
  Hilarious to see the insecure AI doomers downvote personal experience comments like this because they don’t fit with their “AI is useless garbage” takes. I used to respect engineers as a class, because I thought we were more rational. Turns out we’re just as likely to be driven by fear and insecurity as anyone else.
- rs999gti 5mo ago
  > Provide a tightly scoped technical spec to Codex as a task, and ask for 3x solutions. I'm using a personal license and Codex. What does this cost to generate 3x solutions as a starting point? Even in simple coding I have been doing, I notice Codex will burn through my Open AI subscription rather fast.
deleted 6mo ago
[deleted]
WalterBright 6mo ago
My own code is contortious. I refactor it regularly to reduce that, but it still can be better.
- glial 6mo ago
  I think this agrees with the parent's point. How do you know when to refactor?
  - WalterBright 6mo ago
    I've been coding for 50 years. When I write code, I think it is great work. About five years later, I realize it was crap. This is true of all the code I write. So, about five years later is the right time for refactoring. P.S. It takes about five years to forget what you thought you were doing with that code, and see the reality of what you wrote. https://www.imdb.com/title/tt0037671/ https://www.imdb.com/title/tt0037671/
eatsyourtacos 6mo ago
>Yep. The only people I've heard saying that generated code is fine are those who don't read it. If you already have a mature code base, then it's very easy to get AI to write excellent code. It has a ton of documentation on what you already do, how you do things, functions to use etc. I read all the changes AI does. I work in small chunks. >Even if you have an architecture in mind, and even if the agent follows it, sooner or later it will need to be reconsidered The agent can modify the structure you want to change to 100x faster than you can. That's the beauty of it. We all know how hard it is manually to make architectural changes once you've started to lock into something. These comments just show me you must not be using AI in the right way, or haven't used it enough to learn "how" to use it. I've been using claude code months now at full speed. You are simply wrong that it doesn't generate good code.
- xXSLAYERXx 6mo ago
  > I work in small chunks I'm surprised this still needs to be said. I'm convinced that posts like these are from people that let the LLM run wild. Small chunk PRs is the key whether its a human or an LLM
dkersten 6mo ago
> eventually, you'll want to add a feature that clashes with that invariant I find this to be a big problem with spec driven development: no spec survives the real world, some invariant that was in the spec will inevitably turn out to be wrong, no matter how much time you spend researching and designing the spec. When I as a human hit this during development, I can take a step back and think it through, and decide oh yes, the invariant is wrong and needs to be thought through again, and the impact of changing it needs to be assessed. Then I can design around it. Sometimes that means a substantial change in design, sometimes not, but in all times the resulting software is better for it: an unknown has been uncovered, something new has been learned. When this happens to AI, it keeps churning on it until it manages to hack a solution together, under the potentially wrong assumptions, design, or invariant. It doesn’t have the insight to step back and holistically reevaluate. At least, that’s been my experience working with AI. I think we can improve its ability to handle these situations, through good workflows and verification, but it’s not something that comes natural to AI and not something Claude code or whatever support out of the box and it’s got its limits.
smj-edison 6mo ago
And not only do you need to read the output of the code, but you need to write code, at least in my experience. I've had a quirky architecture pattern that I've been using for about 2 months now, and every time I use it I've felt slightly unsettled. I finally had a realization last night that it's not a good abstraction and how to divide it better. But, I don't feel that pain nearly as acutely when I have an LLM generate my code, so it's taken me longer to register that there is an issue, and also how to address it. Ancillary parts I don't mind generating, but for core features I still need to be actively writing most of the time.
doctorpangloss 6mo ago
Code that delivers everything that it asks for and more is fine! This has always been the case, it has always been, "If it looks good, it is good." You are an entrepreneur too, you know this in your heart of hearts. I'm sure you agree broadly with Gabe Newell, "people who don't know how to program who use AI to scaffold their programming abilities will become more effective developers of value than people who've been programming, y'know, for a decade." Look, he's talking about you and me. Programming for a while is quickly becoming worthless. It is of course the journey of programming that gives some people insight to real problems - business, creative, whatever - so it is extra important that the people with the best programming skills use the chatbots to write a lot of code that you and I will absolutely never read. And anyway, you, as consumer, are constantly using code you have never read. Lots of code is shipped that we never read. There is nothing special about reading code. Even if you and I learned everything by reading code, it doesn't mean that generated code isn't going to create value. It's going to generate tons and tons of value. Yet another POV is, if you are making code for customers who need to read the code, you are making a mistake, in the long term. It is a very, very interesting way to think about efforts around SBOM and various security companies - a far more informative lens to look at Wiz or Cloudflare, and what value they actually provide, because it's not code - and how relatively little enterprise value the "we read everything" teams at high frequency trading startups really deliver. You know this, you know exactly what I am talking about, it's your experience, so it is surprising to hear from you, talking in generalities against a trend that is obviously coming for all the best programmers.
luckydata 6mo ago
it's not a solved problem but it's not impossible to keep it at bay either. I created this tool for my own project and it does a pretty darn good job at keeping the AI accountable, I have a harness that runs this in a loop and helps refactor as we go like humans do anyways: https://github.com/CaliLuke/lagotto https://github.com/CaliLuke/lagotto
inf3cti0n95 6mo ago
Yea, happend to me as well, I left my agent to write code, it went down a rabbit hole of solving a typescipt error and ended up removing the package's type files to remove the error from source. lol! that's when I stopped.
marstall 5mo ago
yes it all comes back to iteration, the original "vibe coding". for me, programming has always been about making it up as i go along. like an artist starts with one stroke, i started when i was 10 years old typing '10 print "hello, world" 20 goto 10' and i've never really stopped programming that way 47 years later. For me programming is the same as refactoring, they both happen in a continuous Zone throughout the day. The idea of spending this big period at the beginning Defining the Architecture then letting AI fill in the blanks makes no sense because I only know what the architecture is, what the product is, as part of a process of typing all day for days and weeks and months, that never ends.
deleted 5mo ago
[deleted]

by pron 6mo ago

21asdffdsa12 6mo 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 6mo ago
Don't outsource either then
- 21asdffdsa12 6mo ago
  How about we outsource it to pakistan and they use LLMs. That way, we do what the LLM people do - many agents and stacked on top
- bigstrat2003 6mo ago
  I mean, a lot of companies learned that lesson the hard way. It turns out that skilled workers cost money in India just like in the US, so if you pay bottom of the barrel rates you get crappy talent. So many companies wound up winding back their outsourcing initiatives when they produced subpar results. I predict that exactly the same thing will happen with the AI craze.
pron 6mo ago
Not quite, because the architecture often needs to evolve when you learn more as the project evolves. People will complain when they feel the constraints drive them to unnatural workarounds, the agents don't. You can try telling the agent to stop and ask when a constraint proves problematic, except it doesn't have as good a judgment as humans to know when that's the case. I often find myself saying, "why did you write that insane code instead of raising the alarm about a problem?" and the answer is always, "you're absolutely right; I continued when I should have stopped." Of course, you can only tell when that happens if you carefully review the code.
- senordevnyc 6mo ago
  So I run a solo saas that supports my family, and so the stakes feel very high for me. I use AI heavily, and I’ve seen the exact problem you’re describing. I feel like I’m often really riding the edge in terms of trying to use AI to accelerate product development while not letting tech debt accumulate too fast, or let my mental model of the codebase slip too much. Here’s what’s working for me right now: 1. The basics: use best model available, have skills and rules that specify project guidelines, etc. 2. Always use plan mode. It works much better to iterate on the concept of what we’re going to do, then do the implementation. The models will adhere to the plan at very high rates in my experience. 3. Don’t give chunks of work that are too large in scope. This is just art, and I’m constantly experimenting with how ambitious I can be. 4. I review all code to some extent, but I have a strong mental model of what areas of the app are more critical, where hidden bugs might accumulate, etc, and I review both tests and impl more strenuously in those areas. Whereas like a widget for my admin panel probably gets a 2 second glance. 5. Have the discipline to go through periodically and clean up tech debt, refactor things that you’d do differently now, etc. I find the AI a huge help here, because I can clean up cruft in an hour that would have once taken me days, and thus probably wouldn’t have gotten done. 6. I’m experimenting with shifting my architecture to make it easier to review AI code, make it less likely it’ll make mistakes, etc. Honestly mostly things I should have always been doing, but the level of formalism and abstraction on my solo projects is usually different than on a bigger team. To each their own, but I’ve grown this from nothing to about $350k in ARR over the last ten months, and I’m very confident I never could have built this product without AI help in triple that time.
marcosdumay 6mo ago
It's approximately the same problems, but stretched to an insane extent that you can never expect before it arrives.

benguild 6mo ago

“The only people I've heard saying that generated code is fine are those who don't read it.” Are you sure these people aren’t busy working rather than chatting? (haha) But in all seriousness it depends on what you’re doing with it. Writing a quick tool using an LLM is much easier than context changing to write it yourself. If you need the tool, that’s very valuable.

sevenzero 6mo ago
Also as a webdev, it writes basic CRUD pretty good. I am tired of having to build forms myself and the LLMs are usually really good at that. Been building a new app with lots of policies and whatnot and instructing a LLM is just much faster than doing the same repetitive shit over and over myself.
- spockz 6mo ago
  If you were tired of writing forms yourself, had you looked at https://jsonforms.io/ https://jsonforms.io/? Just specify the the data you need, or extract it from the api spec and go. Display the form uniformly every time across your site. No need to burn AI time.
  - sevenzero 6mo ago
    I typically avoid any most abstractions or third party dependencies. Yea it could be neat, but I still need a lot of custom logic here and there. Same reason I avoid stuff like GraphQL. A little update: upon viewing the page on phone, for me the "comitter" field in the demo is going out of bounds... Really not speaking for their product.
    - topaz0 6mo ago
      Sounds like you're just fine depending on an extremely imprecise abstraction (natural language) and an extremely opaque third party (anthropic).
      - 6mo ago

Zach_the_Lizard 6mo ago

I agree with this. I've been writing a new internal framework at work and migrating consumers of the old framework to the new one. I had strong principles at the outset of the project and migrated a few consumers by hand, which gave me confidence that it would work. The overall migration is large and expensive enough that it has been deferred for nearly a decade. Bringing down the cost of that migration made me turn to AI to accelerate it. I found that it was OK at the more mechanical and straightforward cases, which are 80% of the use cases, to be fair. The remaining 20% need changes to the framework. Most of them need very small changes, such as an extra field in an API, but one or two require a partial conceptual redesign. To over simplify the problem, the backend for one system can generate certain data in 99% of cases. In a few critical cases, it logically cannot, and that data must be reported to it. Some important optimizations were made with the assumption that this would be impossible. The AI tooling didn't (yet) detect this scenario and happily added migration logic assuming it would work properly. Now, because of how this is being rolled out, this wasn't a production bug or anything (yet). However, asking the right questions to partner teams revealed it and unearthed that some others were going to need it as well. Ultimately, it isn't a big problem to solve in a way that will mostly satisfy everyone, but it would have been a big problem without a human deeper in the weeds. Over time, this may change. Validation tooling I built may make a future migration of this kind easier to vibe code even if AI functionality doesn't continue to improve. Smarter models with more context will eventually learn these problems in more and more cases. The code it generates still oscilates between beautiful and broken (or both!) so for now my artistic sensibilities make me keep a close eye on it. I think of the depressed robot from the Hitchhiker's Guide to the Galaxy as the intelligence behind it. Maybe one day it'll be trustworthy

stingraycharles 6mo ago

> 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. Yeah I’m currently working for several months already on a harness that wraps Claude Code and Codex etc to ensure that these types of invariants are captured and enforced (after the first few harness attempts failed), and - while it’s possible - slows down the workflow significantly and burns a lot more tokens. In addition to requiring more human involvement, of course. I suspect this is the right direction, though, as the alternatives inevitably lead any software project to delve into a spaghetti mess maintenance nightmare.

pron 6mo ago
It's not enough to enforce the invariants because they may need to change. You need to follow the invariants when they're right, and go back and reconsider them when they prove unhelpful. Knowing which is the case requires judgment that today's models are simply incapable of (not consistently, at least).
- stingraycharles 6mo ago
  Yeah that's what I mean with "more human involvement", so the approach is to put the human in the loop in these moments, and the LLM knowing when it should do this.

jstummbillig 6mo ago

> The only people I've heard saying that generated code is fine are those who don't read it. Well, that is problematic. I have to either assume you are disinterested or lying and neither is great for any discourse.

nathanielks 6mo ago
Yeah, their statement just isn't true. With enough instruction, I've been able to get great output from models. I think that's the key: with detailed, pointed instructions, the output will match.
- rimliu 6mo ago
  how do you know it matches? You did read it then?
  - nathanielks 6mo ago
    Indeed, I'm not using LLM output without thorough review. After reading a bunch of other comments, it sounds like people are referring to letting agents go wild and code whatever off a limited prompt. I'm not using LLMs like that; I'm generally interacting only via conversations with pretty detailed initial prompts. My interactions with the chat after that are corrections/guiding prompts to keep it on point and edit the prompt output from time to time.
    - hunterpayne 6mo ago
      Which defeats the purpose of using a LLM in the first place. Same as writing by hand but with a bill for tokens.
      - senordevnyc 6mo ago
        This is a fun new position to move the goalposts too, I suppose, but it doesn’t make much sense to me. If I can use AI to plan, implement, test, document, refine, release, and maintain a feature, with review, in 20% of the time it would take me without AI, how exactly does it “defeat the purpose” of using an LLM? My purpose for using the LLM is to solve problems faster, and it does that. What’s yours?

perarneng 6mo ago

If you know how to write good code you can force AI to write good code with various techniques. It's 100% doable. You just need to figure out the problems AI has and find solutions to make it easier for it. Ex: extremely small contexts Modularize to modules with clear boundaries and only allow the AI to work within those boundaries. Make modules pure from IO so they are easily testable. Hide modules behind interfaces etc .. You can write 100 tests that executes within a second. You can write benchmarks etc .. AI needs boundaries and small contexts to work well. If you fail to give it that it will perform poorly. You are in charge.

IdiotSavage 6mo ago
So, basically you need to micro-manage it. Where are your 10x gains now? And is it fun to work like that?
- hansmayer 6mo ago
  Amen. Instead of freeing you up - AI enslaves you - and if it was even enslaving to a superior being at least!
- forgotaccount3 6mo ago
  > you need to micro-manage it. It is significantly easier to micro-manage an AI than a suite of junior developers. The AI doesn't replace a principal engineer, it's replacing junior and weaker senior developers who need stories broken down extremely concisely to be able to get anything done. The time it takes to break down a story such that a junior through weak senior developers can pick it up and execute it well would have the AI already done with testing built around it.
  - gylterud 6mo ago
    Juniors learn. Some juniors are potential good seniors. Over time they will internalise good architecture and be able to make good judgments on their own. Micromanaging LLMs is like having Dory from Finding Nemo as your colleague. You find ways to communicate, but there is no learning going on.

__alexs 6mo ago

I read all the code I generate with Cursor and some of it smells a bit weird but is easily fixable and most of it is as good as what I would write or better.

RALaBarge 6mo ago
And it is only the beginning.
mattw1 6mo ago
I read a bunch of Claude-Code-generated code last week and I was pretty impressed. It followed the established service class paradigm almost as exactly as we'd originally intended. The code was mostly very clean and had copious comments. A big step up from 2025 code. For the record, I definitely don't immediately read the majority of code Claude writes these days. I just check on it periodicially. In terms of code quality it's as good as any human I know of. Can be a bumbler at times. So can people.

daishi55 6mo ago

The generated code is more than fine, it’s good in many cases. And I read it :) Indeed for the task of “jump into an unfamiliar codebase and make a requested change that aligns with existing styles and patterns, and uses existing functionality” I would say something like opus 4.7 exceeds the capabilities of most developers.

pron 6mo ago
I agree with both statements, but that doesn't change the problem I stated. If an agent produces reasonable code 80-90% of the time, and 10-20% of the time it makes mistakes that could render the codebase irretrievably unevolvable once they accumulate, the only thing you can do is to carefully review the agent's output 100% of the time. That it gets things right 80% of the time as opposed to 40% of the time doesn't change this calculus one iota. But agents generate code much faster, and to know slow them down, some people want to not do the only thing that can currently ensure you get good results, which is to carefully review the output. Once that happens, there is simply no way for them to know how good or bad what they're getting is.
- Kiro 6mo ago
  And humans produce 100% reasonable code or what? The kind of mess me and everyone I've worked with produces by hand is the inverse of that. Constant shortcuts and lazy slop through and through. Never worked anywhere where the code wasn't an entangled disarray. As soon as requirements change the abstractions fall apart and everything gets shoehorned.
  - bluefirebrand 6mo ago
    > And humans produce 100% reasonable code or what? Humans can be held accountable for their own slop > The kind of mess me and everyone I've worked with produces by hand is the inverse of that Yes, it's frustrating to work with isn't it? So why are you so excited to make higher volumes of this low quality slop using AI?
    - 6mo ago

agentultra 6mo ago

The invariant, stated informally, would be hard to prove is broken by a human reviewer in the loop. Spoken language isn’t precise enough for the task. Even if you could state it in a precise formal language the LLM under the agent doesn’t have the capability to understand what the invariant is for and why it’s important. You’ll still get oddly generated code. You might get an LLM that can associate certain tokens with those in the formal language specification which can hold invariants and perhaps even write the proofs… but you’ll still get a whole bunch of other code generated from the informal parts of the prompt. I agree that simply adding constraints and prompts to you skills and specs isn’t going to prevent these things. Worse, that even if you could invent a better mouse trap the creature will still escape. The problem is… “elongation:” the addition of code for the sake of the prompt/task/etc. Often less is better. This takes a human with the ability to anticipate what other humans would want/expect. When you need a generator, they’re great but it’s a firehouse that whose use should be restrained a little more.

pron 6mo ago
> The invariant, stated informally, would be hard to prove is broken by a human reviewer in the loop. Spoken language isn’t precise enough for the task. That depends on the invariant. Some are behavioural, like "variable x must be even if y is positive", but some are architectural, such as "a new view requires a new class". But that's only one side of the problem because maintaining the invariant can be just as bad as breaking it. You ask the agent to add a feature and it may well maintain the invariant - only it shouldn't have, because the feature uncovers the fact that the invariant is architecturally wrong. The problem is that evolving software requires exercising judgment about when you need to follow the existing strategy and when you need to rethink it. If there is any mechanical rule that could state what the right judgment is, I don't know what it is.
- agentultra 6mo ago
  Yes! I was trying to make this part of my point but you definitely made it much more clear and concise. With a skilled operator, it could be possible to drive an agent to handle these kinds of changes. I would be concerned that spoken language wouldn't be precise enough to handle the refactoring and changes necessary to make to a code base when an invariant changes... regardless of whether it was a property, architectural, or procedural change. It already can take several prompts and burn quite a few tokens doing large-scale rewrites and code changes. Maybe the parameters and weights can be tuned for this kind of work but I remain skeptical that what we have at present is "efficient" at this kind of work.

linuxftw 6mo ago

Try plan mode. The problems you're speaking about are already solved.

hatefulmoron 6mo ago
Plan mode improves results, but it doesn't solve the underlying problems. Pretty often Claude Opus 4.7 on xhigh will formulate a reasonable enough plan, churn for a while, then come back with a summary that it didn't stick to the plan because it wasn't accurate. Worse, the disclaimer is buried under a bunch of "did X, did Y on line Z of file a/b/c", as if it's just a minor inconvenience. To the extent the plan was inaccurate, you're left in an undefined state where you might as well undo what it just did..
- linuxftw 6mo ago
  You have to review the plan and fill in any missing gaps or correct anything that's wrong. Plan mode often isn't one shot, it might take a few iterations, but once the plan is nailed down, the results are usually very good.
  - deleted 6mo ago
    [deleted]
  - hatefulmoron 6mo ago
    You're right. I think having it spawn lots of subagents, read everything, formulate a big and detailed plan, only for it to be subtly wrong while requiring me to carefully review the result and the intermediate plans that produced it is quite tiring. I suppose things slip through.
    - linuxftw 6mo ago
      If you understand these subtle pieces you perceive the AI to get wrong, you should include that in your prompt. Also, unit test and functional test coverage go a long way to ensure correct behavior.

leonaves 6mo ago

What's the difference between asking an AI to write you a module you never read and installing a 3rd-party module without auditing all its source code?

skydhash 6mo ago
Trust and reputation. I would use Stripe, curl, and ffmpeg without audits, because I trust them to provide good code and to respect their API. I wouldn’t trust AI to write a Fibonacci series implementation. The AI has no reputation to wager for my trust.
frikk 6mo ago
stars on github? I've wondered the same thing.
Xirdus 6mo ago
If the 3rd party module is popular, its badness will affect other people too and either the module will get improved or well known workarounds/"best practices" will develop. With AI-generated code, more often than not you're the sole user.

bicepjai 6mo ago

This is the rule I have settled on and I can feel why. Writing the first buggy working version with agents is always fun. Then making the software reliable with the agents, the way you want is very painful.

indoordin0saur 6mo ago

Write your code by hand, but AI still serves as something of a stack overflow and code completion tool. Also good for writing tedious things like regex or little one-off utility scripts as well as a first crack at unit tests. Using it to actually write big blocks of important code is a no-no in my opinion as it produces what I would characterize as slop, even if it technically works.

abalashov 6mo ago
This is exactly my conclusion, to the letter.

zephen 6mo ago

> What I've seen is that if you define the architectural constraints, the agent writes complex, unmaintainable code... To be fair, there are many people like this as well. One of my personal favorite examples was way back in the 80s when I inherited the code for a protocol converter that let ASCII terminals communicate with IBM mainframes via the 3270 protocol. One of the pieces of code in there, for managing indicator lights, was simply wrong. It was ca. 150 lines of Z80 assembly language that was trying to faithfully follow the copious IBM documentation of how things worked, but it had subtle issues and didn't always work. My approach was to accept the documentation as accurate (the IBM documentation was always verbose and almost never wrong), but to reason that the original 3270 had these functions implemented in TTL logic gates, and there was no way in heck that they were wasting enough gates on indicator lights to require the logical equivalent of 150 instructions. So in my mind, it had to be a really simple circuit that had emergent properties that required the reams of documentation. With that mindset, I was able to craft correct code for this in 12 instructions. Many systems are likewise fractal in nature. You want to figure out the generating equations, rather than all the rules that derive from those. And, in many cases, writing down the generating equations is at least as easy to do in code as it would be to do in English for someone or something else to implement.

tcgv 6mo ago

> "Yep. The only people I've heard saying that generated code is fine are those who don't read it." I review every line of code I generate with AI. I mainly use an MR-based approach: 1) Provide a tightly scoped technical spec to Codex as a task, and ask for 3x solutions. Usually at least one of them is on the right track, and it is better to ditch a solution that went in the wrong direction than to try to fix it. 2) Review the explanation and diff of the proposed changes line by line, file by file. If I find minor deviations from what I asked, or violations of the codebase architecture/conventions, I write comments in the diff and/or global comments, and ask again for 3x adjusted solutions. 3) Usually, by this point, the solution is ready for me to merge locally and either run local tests or do some manual fine-tuning. 4) Finally, I generate unit tests. I leave them to this stage because I can repeat the same process with the sole intent of generating case-specific unit tests. This way, I can generate/review tests against the final version of the implementation. This has been working very well for me since our repos are reasonably organized and have a well-defined architecture. In the technical spec, I include the major architectural requirements and code conventions, and I also add a catch-all like "follow the codebase's existing conventions and style", which works reasonably well. This simple process has enabled me to deliver most minor/medium tasks and bug fixes really quickly while maintaining control over the changes and without lowering the quality bar. For larger and more challenging tasks, I find myself "driving the wheel" (i.e. coding by hand) more often, and using AI code generation in a much more scoped and specific way. So that becomes a different process altogether.

senordevnyc 6mo ago
Hilarious to see the insecure AI doomers downvote personal experience comments like this because they don’t fit with their “AI is useless garbage” takes. I used to respect engineers as a class, because I thought we were more rational. Turns out we’re just as likely to be driven by fear and insecurity as anyone else.
rs999gti 5mo ago
> Provide a tightly scoped technical spec to Codex as a task, and ask for 3x solutions. I'm using a personal license and Codex. What does this cost to generate 3x solutions as a starting point? Even in simple coding I have been doing, I notice Codex will burn through my Open AI subscription rather fast.

deleted 6mo ago

[deleted]

WalterBright 6mo ago

My own code is contortious. I refactor it regularly to reduce that, but it still can be better.

glial 6mo ago
I think this agrees with the parent's point. How do you know when to refactor?
- WalterBright 6mo ago
  I've been coding for 50 years. When I write code, I think it is great work. About five years later, I realize it was crap. This is true of all the code I write. So, about five years later is the right time for refactoring. P.S. It takes about five years to forget what you thought you were doing with that code, and see the reality of what you wrote. https://www.imdb.com/title/tt0037671/ https://www.imdb.com/title/tt0037671/

eatsyourtacos 6mo ago

>Yep. The only people I've heard saying that generated code is fine are those who don't read it. If you already have a mature code base, then it's very easy to get AI to write excellent code. It has a ton of documentation on what you already do, how you do things, functions to use etc. I read all the changes AI does. I work in small chunks. >Even if you have an architecture in mind, and even if the agent follows it, sooner or later it will need to be reconsidered The agent can modify the structure you want to change to 100x faster than you can. That's the beauty of it. We all know how hard it is manually to make architectural changes once you've started to lock into something. These comments just show me you must not be using AI in the right way, or haven't used it enough to learn "how" to use it. I've been using claude code months now at full speed. You are simply wrong that it doesn't generate good code.

xXSLAYERXx 6mo ago
> I work in small chunks I'm surprised this still needs to be said. I'm convinced that posts like these are from people that let the LLM run wild. Small chunk PRs is the key whether its a human or an LLM

dkersten 6mo ago

> eventually, you'll want to add a feature that clashes with that invariant I find this to be a big problem with spec driven development: no spec survives the real world, some invariant that was in the spec will inevitably turn out to be wrong, no matter how much time you spend researching and designing the spec. When I as a human hit this during development, I can take a step back and think it through, and decide oh yes, the invariant is wrong and needs to be thought through again, and the impact of changing it needs to be assessed. Then I can design around it. Sometimes that means a substantial change in design, sometimes not, but in all times the resulting software is better for it: an unknown has been uncovered, something new has been learned. When this happens to AI, it keeps churning on it until it manages to hack a solution together, under the potentially wrong assumptions, design, or invariant. It doesn’t have the insight to step back and holistically reevaluate. At least, that’s been my experience working with AI. I think we can improve its ability to handle these situations, through good workflows and verification, but it’s not something that comes natural to AI and not something Claude code or whatever support out of the box and it’s got its limits.

smj-edison 6mo ago

And not only do you need to read the output of the code, but you need to write code, at least in my experience. I've had a quirky architecture pattern that I've been using for about 2 months now, and every time I use it I've felt slightly unsettled. I finally had a realization last night that it's not a good abstraction and how to divide it better. But, I don't feel that pain nearly as acutely when I have an LLM generate my code, so it's taken me longer to register that there is an issue, and also how to address it. Ancillary parts I don't mind generating, but for core features I still need to be actively writing most of the time.

doctorpangloss 6mo ago

Code that delivers everything that it asks for and more is fine! This has always been the case, it has always been, "If it looks good, it is good." You are an entrepreneur too, you know this in your heart of hearts. I'm sure you agree broadly with Gabe Newell, "people who don't know how to program who use AI to scaffold their programming abilities will become more effective developers of value than people who've been programming, y'know, for a decade." Look, he's talking about you and me. Programming for a while is quickly becoming worthless. It is of course the journey of programming that gives some people insight to real problems - business, creative, whatever - so it is extra important that the people with the best programming skills use the chatbots to write a lot of code that you and I will absolutely never read. And anyway, you, as consumer, are constantly using code you have never read. Lots of code is shipped that we never read. There is nothing special about reading code. Even if you and I learned everything by reading code, it doesn't mean that generated code isn't going to create value. It's going to generate tons and tons of value. Yet another POV is, if you are making code for customers who need to read the code, you are making a mistake, in the long term. It is a very, very interesting way to think about efforts around SBOM and various security companies - a far more informative lens to look at Wiz or Cloudflare, and what value they actually provide, because it's not code - and how relatively little enterprise value the "we read everything" teams at high frequency trading startups really deliver. You know this, you know exactly what I am talking about, it's your experience, so it is surprising to hear from you, talking in generalities against a trend that is obviously coming for all the best programmers.

luckydata 6mo ago

it's not a solved problem but it's not impossible to keep it at bay either. I created this tool for my own project and it does a pretty darn good job at keeping the AI accountable, I have a harness that runs this in a loop and helps refactor as we go like humans do anyways: https://github.com/CaliLuke/lagotto https://github.com/CaliLuke/lagotto

inf3cti0n95 6mo ago

Yea, happend to me as well, I left my agent to write code, it went down a rabbit hole of solving a typescipt error and ended up removing the package's type files to remove the error from source. lol! that's when I stopped.

marstall 5mo ago

yes it all comes back to iteration, the original "vibe coding". for me, programming has always been about making it up as i go along. like an artist starts with one stroke, i started when i was 10 years old typing '10 print "hello, world" 20 goto 10' and i've never really stopped programming that way 47 years later. For me programming is the same as refactoring, they both happen in a continuous Zone throughout the day. The idea of spending this big period at the beginning Defining the Architecture then letting AI fill in the blanks makes no sense because I only know what the architecture is, what the product is, as part of a process of typing all day for days and weeks and months, that never ends.

deleted 5mo ago

[deleted]