311–320 of 401 posts
Completing each individual programming task is easy. Engineering the system in a sustainable way that changes can be traced, understood and reasoned about is difficult.
The problem is, as many other comments have pointed out, typically the business doesn't value this.
> Craftsmanship will always be in our hands, it's one thing we can never outsource to a machine. I'm right there with you, but this last sentence concerned me a bit. In my most other "industries", craftsmanship is not _dead_, but it's been pushed to the wayside for (significantly) cheaper and more available alternatives. You can still get hand-made leather shoes, but very few want to pay $1000+ for them. You can stil…
Thought experiment: would a junior developer armed with a modern day gpt-5.5 or opus 4.8 in 2015 would have been considered a 10x developer (assuming nobody knew they were using AI)?
> considered a 10x developer
We need to stop exaggerating so much. A 2x dev would be insane! A 1.5x dev does a year's work in 8. A 1.1x dev does it in 11. Saving a whole month itself is a massive amount of money saving. Our "10x" devs are really 1.1x and I'm not sure why we see that as anything less than wildly impressive.
Can we stop exaggerating so much?
Earlier quoted context omitted.
I think an important caveat is that LLMs are prone to writing unnecessary code, i.e. there's almost a superfluity to it, that at the same time makes it less straightforward and more prone to unnecessary side effects, which it does catch and handle, but that again expands code further.
Then you add an agent that goes through the code and simplifies it. Before every sprint, you get the agent to simplify whatever it can without losing fidelity. It's really that simple.
> Then you add an agent that goes through the code and simplifies it
Can you? I just asked Opus to generate a sum function.
def sum(a, b):
return a + b
add = lambda a, b: a + b
If you ask it to simplify something, it will make changes whether it needs to or not. Now imagine we were working with a function that is a couple hundred lines. What changes would it make?
The reason something superfluous was written to begin with is because an LLM does not always know what is superfluous. Producing and reading is really cheap for the LLM, so it doesn't have the same considerations we do in writing code. It's more willing to reinvent the wheel or write something that is way more verbose than it needs to be.
In practice, asking an LLM to simplify it just means it adds a different superfluous thing. Or it refactors things that didn't need to be refactored (because it can do it quickly). The result is LLM code, even if it's good, tends to bloat a bit. Multiply that across 100 people all vibe coding and not reading the code base, and soon you have an unreadable mess.
> Half the code was written in a language you didn't understand. The other half was written using libraries you never heard of. The author already describes himself as "not a rockstar developer", but if this is the definition of "rockstar" I need to recalibrate. Being able to learn new languages and libraries, to me, is completely normal. (Also: how funny is it to suggest rewriting code you self-admit you can't even…
Earlier quoted context omitted.
Believing in that system so much to say something like that might be worse. Noting against the OP, that kind of Stockholm Syndrome can be found in my past as well.
Not sure I understand. Is your contention that the distinction between senior and non-senior engineers is fake and everyone's doing basically the same thing? Or are you just objecting to the (arbitrary) names Microsoft uses for them?
> Craftsmanship will always be in our hands, it's one thing we can never outsource to a machine. I'm right there with you, but this last sentence concerned me a bit. In my most other "industries", craftsmanship is not _dead_, but it's been pushed to the wayside for (significantly) cheaper and more available alternatives. You can still get hand-made leather shoes, but very few want to pay $1000+ for them. You can stil…
Yeah, even though I like 'craftsmanship' here, stakeholders don't. I think "durability" is pretty good. 'Engineering standards' perhaps. I think we'll start to see the groundwork laid for software engineering as a proper engineering field, where specific performance characteristics are required for certain stakes. Code can be like "heavy machinery", maybe needs license to operate. If an app has sensitive data in it,…
> stakeholders don't
[0] It's not incredibly, it's monopolies
> Craftsmanship will always be in our hands, it's one thing we can never outsource to a machine. I'm right there with you, but this last sentence concerned me a bit. In my most other "industries", craftsmanship is not _dead_, but it's been pushed to the wayside for (significantly) cheaper and more available alternatives. You can still get hand-made leather shoes, but very few want to pay $1000+ for them. You can stil…
A screw used to be a bespoke and precious object. It took a ton of time and effort to make a good screw. What we would today consider a 'machine screw' could only be made by extreme labor from someone very, very skiled.
But the thing about machines is that a machine can transfer craftsmanship. You can make a single really, really good screw and then a machine can transfer the quality of that screw into countless new screws.
In the modern era, screws of all types and qualities are more or less equally disposable. We produce in the billions today screws that would take days or weeks to cut by hand.
I sort of view AI the same way I'd look at a lathe without a leadscrew. You have to make your own screw by hand the first time, and then you can transfer whatever quality you can muster to any number of new screws. If you get better at making new screws, you can load that into the lathe and start making more and better screws. But you are fundamentally limited by the quality of screw you can make yourself. If all you can manage is a crooked lumpy mess, then that's all you'll be able to get out of the machine.
Earlier quoted context omitted.
Thought experiment: would a junior developer armed with a modern day gpt-5.5 or opus 4.8 in 2015 would have been considered a 10x developer (assuming nobody knew they were using AI)?
> considered a 10x developer The 10x developer never existed. You're telling me these people are doing a year's worth of work in 1.2 months? Seriously?! 10x?! In a year you can probably learn to program from scratch and participle if you're working 8hrs per day 5 days a week We need to stop exaggerating so much. A 2x dev would be insane! A 1.5x dev does a year's work in 8. A 1.1x dev does it in 11. Saving a whole mon…
Even assuming that maybe the average developer could come to learn how to solve the problem you can easily see the gap between taking months to learn how to solve a problem versus already knowing how to solve it on short notice being over 10x.
Large productivity differences are mostly a function of differences in capability than differences of speed in solving rote problems easily within their capabilitys.
I've met a handful of people across my life that i'd call truly brilliant. Like, holy heck how in the world is this person this smart? Two things I've noted about really smart people are (usually mutually exclusively) 1) Sometimes they do not realize how smart they are, because it's simple to them, or because they know the subject they assume everyone else, say with a computer science degree, knows and recalls and un…
I would say there are two explanations for group 2. The first is that you aren't as smart as you think you are, because if you actually understood the people around you in any real way, you would instantly find them less frustrating. But instead you are using flawed heuristics, built out of your own insecurities, to interact with the world. Possibility two is that you are smart, but you have developed a malformed cop…