Decoded: it's next to useless, it's damaged pace, and it isn't value for money. It's boiling the ocean.
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.
CTOs / CEOs have demonstrated how completely useless they are pretty much across the board over the last few years. Groupthink and bandwagons, zero innovation or use of brain.
> AI makes it cheap to write code. That is not the same as it being cheap to ship it, or to maintain it. One participant put it cleanly: cognitive debt is the new technical debt.
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.
Is this true now? I used Claude-backed Cline in March to make that migration, and it got SO much wrong, mainly due to the lack of solid documentation and example code for it, I imagine. Probably the project where I've had to fix the most AI mistakes so far (it was incapable of fixing the mistakes itself, it just kept getting it wrong in different ways).
Considering all the possible levels of abstraction software can represent, I'm imagining it as a fractal. The worst case - a mistake can be introduced by generative AI at any of the abstraction levels at any moment. Meaning, at worst case the whole thing has to be in the head of at least one person to validate the result against. The moment a project is growing beyond a single person capacity to hold it in one head possibility of plausibly looking error introduced at any abstraction level is added to the usual multi-engineer coordination costs.
Copyright issues don't seem to be addressed by any large language model provider.
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?
My worry is that AI will make these companies product-obsessed, the public will mistake the output for AGI, and the real engineering underneath will keep getting overlooked.
There were some good insights in there. I like the idea of changing the hiring interview process to focus on testing code review ability. I feel like this would have been useful even before AI.
A candidate who can identify tradeoffs present in some code and make insightful comments is likely good at systems thinking. It's a highly 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. Many times in my career, I met engineers who seemed mediocre at first because they didn't know a fraction of what I knew, but I later found out they also knew a fair amount that I didn't know.
I've even had an extreme experience in the past year where a colleague seemed to struggle with basic code constructs and for the first month I was thinking to myself "this guy doesn't know how to code". He asked really basic questions and said he didn't know because his background was Python and not Typescript... But I know both of these languages and I just couldn't make sense of this explanation given the kinds of questions he asked and mistakes he made. If I had been asked to review him at the time, I would probably have given him a pretty bad review but after about 1 month and a half, this guy accelerated and literally became the most productive engineer on the team. No leetcode coding test could have predicted this.
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.
On a different topic, 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 hundreds would recognize it unless they read carefully. 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... Also most engineers are afraid to ask why we need a SocketContextManager or a TaskContextSwitcherMediator or the TaskOrchestrator and TaskOrchestratorFactory that comes with it... Nobody will ask why we need 10 different Helm charts to split things up into microservices... Nobody will ask why we need 1000 top level dependencies with a total of 10k nested dependencies. Nobody will question those decisions because they're afraid they will look dumb for questioning complexity.
You cannot question system complexity without acknowledging that you find something to be complex....
They should think about what happens when expectations are so high that a single dev must deliver and maintain multiple products. What stops that single dev from leaving and offering the same product on his own.
Allowing non-technical PMs to ship code is fine if they’re the one getting called up in the evenings and weekends when it breaks. Maybe it’s a good exercise to show how much has effort must be applied to each commit.
Regular reminder: the ‘lines of code’ metric is a liability not an asset. The best engineer is not the one who can produce the most lines of code in a day but the one who can ship the feature with the fewest lines (and prepare the system to receive the next feature with few lines, too).
> Language doesn’t matter anymore: Python, Go, Rust, Node. But system design hasn’t changed.
I keep seeing this claim, and it's incoherent. Programming languages are the languages we use to express system design, and just like Sapir–Whorf in natural languages they admit, emphasize, or force consideration of different concerns in the design process. If we did get to the point where those languages ‘don't matter any more’ it would just be because modern tooling allows us to express ourselves at a higher level than these languages were designed for — but then whatever higher-level language you're using to express yourself matters instead (and matters more than ever: the higher-level you go the more inaccuracies compound).
Programming languages are designed for humans, not for computers.
Classic Software Engineering stages of Specification and Verification (both Formal and Informal) take center stage with the software unit being treated as a blackbox. Developers are now "Systems Engineers" responsible for end-to-end systems delivery.
> If your team can generate code faster than it can review it, you have a bottleneck. The constraint is human judgment, not output.
Given almost any group of coders, who are proficient in their technologies of choice, coding speed almost always exceeds reviewing speed. Same as it ever was.
Given any arbitrarily worthwhile problem to solve, the actual cost is in solving the problem or the cost to serve or both. Cost to serve if the solution is inefficient or the problem space barely tractable.
22 comments
[ 3.2 ms ] story [ 41.0 ms ] threadImplicitly 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.
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.
Is this true now? I used Claude-backed Cline in March to make that migration, and it got SO much wrong, mainly due to the lack of solid documentation and example code for it, I imagine. Probably the project where I've had to fix the most AI mistakes so far (it was incapable of fixing the mistakes itself, it just kept getting it wrong in different ways).
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?
2 years is an era now?
A candidate who can identify tradeoffs present in some code and make insightful comments is likely good at systems thinking. It's a highly 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. Many times in my career, I met engineers who seemed mediocre at first because they didn't know a fraction of what I knew, but I later found out they also knew a fair amount that I didn't know.
I've even had an extreme experience in the past year where a colleague seemed to struggle with basic code constructs and for the first month I was thinking to myself "this guy doesn't know how to code". He asked really basic questions and said he didn't know because his background was Python and not Typescript... But I know both of these languages and I just couldn't make sense of this explanation given the kinds of questions he asked and mistakes he made. If I had been asked to review him at the time, I would probably have given him a pretty bad review but after about 1 month and a half, this guy accelerated and literally became the most productive engineer on the team. No leetcode coding test could have predicted this.
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.
On a different topic, 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 hundreds would recognize it unless they read carefully. 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... Also most engineers are afraid to ask why we need a SocketContextManager or a TaskContextSwitcherMediator or the TaskOrchestrator and TaskOrchestratorFactory that comes with it... Nobody will ask why we need 10 different Helm charts to split things up into microservices... Nobody will ask why we need 1000 top level dependencies with a total of 10k nested dependencies. Nobody will question those decisions because they're afraid they will look dumb for questioning complexity.
You cannot question system complexity without acknowledging that you find something to be complex....
oh wow, what a trustworthy source of information this human written article is.
> Language doesn’t matter anymore: Python, Go, Rust, Node. But system design hasn’t changed.
I keep seeing this claim, and it's incoherent. Programming languages are the languages we use to express system design, and just like Sapir–Whorf in natural languages they admit, emphasize, or force consideration of different concerns in the design process. If we did get to the point where those languages ‘don't matter any more’ it would just be because modern tooling allows us to express ourselves at a higher level than these languages were designed for — but then whatever higher-level language you're using to express yourself matters instead (and matters more than ever: the higher-level you go the more inaccuracies compound).
Programming languages are designed for humans, not for computers.
Classic Software Engineering stages of Specification and Verification (both Formal and Informal) take center stage with the software unit being treated as a blackbox. Developers are now "Systems Engineers" responsible for end-to-end systems delivery.
See also my previous comment chain here - https://news.ycombinator.com/item?id=48431591
No no no no no no no. Not even vaguely remotely close to being true. Why are managers so delusional
Given almost any group of coders, who are proficient in their technologies of choice, coding speed almost always exceeds reviewing speed. Same as it ever was.
Given any arbitrarily worthwhile problem to solve, the actual cost is in solving the problem or the cost to serve or both. Cost to serve if the solution is inefficient or the problem space barely tractable.