61–70 of 113 posts
Earlier quoted context omitted.
That’s why junior devs generally aren’t give the responsibility of architecting a large scale refactor. Yet people seem to be trying to had these types of tasks over to LLMs.
https://news.ycombinator.com/item?id=48841676
> It's not used in production.
Sounds like it’s a tech demo as of now.
Earlier quoted context omitted.
I work on a codebase from the early 2000s, a lot of it using webforms, a long abandoned .NET technology. A rewrite preserving all behavior and making no observable changes whatsoever would be amazing. But it’s also tested exactly as well as you’d expect from something like that so I’d rather not let AI go wild.
Good example. Transitioning from an outdated framework to a modern (or sometimes "slightly less outdated") one is probably one of the few situations where you do not want to change semantics at all. And in my experience, these are _dangerous_. People go into "while we're at it..." mode, and it quickly turns into a big 2.0 kind of thing that takes forever. I would argue that LLMs can speed this kind of thing up, but n…
Building products that no one really knows the internals of is crazy to me, and the methods people have of trying to mitigate that problem seem half assed at best
What's the point of the rewrite if it doesn't fix the underlying issues, though? A rewrite being a good idea often hinges on the ability to simplify. After a decade or more, it's now apparent what the application should and shouldn't do, so one can build it with those learnings and shed all tech debt from how it grew organically. Aka preserving all behavior is not what I would want from a rewrite. The point would be…
Earlier quoted context omitted.
Good example. Transitioning from an outdated framework to a modern (or sometimes "slightly less outdated") one is probably one of the few situations where you do not want to change semantics at all. And in my experience, these are _dangerous_. People go into "while we're at it..." mode, and it quickly turns into a big 2.0 kind of thing that takes forever. I would argue that LLMs can speed this kind of thing up, but n…
It still kind of blows me away that almost any LLM usage for coding isn't viewed as "high risk appetite" Building products that no one really knows the internals of is crazy to me, and the methods people have of trying to mitigate that problem seem half assed at best
We have some and sometimes marketing comes back with some extra revenue from a partner if we build out feature X Y or Z for their new product launch. The contracts are signed so engineering has to do it or we’re blamed for lost revenue.
A few of those a year and you eventually end up in a similar situation.
Earlier quoted context omitted.
Say I rewrite a large codebase from python to C++, preserving all behavior. That's up to a 50x speed up.
Not a good example i'd say given Python's position as pretty much the ultimate glue language :) You'd more likely keep the python shell (and faster developer iteration speed) and push measured hotspots down into c++/rust/c/whatever. Incidentally, Whenever i've done this in the past it's had a pleasant side effect of improving architecture. You end up forcing something akin to "push for's down and pull if's up" becaus…
Earlier quoted context omitted.
Joel is right, but he's also wrong. I've been on the other side of a timid engineering culture that commerical rides roughshod over and its this depressing immeasurable decline. The company stagnates and slowly tailspins around an unmaintainable product until a competitor steals their lunch in a way that that further obscures cause and effect. Estimates are considerably longer, QA is much harder, integration is full…
The LLM might change the economy of this, but I doubt it. I tend to believe that the engineering culture you describe will end up producing similar or, as Joel postulates, an even worse result, just dressed up in a modern stack. If the technical leadership remains the very same one that enabled such a culture, I don't see them being able to suddenly produce a genuinely better software product only because an LLM is i…
With more disciplined engineers we are slowly cleaning it up but it is taking years to realize because management won’t allow work to be stopped on feature development. If we’re lucky, we get two sprints a year to fix things, usually around holidays when half the team is afk anyway so not a huge chunk can be fixed. Then on top of all of that, if you break something when trying to Boy Scout rule improve things, you get chastised and management clamps down more on “scope creep”.
Add in LLMs and now engineering management is convinced that they will solve our problems. Except it can’t really because the project is so spread out and disjointed that it’s impossible to reason about. You’d spend tens of dollars just to have it follow all possible branches of our most critical user flows (and then with hallucinations on top!).
I’m not saying the bots aren’t useful, but they cannot comprehend a disaster zone architecture in anything more than extremely targeted chunks. Without being able to see the entire thing, having it reliably refactor is just not possible without weeks of manual testing or taking a risk and being prepared to rollback on short notice. Writing tests would also take many weeks and if the point is to rearchitect to something sane, a snapshot test is not really going to cut it.
It’s a pickle of a problem for sure… and I’m not sure I will survive at this company long enough to see the end (though I’ve been here years already).
What's the point of the rewrite if it doesn't fix the underlying issues, though? A rewrite being a good idea often hinges on the ability to simplify. After a decade or more, it's now apparent what the application should and shouldn't do, so one can build it with those learnings and shed all tech debt from how it grew organically. Aka preserving all behavior is not what I would want from a rewrite. The point would be…
Earlier quoted context omitted.
Good example. Transitioning from an outdated framework to a modern (or sometimes "slightly less outdated") one is probably one of the few situations where you do not want to change semantics at all. And in my experience, these are _dangerous_. People go into "while we're at it..." mode, and it quickly turns into a big 2.0 kind of thing that takes forever. I would argue that LLMs can speed this kind of thing up, but n…
It still kind of blows me away that almost any LLM usage for coding isn't viewed as "high risk appetite" Building products that no one really knows the internals of is crazy to me, and the methods people have of trying to mitigate that problem seem half assed at best