To me it was always pretty clear. Though I have heard there was some probable weirdness in the functionality. Still bit questionable of grandfathered "classic" subscribers were forced to go through this to keep their status. But that is pretty normal, only have seen one site that allows coming back later to subs at old sub.
With them killing the "classic" it doesn't really matter anymore. Better just to cancel.
I've been involved in many "rewrites". Almost exclusively, the result is worse for users at release.
Especially with "big bang releases". Where a team is working behind the scenes for months or longer, attempting to rewrite the old system "bug for bug". Releasing and then finding out that some users would "hold the space bar to make the CPU heat up, and configuring emacs to interpret that as 'control'" (XKCD 1172). First, users don't see any improvements for all the time that the new system was being built. Secondly, they get all the new stuff bundled. So while they may even get value from the rewrite, it is bundled with the stuff that makes it worse. Three new features, one new bug. And all everyone sees is that new bug.
But even rewrites where parts are swapped out and released immediately, (strangler vine pattern!) are worse for the users. They do get value fast. And in small increments. They can give feedback early. But the (much longer) period in which the replacements are implemented, is almost always one of confusion, complexity, and "having to learn new things every week". We all know the systems where "change email" is a link that leads to a form on some other site, in an old design rather than part of the "edit account" page. Because the "account service" has been extracted, but the "notification service" replacement on the backlog still.
"rewrites" are almost always for the benefit of the business, the technical team, or other internal reasons. If "benefit to the users" is a part of it, it's almost always secondary: so that we can build and release and scale new features and cool stuff for users faster than with the old legacy spaghetti debt.
CoreWeave pays 9.625%. But someone expected them to not be able to meet that so they sold what debt they had at discount to someone who now effectively gets 16% on amount they paid for.
Still, this means that people would only be willing to loan new money to them at that 16% rate.
Not to forget versioned inside the document. The same spreadsheet produces same answers if it is not edited. Same can't be said from programs that can be recreated over and over again.
Jaguar also did extremely well spread marketing campaign. It is really questionable if it moves units. Same goes for this one. You might get notoriety but that doesn't always translate to sales. And I am pretty sure no one was unaware of Tesla at that point.
I wouldn't be so sure about capital in future. I think there might be real look for return on any new capital they are getting. Be it equity or debt. And that alone will not be great for them.
I would be extremely cross if I heard that someone gave my location information to some company that runs this stuff. That level of privacy violation should lead to disinheritance.
Well, let me tell you that you should be extremely cross.
Unless nobody knows your address or you’ve signed up for any services, these companies already have your information.
Some of these use case feel so imaginary that lot of people just don't get why would some other people do them. Like with food delivery I want to select specifically what I want and evaluate if the price is right. Same goes for ordering most stuff or deciding on vacation.
Maybe I could get train ticket from AI... Or order taxi. At least until it went wrong for the first time...
It doesn't have to be that way. You can use llms to greatly improve the quality of the code. You do this by focusing on one part of the design use the LLM to explore alternatives, use it to poke holes in what you have. I think the engineering cultures that embrace this way of using AI will far outperform everyone else in the long term.
I just had a discussion with the AI recently about whether to duplicate the code something used or refactor it so both places used the same code. The decision was to duplicate the code, but make notes (and a ticket) to refactor it later - because the time to test the possible regression cases of the original code wasn't available right now.
I could have worked through all that on my own, but having the AI as a rubber duck to talk to - plus the edge cases it was able to point out - was really helpful.
> I just had a discussion with the AI recently about whether to duplicate the code something used or refactor it so both places used the same code. The decision was to duplicate the code, but make notes (and a ticket) to refactor it later
I wonder if a refactor is even necessary.
Concepts like KISS, DRY, etc. are largely human-centric. They're meant to make code easier to write, understand, and maintain - for people.
Duplicating code was traditionally "bad" because it increased maintenance costs, risked divergence, and added cognitive overhead for human developers.
But with coding agents, some of those tradeoffs start to change. An agent can find and update duplicate implementations in seconds. It doesn't need to maintain the same mental map of a codebase that a human does.
And if we have good specifications and comprehensive tests, behavioral divergence should be detectable and correctable. In fact, duplication can offer an advantage over shared abstractions: isolation. Changes to one implementation don't risk breaking unrelated consumers of shared code, and each implementation can evolve independently.
Maybe we won't need as many high-level abstractions, or eventually even some of the architectural patterns we consider best practices today.
If the cost of writing and maintaining code approaches zero, perhaps we should optimize less for human readability and more for runtime performance, memory efficiency, isolation, and correctness.
We might even regain some CPU and memory efficiency by eliminating layers of indirection, virtual calls, and abstractions that primarily existed to make code manageable for humans.
Perhaps the optimal architecture for AI-maintained software is fundamentally different from the optimal architecture for human-maintained software.
A lot of our software engineering best practices are based on the economics/ergonomics of human maintenance. What happens when those fundamentally change?
> Duplicating code was traditionally "bad" because it increased maintenance costs, risked divergence, and added cognitive overhead for human developers.
Until proven wrong by coding agents, this is still the case even for agents. Not sure why you are assuming this doesn't apply for the machine
I cannot read a 50-page T&C document. I mean, obviously, I can physically do it, but I don't have the patience, and I'd lose track of what I'd read. Getting an LLM to summarise a 50-page T&C document is simple, it doesn't lose track, and it spits out a summary in seconds.
I cannot read a 50K LOC code base at once. I mean, obviously, I can physically do it, but I don't have the patience, etc. I need mental shortcuts like abstractions layers to hold even parts of the code base in my head. LLMs don't. They can read that in seconds and hold the whole thing in context.
This doesn’t really support the argument that KISS et al don’t apply to LLMs. They may not ‘need’ these principles for the same reasons as humans, but will still benefit from the context having higher information density.
> but will still benefit from the context having higher information density.
That's an assumption.
And is that what we really care about anymore? Maybe we are ok accepting some "inefficiencies" in the code for the LLM but we get better CPU utilization or cache/RAM usage
So is that ;)
But yeah, the link between context length and performance reduction is well researched. Automatic context management has been getting better, but it’s not a panacea, especially in very large codebases and long sessions.
> Maybe we are ok accepting some "inefficiencies" in the code for the LLM but we get better CPU utilization or cache/RAM usage
If by ‘inefficiencies’ you mean choosing hardware-friendly architectures over those that correspond to a human-friendly world model, then I would agree with you (this was already required in my domain pre-LLMs). Even still that does not stop one from adhering to DRY, KISS, etc as the abstractions required are often either free or close to free at runtime.
>because the time to test the possible regression cases of the original code wasn't available right now.
The models don't know that they're not human when they estimate. It's worth telling them that all estimates need to be made in the context of an agentic AI doing the work.
It's funny, I've had similar conversations, where the agent would recommend the 'lazy' solution because the robust one took too long. More often than not, it was assuming human-hours of work though. Once reminded that a clanker would be doing the work it's conclusion shifted to the robust one.
Now, I wonder if it actually agreed, or if it sensed that I preferred the robust solution and was trained to make me happy.
It’s jarring when the bot tells you something will take a “week of work”. A good reminder I guess that it doesn’t have self awareness as we usually think of it.
Yeah, I've seen that, too. In my case it was less about the dev time and more about the regression testing time (much of which would fall on QA and involved reading from external feeds, etc - so, complicated). But your point is fair. The AI is ... notoriously bad at LOE. Not that it's always wrong, but frequently enough (and by a large enough amount) that tradeoffs like that really need humans considering them.
People complain about LLMs not respecting KISS, but fail to address why = LLMs being defensive and coding for situations that either do not happen or are unlikely to happen. That doesn't absolve you from deciding using your human brain if given change makes sense or doesn't. You can also tell LLMs to not program defensively.
Same with any other acronyms - if you don't set up guardrails on when given principle should apply you'll get code that you can only complain about.
My complaint is that LLMs’ approach to making code robust is something we used to pejoratively describe as “enterprisey”.
Oftentimes there are two broad ways to fix a gap in the logic. You can eliminate the source of it, which often involves refactoring but tends to result in less code and cleaner, more comprehensible logic. Or you can leave the gap there, but attempt to render it safe by adding extra logic to detect and handle the error condition. This reduces changes to existing code, but makes the overall system more complicated.
You can’t just indiscriminately favor one approach. Which one of those is best depends on the situation. The deciding factor is often something like a time constraint that you can’t know just by reading the code. You might need to talk to your team before deciding.
But LLMs don’t do that. They always choose option B: slap a bandage on it. Keep on adding more epicycles. In the 2000s we learned that, over time, always choosing this approach inexorably leads to codebases that are brittle, bloated and expensive to maintain.
So the problem, from my perspective, isn’t that we shouldn’t be coding defensively. It’s that LLMs encourage us to do it in a way that we’ve already learned is unsustainable.
Agree. It should fall on to developers to decide what to do = whether tackling tech debt is viable solution (whether making decision on their own or talking to people that can make such decision) or not. If, however, you're told "here is a codebase that you're seeing for first time, fix this error" and you simply cannot make the decision, even prior to LLMs you'd put a bandaid on it. Or at least - that's the standard approach = fix now, refactor later, where later in my experience never happens (sorry for this train of thought).
I don't think this is anything new, nor LLMs are to blame here. Although - LLMs want to make you happy, or maybe they don't think about what user actually needs, just how to accomplish the goal that was stated; they do stuff without asking questions (unless you constrain them or plan first). I've actively put in a hook for my agent to not make decisions on their own and ask me when it detects it's about to make a decision.
Agreed, it is not at all a new problem. The enterprisey codebases I’ve encountered are ones that have chronically had no clear owner, or constant ownership churn. I have been in that position before, and I also decided to make the code even more bloated for the same reason: I did not and was not going to have the time to learn the system well enough to safely do a better job.
I think where a lot of people run into problems with the KISS principle is they conflate simple and easy. More often than not, simple is hard. Which is maybe a soft reason why agentic coding, which is all about trying to make every task easy, leads so consistently to complexity and bloat.
Nobody else is likely to see this comment but I want to make it anyway. Yes, simple is hard. Thank you for articulating it so well.
And yes, that's also why LLM code is usually (unless driven by someone who really knows what he's doing) full of unnecessary complexity. Because although LLMs can get a much broader "understanding" of a code base than I would have given them credit for a couple years ago, their "understanding" is still shallow. And what you need to truly be able to achieve that hard simplicity (I heard someone refer to it once as "the simplicity on the other side of complexity", e.g. when Kepler figured out that orbits were ellipses, not circles, and that allowed getting rid of epicycles) is deep understanding. Which LLMs are not capable of, hence why their code is full of the kind of needless complexity that one produces when one has only a shallow understanding of the code. (E.g., you in that enterprisey codebase when you weren't going to be given time to reach deep understanding).
I don't think I agree that simple is hard. Simple takes effort. Simple requires that you have agency. Simple has all the information available. Simple means that you're accountable for something. I'll be cynical here - it's sooooo much easier to say: this is how it was when I arrived here, it's not my problem, what will I get out of this, somebody told me to do it like this, let's leave as it is, there's no point in touching this. And nothing in the above is LLMs fault! Well, unless at least now you can say - something did it like that! It's not my fault, it's what LLM told me to do.
I'm hopeful that LLMs make iteration and refactoring easier. That they'll allow developers to say to product (or even to themselves) "this module that is a dumpster fire? Sure, I can let agent investigate/refactor and that work that would have taken 2w will be done in half a day, do you want to go ahead?". That they'll allow developers to investigate how to make things simpler, more understandable, more coherent, to agree on a one fucking way to do things.
Anyhow, apologies for being glum and straying away from the topic, but I also wanted to make a comment that is unlikely to be seen :) the bile comes from past personal experience and is not directed towards anyone (it's more of an acid reflux).
When you say "simple takes effort", that's kind of what I meant by "simple is hard". It takes work, it takes looking at the problem for a long time (Kepler studied orbits for years) until you understand it well enough to have the epiphany that lets you reduce the complexity down to "oh wait, orbits are ellipses and that solves everything!". Since you preceded your statement that "simple takes effort" with a disagreement about simple being hard, I wonder what you thought I meant by "simple is hard".
So true! And it goes hand-in-hand with a different problem: You being able to try and brute-force solutions.
If you write your prompt as a request, and not carefully as an idea or suggestion, the bot can blindly agree to 'help'. And if you are stubborn about it, you can lose hours on something that cannot work, or make the code infinitely worse.
However, it's also the path of getting better at programming. To learn to take a step back, to ask yourself if it's really sensible. Just that now it also involves questioning the bot's help, as well as writing your prompts to prevent it.
> coding for situations that either do not happen or are unlikely to happen.
Not coding for situations that “do not happen” is exactly what creates vulnerabilities. But I also don’t think that such code is the main source of complexity in LLM-generated code.
An example to what I'm talking about: I have application that takes two inputs from request. I've put in validation on request values to deny values that are greater than 100. In my code I'm adding these values. LLM can say "cater for addition of these two numbers, because they might go over MAX_INT and result in overflow". This is a situation that won't happen. LLM can recommend - add assertions. That's unnecessary.
And the day you add a way to batch import request through another code path, you may forget the validation.
Having it in the lower layer is correct, a proper optimizing compiler should be able to detect there's a single code path to the function and that the checks have already been done, skipping the second check.
Arguably it’s only unnecessary when the value range is enforced by the programming language (types). The structure of who calls what in the code can change, and suddenly larger values can appear. You don’t want to have to perform whole-program analysis on every change to check whether all assumptions made in the past still hold. That’s also a source of vulnerabilities: assumptions that held when the code was written, but stopped holding sometime later.
That’s why I think code needs to document all its assumptions, and in a way that is checked by the compiler to the extent possible. If you document that the values have restricted range, then the AI should be taking it into account.
I vibe-slopped a small and local forms application for my family. I explicitly mentioned that fact to the LLM.
Yet, I removed 2/3s of the code, because it triple-checked that every file really existed and was valid, that the input form was less than a million bytes in size, that there were propper HTTP status codes for everything, that every possible error from reading data was eagerly checked and caught, and so on.
Like come on, three people will ever look at it. So keep it small and tidy so I can understand it better!
Depends on your incentives, most people and companies are measuring Lines of codes and features as the metric so ofc it will increase it, but AI can create small KISS applications. It might have a little difficulties in doing so sometimes because it sometimes likes to overengineer things but I have to wonder how much of it is because it is RLHF'd to solve questions at any costs in terms of lines of code rather than training it in solving it in KISS principles. Also I wonder how AI will perform if we explicitly treat KISS as the only principle and have checks running on it and have it discard all the code which wouldn't follow KISS principle if it doesn't follow the principle.
With them killing the "classic" it doesn't really matter anymore. Better just to cancel.
reply