doug_durham
3 hours ago
This seems to romanticize the past. I've been doing this for 40 years and I don't see that much has changed. I would code even if I didn't get paid for it. That said I've always seen writing code as a means to an end. I use GenAI every day to write code, and it brings pure joy when there's boiler plate that I don't need to write so I can focus on the fun stuff. There is zero value in me writing yet another Python argparse routine. I've done it and I've learn everything I'm ever going to learn about it. Let me get on to the stuff that I don't know how to do.
spockz
2 hours ago
Okay I get the desire of not wanting to do repetitive stuff. It appears doing this with an llm scratches your itch. Before the same - focusing on the intrinsic complexity instead of the accidental - could be achieved by using libraries, toolkits, frameworks, better compiler (plugins), or “better” languages.
What plagues me about LLMs is that all that generated code is still around in the project making reviews harder as well s understanding the whole program source. What is in there that makes you prefer this mechanism instead of the abstractions that have been increasingly available since forever?
seer
an hour ago
Isn't this compiled languages vs writing pure machine code argument all over again?
The compiler produces a metric shit ton of code that I don't see when I'm writing C++ code. And don't get me started on TypeScript/Clojure - the amount of code that gets written underneath is mindbogglingly staggering, yet I don't see it, for me the code is "clean".
And I'm old enough to remember the tail end of the MachineCode -> CompiledCode transition, and have certainly lived through CompiledCode -> InterpretedCode -> TranspiledCode ones.
There were certainly people who knew the ins and outs of the underlying technology who produced some stunningly fast and beautiful code, but the march of progress was inevitable and they were gradually driven to obscurity.
This recent LLM step just feels like more of the same. *I* know how to write an optimized routine that the LLM will stumble to do cleanly, but back in the day lots of assembler wizards were doing some crazy stuff, stuff that I admired but didn't have the time to replicate.
I imagine in the next 10-20 years we will have Devs that _only_ know English, are trained in classical logic and have flame wars about what code exactly would their tools generate given various sentence invocations. And people would benchmark and investigate the way we currently do about JIT compilation and CPU caching - very few know how it actually works but the rest don't have to, as long as the machine produces the results we want.
Just one more step on the abstraction ladder.
The "Mars" trilogy by Kim Stanley Robinson had very cool extrapolations where this all could lead, technologically, politically, social and morally. LLMs didn't exists when he was writing it, but he predicted it anyway.
hinkley
2 hours ago
I've seen a lot change. I used to have a seemingly bottomless list of things we are doing wrong and about half of them have dropped off in the last twenty years. Did they all turn out as well as we hoped they would? No. I don't think a single one did. We are half-assing a lot of things that we used to laugh off entirely. In most of these cases some is better than none, but could be a lot better.
What I worry about is that my list has gotten shorter not because everything is as it should be but because I have slowed down.
Quite a lot of things on that list were of the "The future is here but it's not evenly distributed" sort. XP was about a bunch of relatively simple actions that were force multipliers with a small multiple on them. What was important was that they composed. So the benefit of doing eight of them was more than twice the benefit of doing four. Which means there's a lot of headroom still from adding a few more things.
mattikl
an hour ago
That's certainly a more positive way to look at this. Working software has always relied on having people who grok the code, and this happens by spending a lot of time thinking about the code while writing it. And it's undocumented, because the nature of it is something you cannot really document.
If AI is writing all the code, how do we keep the quality good? It's so obvious with the current GenAI tools that they're getting great at producing code, but they don't really understand the code.
We don't really know how this story unfolds, so it's good to keep a positive mindset.
imiric
an hour ago
Code generation tools of today are pretty good at writing the boring boilerplate. I think the author is aware of this.
But what happens when they get really good at generating the not-so-boring bits? They're much better at this than they were a year or two ago, so it's not unthinkable that they will continue to improve.
I'm a firm "AI" skeptic, and don't buy into the hype. It's clear that the brute force approach of throwing more data and compute at the problem has reached diminishing returns. And yet there is ample room for improvements by doing good engineering alone. Most of what we've seen in the past year is based on this: MCP, agents, "skills", etc.
> I would code even if I didn't get paid for it.
That's great, but once the market value of your work diminishes, it's no longer a career—it's a hobby. Which doesn't mean there won't be demand for artisanal programming, but it won't power the world anymore. It will be a niche skill we rely on for very specific tasks, but our jobs will be relegated to steer and assist the "AI" into producing reliable software. At least in the short-term. It's doubtful whether the current path will get us to a place where these tools are fully self-sufficient.
This is the bleak present and future the article is talking about. Being an assistant to code generation tools is far removed from the practice of programming. I personally find it tedious, unengaging, and extremely boring. There's little joy in the experience beyond having a working product. The road to get there is not a journey of discovery, serendipity, learning, and dopamine hits. It is a slog of writing software specs, balancing contextual information and prompts, and coaxing a human facsimile using natural language into producing working software. I dislike every part of this process.