41–50 of 82 posts
Earlier quoted context omitted.
This is a running production service. The team was reduced to just these 2, per the lead's instuction. The closest I can explain this phenomenon to thos who are surpised was by the LLM variance section in this recent blog post: https://danluu.com/ai-coding/#llm-variance
It could be that the team was oversized and wasting time in meetings and AI has nothing to do with that.
"There's plenty of space for "disposable and single use software." Sure, to a trained software engineer, this might be "bad code" but doing today's task has value, even if the code that performs that task isn't "accretive."" Grant me the serenity to accept the bad code i shouldn't fix, the courage to change the code I can, and the wisdom to know the difference.
> Grant me the serenity to accept the bad code i shouldn't fix, the courage to change the code I can, and the wisdom to know the difference. Well, It's really early in the morning and I've got the quote of the day already
I think this kind of work is constantly misunderstood and undervalued. I don't really see it as a binary thing, more like a complex skill that most people are terrible at, some are good at, and a handful of giants use to be just ridiculously productive in their field.
It reminds me of hedgehogs and foxes - foxes tend to be bad at making one off progress on their own, but are critical for accretive work.
Also I was reading a textbook the other day and thinking wow, it is absurd how much more valuable these things can be than other resources, and it's exactly because they canonize. It would be a massive loss if they stop getting written.
Isn’t this a question of how much the “terrorised survivors” spend on tokens to make the output “canonised”? I think the main argument that the billions spent are not going to be recouped is accurate, but I strongly suspect the cost of producing high quality code will remain the same -just being produced faster (speed, cost, quality - you still only get to pick two) If one Steve Yegge can burn tokens in “Gas Town” th…
I suspect "same price, three days instead of three months" is a very real win for plenty of businesses
- on the one hand, time-to-market is super important. Getting to the right place faster is obviously better.
- on the other hand, figuring out right product/right fit is hard, and if a business spends that much cost every 3 days chasing every idea (most of which may be bad ideas), they’ve probably wasted a lot of money.
Obviously token costs are cheaper than developers, and local models would reduce costs still further. But the thought I keep coming to is: maybe there’s a benefit to slowing down and not jumping to implement?
I usually hear the opposite side (better to implement 10 things and throw out 9 of them, easier to react to prototypes, etc.). But I also think the infinity of possible ideas doesn’t get smaller when you throw more engineers or compute at it. You just end up exploring more, possibly bad ideas. This works out if exploring more of the space builds a greater understanding of the problem and increases the likelihood that one of your choices pans out. But the cost of exploring the space isn’t $0 and 0 time.
Earlier quoted context omitted.
> Grant me the serenity to accept the bad code i shouldn't fix, the courage to change the code I can, and the wisdom to know the difference. Well, It's really early in the morning and I've got the quote of the day already
This is a slightly modified version of the serenity prayer of AA fame.
Most of the time he comes off as an objective thinker, but those are really discounted by moments where his own dogma leads him down a path of making weakly supported points that seem like they come more from a place of anger.
Earlier quoted context omitted.
This is a slightly modified version of the serenity prayer of AA fame.
Yes, I know, but I substituted that one in daily usage for just shouting "SERENITY NOW" at maximum volume.
Isn’t this a question of how much the “terrorised survivors” spend on tokens to make the output “canonised”? I think the main argument that the billions spent are not going to be recouped is accurate, but I strongly suspect the cost of producing high quality code will remain the same -just being produced faster (speed, cost, quality - you still only get to pick two) If one Steve Yegge can burn tokens in “Gas Town” th…
I suspect "same price, three days instead of three months" is a very real win for plenty of businesses
Centaur + no Canonization -> personal infrastructure, MVPs. probably ever-accruing tech debt, but the scale is limited so it probably doesn't matter
Centaur + Canonization -> libre software, companies with empowered employees. The Canonization process is going to have some differences now that the goal now includes consumption by an LLM.
Reverse Centaur + no Canonization -> Ever accruing tech debt, eventually leading to a situation where nobody understands how the "magic box" works and everyone is powerless to fix it when it breaks down (tech debt accrues to a level where an LLM can no longer achieve the desired results)
Reverse Centaur + Canonization -> It's certainly possible to have an automated process that distills and compresses knowledge at one stage into a succinct representation that can be used down the line. The open question is whether a company could arrive at this with disempowered reverse centaurs, or whether they're doomed to the previous option
Enumerating those 4 quadrants, I don't think I'm even doing a good job capturing where I had thought the article was going to go. But I'm having a hard time getting it back now.
"There's plenty of space for "disposable and single use software." Sure, to a trained software engineer, this might be "bad code" but doing today's task has value, even if the code that performs that task isn't "accretive."" Grant me the serenity to accept the bad code i shouldn't fix, the courage to change the code I can, and the wisdom to know the difference.
The real trick is recognizing when "disposable" code has quietly become infrastructure
I found an excellent way to avoid premature abstraction and optimization and to write better software in general was to explicitly consider v1.x a throw-away.
Build something expedient that works well enough to deploy in the field, get actual user feedback and system metrics (e.g., where are the actual bottlenecks). Do a few iterations on user feedback and system metrics. NOW, you are much further down the road to a true final spec, and you can use that real information to design the real system to scale up on.
One Test Is Worth A Thousand Opinions.
This plan first tests your ideas against the real world of users, hardware, and data flows, and keeps a lot of technical debt out of the scaling system.
I discovered it a bit by accident, having previously been really big on early abstraction and planning, but sort of having to do this in one startup, and it was a real eye-opener how well it worked.