> models write much better code than humans can
What? I think this is either over exaggerating model capabilities or you haven't seen much good code from humans?
My experience is that my colleagues which have bought into model-first development have regressed in quality of the PRs they send out. LLMs are not better coders, in my experience. They lack holistic understanding and often need course correction for that reason. At least in medium to highly complicated systems.
Over my time in the industry I've become increasingly convinced most people haven't seen what good human programmers are like. Otherwise we wouldn't have the popularity of things like Scrum, Clean Code (the book, not the concept), etc.
I was lucky enough to see some good teams when I was a student (both at Berkeley itself and by interning at Jane Street), and it totally changed my intuition for what good programming is like. It's gotten to the point where I'm convinced there are two incommensurable paradigms in programming, and we're constantly talking past each other.
Like, if you have an ongoing project where the codebase has grown over time, do you expect it to get easier to do things or harder? I've worked on projects where it's obvious that things are always getting harder (old code is hard to change, you have to deal with lots of complexity and edge cases and workarounds). I've also worked in codebases where things got easier over time: you get better abstractions, more libraries, more capabilities. That can be a lot of fun; you think of a new thing to try, and you have the pieces to just do it.
Or another point of comparison: do people think that writing good code slows you down (so it only makes sense to avoid bugs), or do people think that writing good code lets you move faster? I've talked to people for whom one or the other is totally and obviously true. (I'm solidly in the second camp myself.)
But the surprising thing was how "obvious" the dynamic was in both cases, even though the two cases are exact opposites of each other! If you ask one group or the other they'd just tell you that, well, that's simply how programming works. Of course things get (easier|harder) over time. That's built into people's fundamental understanding of what programming is and how to do it. And that's exactly what I mean by incommensurable paradigms.
Anyway, this is a bit of a tangent from the main discussion, but it's something I've been thinking about a bunch over the last few years, partly inspired by the advent of AI-powered programming, but largely thanks to experiencing some very different projects and teams...
I think you can get to "easier" if you have the a) budget to hire the people that are good enough and b) the time and discipline to create the abstractions so it gets easier over time.
Most shops will not have that kind of time and money, so the default will be "harder". Also, to be fair, most shops will not be led by individuals that understand why ensuring things get easier / faster is important in the short term, so that also complicates things a bit.
> Clean Code (the book, not the concept), etc.
Thank you for drawing the distinction. I've noticed that while ~80% of Uncle Bob's ideas are good, he doesn't seem to have been very good at implementing them, and he often does so in ways that contradict other principles. Much the same with Fowler and other names from that era/community.
> But the surprising thing was how "obvious" the dynamic was in both cases, even though the two cases are exact opposites of each other! If you ask one group or the other they'd just tell you that, well, that's simply how programming works. Of course things get (easier|harder) over time. That's built into people's fundamental understanding of what programming is and how to do it. And that's exactly what I mean by incommensurable paradigms.
Although I mostly see it get harder over time, it certainly feels like it's supposed to get easier.
That's an interesting point, and maybe that actually also explains the difference of people that believe that AI is making them more productive and people that believe it doesn't; if you never think about the architecture, then it becomes more slop over time, and it becomes harder to do anything. If you do think about architecture, development becomes easier and faster all the time. AI just accelerates both processes.
I’ve seen both side of the fence and if there’s one quality that seems to define that fence, it’s caring about the process. Both sides wants to archieve the same goal, but one care about the process (enough to make it less tedious) and the other don’t (whatever seems to work is Ok).
That’s why they say the best programmers are lazy. Not in the sense of avoiding any kind of work, but avoiding the kind of senseless stuff that’s surely to come down the line if you’ve not taken care of the process
Fair enough; I'm talking about relatively "small" snippets, that with reasoning algorithms, can quickly give you a better result than you would get if you let a mediocre or even senior developer would give an hour.
Managing a complete codebase, making architectural decisions, designing business logic; that is not something you should let your agent do.
But I see that as a different task from "coding".