> The best devs still put out good code, but the poor devs are learning nothing while their metrics look great. I can't help but think we are racking up immense amounts of debt that will very soon become due.
I agree with this, but the reality is that it's only the result of models empowering devs, and power in good hands amplifies positive results while power in mediocre hands amplifies technical debt.
It's a good time to choose wisely who you work with.
> It's a good time to choose wisely who you work with.
Very true, but this also makes me think what kind of ridiculous obstacle course future hiring process would look like.
In a land where anyone with a pulse can prompt AI to make an app for them - how would future hiring managers and team leads figure out who will drag codebase down with tech debt and who wouldn't?
Probably the same way they have for the last 30 years: poorly, in a dozen different ways, depending on what that particular hiring manager thinks has correlated with successful hiring in the past
Future hiring will select for people that shipped the most, plain and simple.
The tech debt concerns are much ado about nothing. Use the next model to clean it up, big deal. Code is cheap.
The people that sat around handwringing about tech debt and trying to read every line of LLM code will really struggle to find a job. The profession fundamentally changed, and these people did not catch up.
I can imagine a code review where you're asked to implement and merge 10 PR in a sample codebase and the codebase is littered with the sorts of mistakes and slop that vibe coders put in when they're careless and you're asked to correct the mess and make it work.
> It's shocking to me that he was aware of it and yet considered it an unrelated defect that can be individually corrected, and not a flaw that blows the entire idea wide open.
Hindsight is 20/20. He was suggesting free markets as the counter to entrenches aristocrats. It took centuries for our modern understanding of monopolies and rentier capitalism to develop.
He was arguably also right insofar as the slippery slope that he warned about is pretty much exactly the slippery slope that we slid down. And I can’t really blame him for the fact that most Adam Smith fanboys don’t seem to have read the second half of his book.
Feels like a tired trope by now of people who're stuck with the ideas of what LLMs could produce a year ago not knowing that by this point some people actually understand how to work fast and get great results out of them. There's no contradiction between having LLMs write reams of code that you architected and designed with purpose and whose output you vetted.
Definitely, but hyperbole about feature parity on a 4 MHz CPU with 128k of RAM doesn't help. I have conversations with Claude that wouldn't fit in that amount of memory.
Most line-of-business software has a lot of optimization opportunities. Making software optimized takes up time that can be spent building features. The fact that you can just make things go fast without having to take time away from feature building is actually pretty awesome.
Not taking 5 seconds to load text is a feature. 10x more valuable than whatever other shitty feature you're thinking of piling onto your monstrosity. Like, actually tangible valuable to users and consequently your business; Google has already done the studies at scale that demonstrate how every 100ms of delay has an observable impact on usage statistics and user retention.
> And I don't think it's plausible that the gap between those two is "well you just need to use it right".
But this has always been the gap between effective software engineering and garbage. When humans write software we put a large amount of effort in having best practices, hiring seniors with a track record, and enforcing process that empirically shows good results in reliability.
This is the same in AI. You need to have thorough code reviews by humans and agents, do a lot of manual QA, understand the tradeoffs when codebases grow, keep good documentation, keep bad comments out or anything that wastes the agents' context windows, etc.
The reality is that most people who produce mediocre code are mediocre users of AI, except that now they're empowered to produce crap 10 times faster and are too ignorant to distinguish between productivity and accelerated crap production.
> Ive actually yet to hear an X applied to production code that doesnt make me think that.
This is one of those things we value in theory in engineering but not in practice.
Reducing code as an artifact might mean coming up with clever ways or compressing data, like making code that generalizes and abstracts.
This is fine if you're experienced and clever. But a lot of organizations don't have that many clever or experienced engineers and those tools cause more harm in the hands of those people. Hence compromises must be reached and verbosity is valued because it is explicit.
I used to believe otherwise but then I worked in larger orgs with a lot of mediocre people who still provided value but needed to be given the means to add value.
> At least back in the day there weren't endless comments about how this widget is load-bearing
By far the biggest problem 90% of developers have with AI is that they should be turning off comments, as it's clear that the training data they have is no good for developing a theory of mind for an engineer who has to read them.
I've turned them off and add them myself at review time and am quite happy.
Requiring the coding agent to (try to) iterate on code clarity until comments are no longer necessary, probably doesn't hurt either. Save the commentary for conversation logs, agent Markdown files, and other sorts of documentation.
> I see AI introduce all sorts of bugs all the time in my personal projects that I would never introduce, and would never think to test for, especially around anything graphical.
This is referred to in the need for E2E testing and E2E testing not being a substitute.
Code review is definitely the biggest challenge of AI-driven development IMO. I still have not found good processes that work in my org, but for my personal work I independently reached the author's conclusions a while ago and am very satisfied with the results.
I agree with this, but the reality is that it's only the result of models empowering devs, and power in good hands amplifies positive results while power in mediocre hands amplifies technical debt.
It's a good time to choose wisely who you work with.
reply