5 ms·

I suspect if people saw the handwritten code of many, many, many products that they used every day they would be shocked. I've worked at BigCos and startups, an

by tombert 6mo ago

I suspect if people saw the handwritten code of many, many, many products that they used every day they would be shocked. I've worked at BigCos and startups, and a lot of the terrible code that makes it to production was shocking when I first started. This isn't a dig at anyone, I've certainly shipped my share of bad code as well. Deadlines, despite my wishes sometimes, continue to exist. Sometimes you have to ship a hack to make a customer or manager happy, and then replacing those hacks with better code just never happens. For that matter, the first draft of nearly anything I write is usually not great. I might just be stupid, but I doubt I'm unique; when I've written nice, beautiful, optimized code, it's usually a second or third draft, because ultimately I don't think I fully understand the problem and the assumptions I am allowed to make until I've finished the first draft. Usually for my personal projects, my first dozen or so commits will be pretty messy, and then I'll have cleanup branches that I merge to make the code less terrible. This isn't inherently bad, but a lot of the time I am simply not given time to do a second or third draft of the code, because, again, deadlines, so my initial "just get it working" draft is what ships into production. I don't love it, and I kind of dread of some of the code with my name attached to it at BigCo ever gets leaked, but that's just how it is in the corporate world sometimes.

cassianoleal 6mo ago
This is the product that's claiming "coding is a solved problem" though. I get a junior developer or a team of developers with varying levels of experience and a lot of pressure to deliver producing crummy code, but not the very tool that's supposed to be the state-of-the-art coder.
- tombert 6mo ago
  Sure, but as I stated, even "professional" code is pretty bad a lot of the time. If it's able to generate code that's as good as professional code, then maybe it is solved. I don't actually think it's a solved problem, I'm saying that the fact that it generates terrible code doesn't necessarily mean that it doesn't have parity with humans.
  - aswanson 6mo ago
    Hard to argue with that.
  - genxy 6mo ago
    You can get AI to generate the best code you have ever seen. It just takes time and direction. I can write "poetic" code, but it takes orders of magnitude more time. I can also write beautiful code with AI, but it is also time and brain intensive. It generates terrible code when used in a nearly open loop manner, which all coding agents are currently doing.
  - croes 6mo ago
    And look what damage comes from that human generated code. Now we get hyper mass production of the same quality.
- SpicyLemonZest 6mo ago
  The bet is that it will be trivial for them to invest in cleaning up Claude Code whenever they face real competitive pressure to do so. My best guess is that it's a bad bet - I don't think LLM agents have solved any of the fundamental problems that make it hard to convert janky bad code to polished good code. But Claude Code is capable in my experience of producing clean code when appropriately guided, so it's not that there's no choice but jank. They're intentionally underinvesting in code quality right now for the sake of iteration speed.
  - woeirua 6mo ago
    Have you tried just asking CC to make a codebase more elegant? It’s surprisingly effective up to a point. No reason to think that won’t work better down the road.
    - SpicyLemonZest 6mo ago
      Down the road AI is smarter than all of us. Today (including one time literally today), my experience is that it’s occasionally helpful at cleaning up its own mess but often tries to change behavior in a way that’s unacceptable for a production project.
      - andrekandre 6mo ago
        > often tries to change behavior yes, and (in my experience) at the same time re-write the unit tests that are supposed to guarantee behavior doesn't change...
        viktorianer 6mo ago
        [flagged]
- woeirua 6mo ago
  No one cares about code quality. No one has ever cared about code quality. It’s only been tolerated in businesses because no one could objectively say that ignoring code quality can result in high velocity. With coding agents, velocity is now extremely high if you get humans out of the way.
  - pydry 6mo ago
    It really shows that nobody cares about uptime at github or the jankiness of claude. I wouldnt say that customers are indifferent, but it wouldnt be the first time that investor expectations are prioritized far above customer satisfaction.
  - switchbak 6mo ago
    "No one cares about code quality" - disagree. As a dev, I care about code quality in that shitty code makes my life suck. As a user of terrible products, I only care about code quality in as much as the product is crap (Spotify I'm looking at you), or it takes forever for it to evolve/improve. Biz people don't care about quality, but they're notoriously short sighted. Whoever nerfed Google's search is angering millions of people as we speak.
    - anonymars 6mo ago
      > Whoever nerfed Google's search is angering millions of people as we speak This guy, supposedly: https://news.ycombinator.com/item?id=40133976 https://news.ycombinator.com/item?id=40133976
  - hiq 6mo ago
    Nobody cares about costs until they pay them themselves. Regarding code quality and tech debt, it's sensible not to care if it doesn't lead to anything observable. Do you really care of some "bad" code somewhere that hasn't changed for 5 years but keeps working fine, and has no new requirements? On the other hand, if you work on an active codebase where fixing one bug inevitably leads to another, maybe it's worth asking whether the code quality is simply too low to deliver on the product expectations. It's not even obvious to me in which direction coding agents move the needle. Do you want higher quality, at least at a higher (design) level, when you heavily use agents, so that you know know the mess will at least compartmentalized, and easier to deal with later if needed? Or do you just assume the agent will always do the work and you won't need to dig into the code yourself? So far I've mostly done the former, but I understand that for some projects, the latter can make sense.
- H8crilA 6mo ago
  > crummy code, but not the very tool that's supposed to be the state-of-the-art coder Why not? It is subject to the same pressures, in fact it is subject to more time pressure than most corp code out there. Also, it's the model that's doing the coding, not the frontend tool.
  - Eufrat 6mo ago
    I thought the sales pitch of all of this is that the AI was supposed to relieve people from having to do a bunch of annoying bootstrap coding and to do it in a way that we could extended easily. I have a subscription to Claude Code and despite my skepticism, it has been pretty good at just getting a goofy PoC thing going. When I look at the code, it’s usually insane unless the prompt was so narrow and specific like about writing a function that does one thing and only one thing. Outside of small, personal projects, I am still really uncomfortable at having agents run wild. I see the result, and then I spend a bunch of time having to gain the context of what is going on, especially if I ask it to implement features in spaces I have general knowledge, but not expertise. So, the problem remains the same. These things still need handholding by people who understand the domain, but having people become glorified PR reviewers is not an acceptable path forward. Arguing that there is lots of bad production code kinda avoids the actual issue that is going on here. Yes, a lot of sloppy code can and has been written by people. I’ve seen it myself, but it feels like the actual thing is that, we are now enabling that at scale and calling it “abundance” when instead we are really generating an abundance of completely avoidable security holes and logic errors.
    - drob518 6mo ago
      Exactly. I thought AI was going to be smarter. I thought AI would give us expert coders. Instead we have idiot savants.
      - cindyllm 6mo ago
        [dead]
  - cassianoleal 6mo ago
- progmetaldev 6mo ago
  I mean, hasn't it learned from reading other's code? I don't think it can be any better than the common patterns and practices that it has been trained on. Some outlier of amazing code is probably not going to make much of a difference, unless I am completely misunderstanding LLMs (which I very well may be, and would gladly take any criticism on my take here).
  - drob518 6mo ago
    Yes, but, that’s a low bar, no? I mean, when they first started talking about AI, were you envisioning a mediocre AI that is just average, or were you imagining an expert?
awesome_dude 6mo ago
> and then replacing those hacks with better code just never happens Yeah, we even have an idiom for this - "Temporary is always permanent"
- switchbak 6mo ago
  We'll fix it later. But as a great man once said: Later == Never.
- parineum 6mo ago
  "There's nothing more permanent than a temporary solution."
xienze 6mo ago
> I suspect if people saw the handwritten code of many, many, many products that they used every day they would be shocked. Absolutely. The difference is that the amount of bad code that could be generated had an upper limit on it — how fast a human can type it out. With LLMs bad code can be shat out at warp speed.
- tombert 6mo ago
  Oh I don't disagree with that. I am getting pretty tired of people making multi-thousand-line pull requests with lots of clearly AI-generated code and expecting it to be merged in. I think the better unit to commit and work with is the prompt itself, and I think that the prompt is the thing that should be PR'd at this point, because ultimately the spec is what's important.
  - xienze 6mo ago
    > I think that the prompt is the thing that should be PR'd at this point, because ultimately the spec is what's important. The fundamental problem there is the code generation step is non-deterministic. You might make a two sentence change to the prompt to fix a bug and the generation introduces two more. Generate again and everything is fine. Way too much uncertainty to have confidence in that approach.
    - tombert 6mo ago
      If you make the prompts specific enough and provide tests that it has to run before it passes, then it should be fairly close to deterministic. Also, people aren't actually reading through most of the code that is generated or merged, so if there's a fear of deploying buggy code generated by AI, then I assure you that's already happening. A lot.
      - ben-schaaf 6mo ago
        How is "fairly close to deterministic" anywhere near good enough? LLMS aren't anywhere near cheap enough to do this either. That said it's so trivial to do, why haven't you done that already?
whatisthiseven 6mo ago
> I suspect if people saw the handwritten code Somehow, everyone has forgotten the terrible code quality that existed prior to 2020. https://www.youtube.com/watch?v=UjZQGRATlwA https://www.youtube.com/watch?v=UjZQGRATlwA Like, come on. Software has been shit for decades. AI hasn't observably reduced the quality of software I use everyday in a way that is meaningfully separable from normal incidents in the past.
- 0xDEAFBEAD 6mo ago
  >AI hasn't observably reduced the quality of software I use everyday in a way that is meaningfully separable from normal incidents in the past. I have noticed a spike in web apps exhibiting random failures and glitchy behavior over the past few months.
- jfkddkdjdj 6mo ago
  [dead]
- thesz 6mo ago
  > AI hasn't observably reduced the quality of software I use everyday in a way that is meaningfully separable from normal incidents in the past. Most probably, you are not looking into that well enough. Average duration for AWS outages [2] was 1.5 hours per outage, 38 hours total. Most recent AWS outage in 2026 [1] downed AWS for 13 hours, a third of 38 hours spanning an year before, and was caused by AWS LLM coding tool. [1] https://www.theguardian.com/technology/2026/feb/20/amazon-cloud-outages-ai-tools-amazon-web-services-aws https://www.theguardian.com/technology/2026/feb/20/amazon-cl... [2] https://www.cherryservers.com/blog/cloud-outages https://www.cherryservers.com/blog/cloud-outages
benjiro3000 6mo ago
[dead]
progmetaldev 6mo ago
To me, it instead sounds like you care about the code you produce. You judge it more harshly than you probably do other code. It sounds like you are also meeting deadlines, so I'd call that a success and more production than what a lot of people tend to put out into the world. I often have a lot of time between projects, and am able to really think about things, and write the code that I'm happy with. Even when I do that, I do some more research, or work on another project, and immediately I'm picking apart sections of my code that I really took the time to "get right." Sometimes it can be worse if you are given vast amounts of time to build your solution, where some form of deadline may have pushed you to make decisions you were able to put off. At least that's my perspective on it, I feel like if you love writing software, you are going to keep improving nearly constantly, and look back at what you've done and be able to pick it apart. To keep myself from getting too distressed over looking at past code now, I tend to look at the overall architecture and success of the project (in regards to the performing what it was supposed to, not necessarily monetarily). If I see a piece of code that I feel could have been written far better, I look at how it fits into the rest. I tend to work on very small teams, so I'm often making architecture decisions that touch large areas of the code, so this may just be from my perspective of not working on a large team. I still do think if you care about your craft, you will be harsh on yourself, more than you deserve.
marcus_holmes 6mo ago
It's an unpopular truth for our industry, but the point of commercial software development is not to write good code; it's to write profitable code. There are some cases where the most profitable code is also good code. We like those. But in most (99%+) cases, the code is not going to survive contact with the market and so spending any time on making it good is wasted.
- arcticbull 6mo ago
  Yep this is especially true in the pre-product-market-fit phase. Most if not all of that code should be written to be thrown away. Any time you spend writing perfect code instead of your MVP is burnt runway and a chance for competitors to catch up. Once you show PMF though the balance changes to long-term sustainability and maintainability. What's going to be interesting is getting to a place where it generates better code than we would from specs. You can get better and better generated code by filling in the context the model infers. Do that long enough, and well, a perfect spec is just code. We do live in interesting times.
  - KellyCriterion 6mo ago
    > Any time you spend writing perfect code instead of your MVP is burnt runway This. Once we crashed a product/company becaues of "we want it to be engineered perfectly" :-X
- okr 6mo ago
  To my believe there was not a goal to write good code. The goal was maintainability and to keep it simple, so that people understand. People come and go, you constantly get to see foreign code and you have to do something with it. Anyways, i see the maintainability hell coming onto us. I still wonder how i organize this with AI. I definitly do not want to touch it what is written by AI.
  - drob518 6mo ago
    I think the industry-wide hope is that AI manages the AI-written code, but it’s unclear whether that’s actually going to work out in practice. Right now, my experience is that is dicey. I’ve had AI mess up a codebase to the point where I threw it away and restarted. Maybe I was doing it wrong, though, in that I was looking at the code and was increasingly horrified by the slop. I get the feeling that in this new world, we’re supposed to ignore how the sausage is made and just focus on the final outcome.
faangguyindia 6mo ago
i worked at companies in US where uptime monitoring was Page Refresh by QA team. where there was no centralized logs postgres had no backup or replication or anything
bombcar 6mo ago
This is not just true of code; it is true of everything - the whole world is held together with spit, bailing wire, a prayer, and some old dude who remembers.
- duskdozer 6mo ago
  It doesn't mean it's something to strive for
  - bombcar 6mo ago
    Totally agree; we've created a system that goes so far beyond technical debt we're going to have to call it technical usury, and we're piling it up at rapid rates. Given that most code gets thrown away, perhaps it won't matter much. Perhaps
Sohcahtoa82 6mo ago
> I suspect if people saw the handwritten code of many, many, many products that they used every day they would be shocked. At a place I worked at with their core product written in Python, it was exceptionally common for engineers to make shell calls for file operations that had easy Python-native functions. For example, rather than `os.remove("some_file")`, they'd do `os.system("rm some_file")`. Sometimes, the file name being acted on included user input. I found so many shell injections that could have easily been prevented.

by tombert 6mo ago

cassianoleal 6mo ago

This is the product that's claiming "coding is a solved problem" though. I get a junior developer or a team of developers with varying levels of experience and a lot of pressure to deliver producing crummy code, but not the very tool that's supposed to be the state-of-the-art coder.

tombert 6mo ago
Sure, but as I stated, even "professional" code is pretty bad a lot of the time. If it's able to generate code that's as good as professional code, then maybe it is solved. I don't actually think it's a solved problem, I'm saying that the fact that it generates terrible code doesn't necessarily mean that it doesn't have parity with humans.
- aswanson 6mo ago
  Hard to argue with that.
- genxy 6mo ago
  You can get AI to generate the best code you have ever seen. It just takes time and direction. I can write "poetic" code, but it takes orders of magnitude more time. I can also write beautiful code with AI, but it is also time and brain intensive. It generates terrible code when used in a nearly open loop manner, which all coding agents are currently doing.
- croes 6mo ago
  And look what damage comes from that human generated code. Now we get hyper mass production of the same quality.
SpicyLemonZest 6mo ago
The bet is that it will be trivial for them to invest in cleaning up Claude Code whenever they face real competitive pressure to do so. My best guess is that it's a bad bet - I don't think LLM agents have solved any of the fundamental problems that make it hard to convert janky bad code to polished good code. But Claude Code is capable in my experience of producing clean code when appropriately guided, so it's not that there's no choice but jank. They're intentionally underinvesting in code quality right now for the sake of iteration speed.
- woeirua 6mo ago
  Have you tried just asking CC to make a codebase more elegant? It’s surprisingly effective up to a point. No reason to think that won’t work better down the road.
  - SpicyLemonZest 6mo ago
    Down the road AI is smarter than all of us. Today (including one time literally today), my experience is that it’s occasionally helpful at cleaning up its own mess but often tries to change behavior in a way that’s unacceptable for a production project.
    - andrekandre 6mo ago
      > often tries to change behavior yes, and (in my experience) at the same time re-write the unit tests that are supposed to guarantee behavior doesn't change...
      - viktorianer 6mo ago
        [flagged]
woeirua 6mo ago
No one cares about code quality. No one has ever cared about code quality. It’s only been tolerated in businesses because no one could objectively say that ignoring code quality can result in high velocity. With coding agents, velocity is now extremely high if you get humans out of the way.
- pydry 6mo ago
  It really shows that nobody cares about uptime at github or the jankiness of claude. I wouldnt say that customers are indifferent, but it wouldnt be the first time that investor expectations are prioritized far above customer satisfaction.
- switchbak 6mo ago
  "No one cares about code quality" - disagree. As a dev, I care about code quality in that shitty code makes my life suck. As a user of terrible products, I only care about code quality in as much as the product is crap (Spotify I'm looking at you), or it takes forever for it to evolve/improve. Biz people don't care about quality, but they're notoriously short sighted. Whoever nerfed Google's search is angering millions of people as we speak.
  - anonymars 6mo ago
    > Whoever nerfed Google's search is angering millions of people as we speak This guy, supposedly: https://news.ycombinator.com/item?id=40133976 https://news.ycombinator.com/item?id=40133976
- hiq 6mo ago
  Nobody cares about costs until they pay them themselves. Regarding code quality and tech debt, it's sensible not to care if it doesn't lead to anything observable. Do you really care of some "bad" code somewhere that hasn't changed for 5 years but keeps working fine, and has no new requirements? On the other hand, if you work on an active codebase where fixing one bug inevitably leads to another, maybe it's worth asking whether the code quality is simply too low to deliver on the product expectations. It's not even obvious to me in which direction coding agents move the needle. Do you want higher quality, at least at a higher (design) level, when you heavily use agents, so that you know know the mess will at least compartmentalized, and easier to deal with later if needed? Or do you just assume the agent will always do the work and you won't need to dig into the code yourself? So far I've mostly done the former, but I understand that for some projects, the latter can make sense.
H8crilA 6mo ago
> crummy code, but not the very tool that's supposed to be the state-of-the-art coder Why not? It is subject to the same pressures, in fact it is subject to more time pressure than most corp code out there. Also, it's the model that's doing the coding, not the frontend tool.
- Eufrat 6mo ago
  I thought the sales pitch of all of this is that the AI was supposed to relieve people from having to do a bunch of annoying bootstrap coding and to do it in a way that we could extended easily. I have a subscription to Claude Code and despite my skepticism, it has been pretty good at just getting a goofy PoC thing going. When I look at the code, it’s usually insane unless the prompt was so narrow and specific like about writing a function that does one thing and only one thing. Outside of small, personal projects, I am still really uncomfortable at having agents run wild. I see the result, and then I spend a bunch of time having to gain the context of what is going on, especially if I ask it to implement features in spaces I have general knowledge, but not expertise. So, the problem remains the same. These things still need handholding by people who understand the domain, but having people become glorified PR reviewers is not an acceptable path forward. Arguing that there is lots of bad production code kinda avoids the actual issue that is going on here. Yes, a lot of sloppy code can and has been written by people. I’ve seen it myself, but it feels like the actual thing is that, we are now enabling that at scale and calling it “abundance” when instead we are really generating an abundance of completely avoidable security holes and logic errors.
  - drob518 6mo ago
    Exactly. I thought AI was going to be smarter. I thought AI would give us expert coders. Instead we have idiot savants.
    - cindyllm 6mo ago
      [dead]
- cassianoleal 6mo ago
progmetaldev 6mo ago
I mean, hasn't it learned from reading other's code? I don't think it can be any better than the common patterns and practices that it has been trained on. Some outlier of amazing code is probably not going to make much of a difference, unless I am completely misunderstanding LLMs (which I very well may be, and would gladly take any criticism on my take here).
- drob518 6mo ago
  Yes, but, that’s a low bar, no? I mean, when they first started talking about AI, were you envisioning a mediocre AI that is just average, or were you imagining an expert?

awesome_dude 6mo ago

> and then replacing those hacks with better code just never happens Yeah, we even have an idiom for this - "Temporary is always permanent"

switchbak 6mo ago
We'll fix it later. But as a great man once said: Later == Never.
parineum 6mo ago
"There's nothing more permanent than a temporary solution."

xienze 6mo ago

> I suspect if people saw the handwritten code of many, many, many products that they used every day they would be shocked. Absolutely. The difference is that the amount of bad code that could be generated had an upper limit on it — how fast a human can type it out. With LLMs bad code can be shat out at warp speed.

tombert 6mo ago
Oh I don't disagree with that. I am getting pretty tired of people making multi-thousand-line pull requests with lots of clearly AI-generated code and expecting it to be merged in. I think the better unit to commit and work with is the prompt itself, and I think that the prompt is the thing that should be PR'd at this point, because ultimately the spec is what's important.
- xienze 6mo ago
  > I think that the prompt is the thing that should be PR'd at this point, because ultimately the spec is what's important. The fundamental problem there is the code generation step is non-deterministic. You might make a two sentence change to the prompt to fix a bug and the generation introduces two more. Generate again and everything is fine. Way too much uncertainty to have confidence in that approach.
  - tombert 6mo ago
    If you make the prompts specific enough and provide tests that it has to run before it passes, then it should be fairly close to deterministic. Also, people aren't actually reading through most of the code that is generated or merged, so if there's a fear of deploying buggy code generated by AI, then I assure you that's already happening. A lot.
    - ben-schaaf 6mo ago
      How is "fairly close to deterministic" anywhere near good enough? LLMS aren't anywhere near cheap enough to do this either. That said it's so trivial to do, why haven't you done that already?

whatisthiseven 6mo ago

> I suspect if people saw the handwritten code Somehow, everyone has forgotten the terrible code quality that existed prior to 2020. https://www.youtube.com/watch?v=UjZQGRATlwA https://www.youtube.com/watch?v=UjZQGRATlwA Like, come on. Software has been shit for decades. AI hasn't observably reduced the quality of software I use everyday in a way that is meaningfully separable from normal incidents in the past.

0xDEAFBEAD 6mo ago
>AI hasn't observably reduced the quality of software I use everyday in a way that is meaningfully separable from normal incidents in the past. I have noticed a spike in web apps exhibiting random failures and glitchy behavior over the past few months.
jfkddkdjdj 6mo ago
[dead]
thesz 6mo ago
> AI hasn't observably reduced the quality of software I use everyday in a way that is meaningfully separable from normal incidents in the past. Most probably, you are not looking into that well enough. Average duration for AWS outages [2] was 1.5 hours per outage, 38 hours total. Most recent AWS outage in 2026 [1] downed AWS for 13 hours, a third of 38 hours spanning an year before, and was caused by AWS LLM coding tool. [1] https://www.theguardian.com/technology/2026/feb/20/amazon-cloud-outages-ai-tools-amazon-web-services-aws https://www.theguardian.com/technology/2026/feb/20/amazon-cl... [2] https://www.cherryservers.com/blog/cloud-outages https://www.cherryservers.com/blog/cloud-outages

benjiro3000 6mo ago

[dead]

progmetaldev 6mo ago

To me, it instead sounds like you care about the code you produce. You judge it more harshly than you probably do other code. It sounds like you are also meeting deadlines, so I'd call that a success and more production than what a lot of people tend to put out into the world. I often have a lot of time between projects, and am able to really think about things, and write the code that I'm happy with. Even when I do that, I do some more research, or work on another project, and immediately I'm picking apart sections of my code that I really took the time to "get right." Sometimes it can be worse if you are given vast amounts of time to build your solution, where some form of deadline may have pushed you to make decisions you were able to put off. At least that's my perspective on it, I feel like if you love writing software, you are going to keep improving nearly constantly, and look back at what you've done and be able to pick it apart. To keep myself from getting too distressed over looking at past code now, I tend to look at the overall architecture and success of the project (in regards to the performing what it was supposed to, not necessarily monetarily). If I see a piece of code that I feel could have been written far better, I look at how it fits into the rest. I tend to work on very small teams, so I'm often making architecture decisions that touch large areas of the code, so this may just be from my perspective of not working on a large team. I still do think if you care about your craft, you will be harsh on yourself, more than you deserve.

marcus_holmes 6mo ago

It's an unpopular truth for our industry, but the point of commercial software development is not to write good code; it's to write profitable code. There are some cases where the most profitable code is also good code. We like those. But in most (99%+) cases, the code is not going to survive contact with the market and so spending any time on making it good is wasted.

arcticbull 6mo ago
Yep this is especially true in the pre-product-market-fit phase. Most if not all of that code should be written to be thrown away. Any time you spend writing perfect code instead of your MVP is burnt runway and a chance for competitors to catch up. Once you show PMF though the balance changes to long-term sustainability and maintainability. What's going to be interesting is getting to a place where it generates better code than we would from specs. You can get better and better generated code by filling in the context the model infers. Do that long enough, and well, a perfect spec is just code. We do live in interesting times.
- KellyCriterion 6mo ago
  > Any time you spend writing perfect code instead of your MVP is burnt runway This. Once we crashed a product/company becaues of "we want it to be engineered perfectly" :-X
okr 6mo ago
To my believe there was not a goal to write good code. The goal was maintainability and to keep it simple, so that people understand. People come and go, you constantly get to see foreign code and you have to do something with it. Anyways, i see the maintainability hell coming onto us. I still wonder how i organize this with AI. I definitly do not want to touch it what is written by AI.
- drob518 6mo ago
  I think the industry-wide hope is that AI manages the AI-written code, but it’s unclear whether that’s actually going to work out in practice. Right now, my experience is that is dicey. I’ve had AI mess up a codebase to the point where I threw it away and restarted. Maybe I was doing it wrong, though, in that I was looking at the code and was increasingly horrified by the slop. I get the feeling that in this new world, we’re supposed to ignore how the sausage is made and just focus on the final outcome.

faangguyindia 6mo ago

i worked at companies in US where uptime monitoring was Page Refresh by QA team. where there was no centralized logs postgres had no backup or replication or anything

bombcar 6mo ago

This is not just true of code; it is true of everything - the whole world is held together with spit, bailing wire, a prayer, and some old dude who remembers.

duskdozer 6mo ago
It doesn't mean it's something to strive for
- bombcar 6mo ago
  Totally agree; we've created a system that goes so far beyond technical debt we're going to have to call it technical usury, and we're piling it up at rapid rates. Given that most code gets thrown away, perhaps it won't matter much. Perhaps

Sohcahtoa82 6mo ago

> I suspect if people saw the handwritten code of many, many, many products that they used every day they would be shocked. At a place I worked at with their core product written in Python, it was exceptionally common for engineers to make shell calls for file operations that had easy Python-native functions. For example, rather than `os.remove("some_file")`, they'd do `os.system("rm some_file")`. Sometimes, the file name being acted on included user input. I found so many shell injections that could have easily been prevented.