100%. I am really getting tired of the narrative that code before LLMs was optimally performant, perfectly architected, completely understood, and bug free...
Does the author not have the experience of working in a legacy codebase that nobody really "understood"? Something sufficiently complex where even the senior SW devs needed to scope out project work and research the codebase for dependencies or potential issues?
I fail to remember a time at LARGE_CORP where even the most experienced developers were able to scope out or design a feature without studying the existing documentation, timing diagrams, etc....
100% agree. I understand the argument around the "fun" of programming and learning. But my joy from coding (especially when working 9-5, on a team of 5-500 people) always came from the value creation for other people and for society.
AI has simply been a tool to accelerate that and I've genuinely never been happier about the value I provide to society. I find it hard to take the "respect of the craft" argument at face value - even if I enjoy knitting by hand, I can still support the existence of mechanized looms and machinery that provide affordable clothing in the millions.
My late grandmother knit 1-2 pairs of socks per day and donated them to the homeless center - absolutely amazing thing to, and it kept her motivated and sharp up to 104 years of age.
However, if her ultimate goal is providing socks to the homeless, would it not be better for her to work a library job for $15/hour, then take the $100+ a day and purchase then donate 30 pairs of socks? Even if the socks are a lower quality and wear out twice as fast, she could help 15x the people thanks to the mechanization and efficiency provided by the devision of labour.
I see this divide more and more and truthfully I wish I could understand both sides. I am encountering trouble in the startup I'm working on for exactly this reason: I feel laser focused on the attempt to create value for others, while my mech eng cofounder has this "respect of the craft". From from my perspective this has only caused delays in generating revenue.
Any help in understanding those who "love to make" (as opposed to those who "love to deliver") would be extremely useful.
> my mech eng cofounder has this "respect of the craft". From from my perspective this has only caused delays in generating revenue.
You need both. You really need both. A salesman to keep the craftsman from getting too bogged down in details to ever finish, and the craftsman to keep the salesman from ever lowering quality too much that customers start seeing the company as money grubbing misers trying to make a quick buck.
It only works with both. Too much of one and you sink.
This can be seen time and again in successful endeavours. (Apple, Microsoft, Google, star wars, honestly so many movies, moon landings, the list could go on)
I don't think you really are struggling to understand, you just don't agree.
Some people genuinely enjoy the process of thinking hard about a problem and writing the code that solves it.
Literally the entire "flow" of coding has changed. It's now about parallel agent management and testing, less about any actual writing of code. Even thinking hard about problems has been reduced due to how insanely good AI has gotten.
The other side of this equation is the people who now pump out socks for pennies. You can get what you’re advocating for but it means software development becoming something closer to sweat shops.
Yes, power efficiency may be the largest benefit of these chips actually - especially if the projections are true that the US and other countries simply aren't able to ramp up power generation to meet forecasted datacenter demand.
There's a bit of a ticking time bomb there, something that a Taalas-like architecture can clearly resolve.
Yes this is true to some extent. I've been using LLMs to run some computer vision tests, and I've certainly noticed myself running into the trap of "just one more AI experiment", or "just one more change" while neglecting to actually properly integrate the learnings into my mental model.
However, without an agent running its own experiments on a cloud GPU, would I realistically have invested my limited work hours and tried evaluating 10 different models, each with 10 different tuned parameters, to solve my specific use case?
Or would I have tried 1-2 models and spent my time trying to optimize those models?
I think there is some merit to the spray and pray approach when one is in the exploration phase of the solution space.
Also, on more than one occasion now, I have had fable halve the inference latency of a model simply because the original implementation from an academic included unnecessary GPU-to-CPU-to-GPU transfers or similarly inefficient operations. Those optimizations came at essentially 0 time cost to me and I can verify that the outputs are byte-identical. Pretty sweet!
Does the author not have the experience of working in a legacy codebase that nobody really "understood"? Something sufficiently complex where even the senior SW devs needed to scope out project work and research the codebase for dependencies or potential issues?
I fail to remember a time at LARGE_CORP where even the most experienced developers were able to scope out or design a feature without studying the existing documentation, timing diagrams, etc....
reply