It being expensive to ship or maintain software still sounds like technical debt, no?
For cognitive debt, I'd expect something like context switching and reviewing large amounts of code being exhausting.
Migrating Spring Boot apps from 3.x t 4.x is now easy given all the tooling available.
But the administrative load can't be reduced by faster code delivery and that's the new bottleneck.
If an LLM is trained on GPL code then that code has become an intrinsic part of the model (because if it hasn't then what was the value of training on it). So shouldn't that model now also be licensed GPL?
And how do I know the LLM output is not reproducing substantial chunks of GPL'd code, making my code GPL?
Law is probably going to take a while to catch up here.
2 years is an era now?
The best case for engineering is always: nothing went horribly wrong in public.
A candidate who can identify tradeoffs present in some code and make insightful comments is a really effective way to test someone's knowledge, intelligence and taste.
It's actually brilliant because it provides the company with a way to actually improve their engineering posture since the company could land on a candidate who is more skilled than the engineers doing the interviewing.
Most leetcode tech interviews are a series of puzzles which most company insiders can solve but they never include problems that the candidate could solve but which the interviewer could not.
Leetcode interviews are horrible because they test a tiny subset of moderately difficult questions under time constraints and ignore a much larger set of problems that are much more complex. There is an incorrect assumption that someone who can solve extremely complex problems can also solve moderately complex problems under time constraints. This is absolutely not the case. It's almost mutually exclusive in fact since people who work on complex problems don't have the time or interest to practice solving simpler problems so they can never solve those fast enough to compete with fresh university grads who have been practicing those for years and don't know anything else.
That said I was sceptical of this comment:
"I honestly think you can have a fifteen thousand line PR and say, I need a human to review these three lines."
15k lines is a lot of code. I could destroy any software project, irreparably with 15k lines of code and not one engineer out of thousands would recognize it. You can absolutely destroy a codebase with 15k lines of code, without any obvious backdoors or malicious code. How would I do it? I would invent counter-productive abstractions and write a lot of unit tests for them to lock down the design... Then I would watch other engineers build on top to further lock it down... Let the flawed design accumulate debt for a few years until the entire codebase becomes slow, insecure and totally unmaintable. Nobody would ever remember that I'm the one who set the project on a bad course. Nobody ever suspects the person who invents the complex abstractions and who everyone comes to with questions.
So my view is that every single one of these 15k lines needs thorough analysis. Each of those 15k lines represent the soil upon which the next round of seeds will be planted.
CTOs told the, reporters, who know what technical debt means (not really)
ggm•1h ago
Implicitly they've woken up to the value proposition which was latent in their tech hires: detailed knowledge of their code and systems. They've just tossed that away, and even worse they've smooged it into unfathomable information systems which probably share aspects of it with their competitors.
AI destroyed their value.