[flagged]
What we lost the last time code got cheap
61–70 of 126 posts
Re: What we lost the last time code got cheap
#62Reads at least partially like LLM writing, for example: > When code production gets cheap, the cost doesn't disappear. It migrates. > It was true then. It is unavoidably true now.
Like clockwork, every single thread about something AI-related has someone expressing their disgust at passages of LLM-written text. In many cases by the same people who are enthusiastically embracing LLM-generated software. Why don't we show the same level of contempt for LLM-authored software as we do for even the slightest hint of LLM-authored text in a blog post?
code is not user-facing, functionality, ux, and specs are!
there are many apps with ai-generated ideas, specs, and functionality. nobody uses them because of the contempt.
in either case, the part that's user-facing is ai-resistant
Re: What we lost the last time code got cheap
#63>The cost of producing code has collapsed. AI tools can generate functional, adequate, perfectly average code at a speed and cost that would have been unimaginable even five years ago. And like the outsourcing wave of the early 2000s, the economics are real and rational. Nobody is wrong for using these tools. The code they produce is often fine. It works. It passes tests. It might ship as-is. After using AI for month…
try gpt-5.5-xhigh fast in codex mac app, preferably with TDD and /goal, with a clearly defined end result
it's unbelievable, it will do the iterations for you, it will easily work 12 hours straight until it's a good output
Re: What we lost the last time code got cheap
#64Related (maybe the same thing): Whenever an agent is planning there are often architecture and product choices that it asks humans to make. None of this intent is captured in the code or comments. We started a decisions.md file and updated CLAUDE.md and AGENTS.md to create an entry in the decisions.md file everytime it has to ask a human about what to do. It captures the intent so at least we have doc that describes…
I have a tool for this https://deciduous.dev
Re: What we lost the last time code got cheap
#65Related (maybe the same thing): Whenever an agent is planning there are often architecture and product choices that it asks humans to make. None of this intent is captured in the code or comments. We started a decisions.md file and updated CLAUDE.md and AGENTS.md to create an entry in the decisions.md file everytime it has to ask a human about what to do. It captures the intent so at least we have doc that describes…
(The comment made me start hashing out some early stage thoughts here)
Intent is something that is already sorely missing in most software projects.
At best you might get good commit messages, or messages that link back to good issue/PR discussion.
But something I realize is that /implementation/ intent is also important, not just higher level "why are we here in the first place" intent.
We tend to cargo cult the idea that you shouldn't have to explain what you're changing because it can be derived from the change. e.g. Commit messages should only explain the why since the what is redundant.
But the what is not redundant. Most bugs are a desync from the what, since you obviously didn't mean to implement the bug. And you didn't mean to use UUID v1 instead of UUID v4 for that session token.
Now that my workflow is centered around generating plan files instead of doing the implementation myself, the goal is specifying the plan with enough granularity that anyone could implement the intended change when given the plan.
It's data I wish we always had in a software project, but it would involve way too much work and energy to do this level of planning before every change until the LLM age.
Now that implementation is automated, we live at this specification step. And it's really the specification/plan that I want to see first rather than the code.
I think a great way to approach this to change the PR / code review step to center around revising a markdown plan file until you can get the intent and specification right. That makes a lot more sense than only reviewing the code and the deriving the why and the intended what.
e.g. For my own projects, I'd rather someone submit a plan file as a PR that we can revise together, not code. The code is a derivation of the plan. And when code is derived from a plan, then the plan must contain all of the knowledge that is applied to (or missing from) the code since it's the source of truth.
Compare that to the status quo where you start with a PR code change and then kinda work backwards to synthesize the why and intended what, then see if the real what synchronizes with intention.
Re: What we lost the last time code got cheap
#66Personally I've found one of the biggest gains with coding agents is in helping me read code. Actually - that's a lie. I don't read the code. Mostly (unless my spidey-sense goes off) I ask the LLM to read the code and tell me what it does. And then I make a decision based on that. I guess I'm wondering if the article is missing half the picture. Yes - AI is wrong some of the time (and that % varies based on a host of…
Exactly, and that's why this maxim about "understanding the code base" being the bottleneck is also somewhat misleading.
Claude is even better at helping you understand the code base then it is at writing code! It can look at a bunch of files and give you an accurate run down in ten minutes.
Re: What we lost the last time code got cheap
#67Reads at least partially like LLM writing, for example: > When code production gets cheap, the cost doesn't disappear. It migrates. > It was true then. It is unavoidably true now.
Maybe it's just because I grew up spending way too much time on the internet, but I write like that and have since well before LLMs. As much as people like to attribute that style to AI, I don't think it's the dead giveaway that people act like it is.
You’re absolutely right. And honestly, you’re really on to something.
Re: What we lost the last time code got cheap
#68Reads at least partially like LLM writing, for example: > When code production gets cheap, the cost doesn't disappear. It migrates. > It was true then. It is unavoidably true now.
Like clockwork, every single thread about something AI-related has someone expressing their disgust at passages of LLM-written text. In many cases by the same people who are enthusiastically embracing LLM-generated software. Why don't we show the same level of contempt for LLM-authored software as we do for even the slightest hint of LLM-authored text in a blog post?
We don't like LLMs throwing giant walls of code in PRs at repos and expecting devs to read and respond to all of them.
That's kind of similar to written content being posted and linked. There's an expectation that you are asking someone to take time to read it, and with LLMs now the cost to generate things to be read is a lot lower but our attention and capacity to read them remains the same.
Re: What we lost the last time code got cheap
#69Reads at least partially like LLM writing, for example: > When code production gets cheap, the cost doesn't disappear. It migrates. > It was true then. It is unavoidably true now.
Like clockwork, every single thread about something AI-related has someone expressing their disgust at passages of LLM-written text. In many cases by the same people who are enthusiastically embracing LLM-generated software. Why don't we show the same level of contempt for LLM-authored software as we do for even the slightest hint of LLM-authored text in a blog post?
Code is machinery, writing is communication between humans.
Re: What we lost the last time code got cheap
#70 > The code they [LLMs] produce is often fine. It works. It passes tests. It might ship as-is