I have two issues with this post where I think it goes too far.
"Redefining terms and portraying yourself as the sane side and others as beings not worthy of consideration is a new tactic..." - Agile. Low level. Unit. And likely many more. Names have been subverted for a long time.
The post seems to imply more than once that you should be deeply connected with the code and familiar with it at low level. This would mean you can't be a serious software engineer if you work on projects larger than yourself. There's a threshold where you have to start delegate and co-operate and you cannot realistically understand the whole system in details. Yet I'm sure that there are software engineers working (for example) on creating Windows.
I don't think there are engineers who work "on Windows," only engineers that work on various specific aspects of it, which should be smaller and possible to fit in your head. Delegation kind of proves the point: you delegate to someone else to keep the scope of what you need to understand in detail smaller.
I don't think this is exactly correct. Well, it depends on whether you count a "Principal Staff Engineer" or technical lead of an entire product area (say, Windows) as an engineer. These people will generally not be intimately familiar with every little thing, but we are (arguably) doing ourselves a disservice by claiming that this level of technical ownership over a giant product is not software engineering anymore.
A smaller group of engineers works on the overall system architecture and design. That doesn't mean that the details of what the pieces are doing don't matter - indeed they do, and those concerns belong to someone specific. The point is, if you appropriately control your scope you can understand the thing you work on in depth, and project size shouldn't make that impossible.
There's going to be a mix of people. I'm a senior engineer at my $dayjob, working mostly on cross cutting concerns. I jump on what needs to be done and sometimes need to work with projects I've never seen before, sometimes written in languages I've never used before. Apart from a few smaller things I created, I learn parts of systems only as far as necessary; rarely in deep details. I'd call it JIT familiarity rather than deep familiarity and it doesn't seem to align with what's described in the post. I'm sure similar people exist at Microsoft.
I agree with your points, but I think the second point is an area where things can get bikeshedding-y really quickly when it comes to current day use of "engineering", and software development. Implicit trust has been created over so many years and it's suddenly so different.
So I find it hard to put in words why it's different, but my feeling is that I think vibecoders is much more akin to management(bots instead of persons) than software development.
I think vibecoders is much more akin to management(bots instead of persons) than software development.
I have actually wondered about that, whether the future is "everyone is a manager" but where I think that breaks down is that (thankfully!) my manager does not review PRs or have to constantly check every statement for bald-faced lies. So, maybe closer to "supervising off-shore project"?
This post conflates "AI-assisted programming" with "not understanding the code".
In practice this is true more often than not, but in theory it doesn't check out of imo. You can (for example) write all the code yourself, and then use Fable to perform in-depth correctness checks of every single function on top of everything you've been doing.
If you believe that there's any value to AI, this should give strictly better results.
(Yes, this is a fine line to walk and a slippery slope.)
The point is that "caring about truly understanding the code, and finding the right architecture" doesn't strictly disagree with all AI usage.
The reason why it does in practice is due to incentives, often corporate incentives, which care about shipping more than about correctness (and always have, this is an ancient theme).
(So if you only care about shipping something, you'll inevitably use AI heavily. The other implication doesn't hold, people who strongly care about correctness don't inevitably avoid AI usage. Using AI and caring about correctness are not incompatible. In practice it looks like they are, again, often due to corporate incentives.)
The point is that "caring about truly understanding the code, and finding the right architecture" doesn't strictly disagree with all AI usage.
One of the major ways I use local models is to ask, "So I am trying to do X, Y and Z. Is there any reason this won't work?" When I'm right up against the tightest constraints in a system, this can save me hours of messing around with a dead end. The model typically responds with one of:
"That won't because of..."
"You can make that work, but see page ... in the docs, which seems like it should be unrelated. But it contains the key trick."
"That should actually work the way you hope."
When the code really matters, I don't let the model write very much code. But I'm still happy to use it as a critic and "scout".
It would be better IMHO to emphasize that all choices are made consciously and deliberately. Maybe something like "deliberate programming", "active programming" or "Intentional Programming" ?
I want my programs to be reliable. Patience and care are two important ingredients for this. When designing programs from ground up and taking my time, I just know that they’re correct, and that any mistake is due to a typo. Unit tests, LLM reviews, and provers can guarantee the code is 99% right, but not that it’s 100% right: optimal, maintainable, readable, and that it doesn’t rely or break due to undocumented incompliant behaviors. I want that 100%.
I really appreciate this bold ethos. It's easy to pick at it because of course nothing can really be 100% reliable. But, IMO, having this confidence and being willing to put in understanding and effort is the way we get better software. I think when Andrew Kelley said "we are learning that software quality was maintained only through the will of software engineers" this is the type of person he referenced.
Thanks. I've actually originally meant to write the post about the way I approach software, covering this attitude and bug blindness and the responsibility we bear to keep software running, before realizing I'm digressing and pivoting to this topic. The 100% comment is a relic of that, and I probably wouldn't leave it if I polished the post more, but I'm glad someone understood it properly. :)
I agree with the naming complaint: handing "engineer" to the AI side and keeping "artisanal" for ourselves was a bad trade, and Hillel Wayne's line about us lacking a rich enough vocabulary is the right diagnosis.
Where I part ways: I take great care of code, at work and outside, I dig into whatever I lay eyes on, and I also use AI assistance without reviewing every line. I never reviewed every line of the dozen professional codebases I've worked in either. That doesn't make me a second-class engineer, developer, coder, or whatever the word is this month.
What tires me is the speed. Good, popular, money-making software takes years to settle and earn its name; the labels around AI are being handed out in weeks. The conversation is bipolar, and I don't fit on either pole. Without the hype I'd use these tools more, more openly, and take the time to craft.
For me, it is both the journey and the end. And it's about caring. Andrew Kelly circled it in his black pill talk:
We are learning that software quality was maintained only through the will of software engineers combined with their accidentally strong negotiation position in the job market.
I think for many seasoned SWE's we worked ourselves into positions (parts luck, and parts hard work) where caring mattered. And we've opined voluminously about the legion peers who just don't seem to care. It is fulfilling to care and feel like it matters. I think that's a very human thing. And I think it's been more than just a side effect emotion for a subset of programmers/coders/engineers/analysts/call-them-what-you-will. It has been, too date, and an essential ingredient. It's the "more cowbell" that helped us get where we were today. I can't imagine us having many of the nice things we have in software, if it wasn't for the simple "cared to make the effort" that many have along the way. For a great retro take on where caring can take you, (re)read the Pacific Tech Calculator Story (https://www.pacifict.com/story/)
Prompt coding seems like a thing that changes how we care about software. Some will argue "less", a few "more," many "different". As I watch this all unroll on the stage, that is the ingredient that is being reconsidered and reformulated.
anex9d | 13 hours ago
someone please get this person on the world’s most important problems that we can’t afford to get wrong
tonyarkles | 12 hours ago
“Make no mistakes” :D
purplesyringa | 8 hours ago
If anyone is willing to sponsor my ADHD meds, I'm all ears! :)
Glaeqen | 12 hours ago
I need this on my T-shirt
viraptor | 13 hours ago
I have two issues with this post where I think it goes too far.
"Redefining terms and portraying yourself as the sane side and others as beings not worthy of consideration is a new tactic..." - Agile. Low level. Unit. And likely many more. Names have been subverted for a long time.
The post seems to imply more than once that you should be deeply connected with the code and familiar with it at low level. This would mean you can't be a serious software engineer if you work on projects larger than yourself. There's a threshold where you have to start delegate and co-operate and you cannot realistically understand the whole system in details. Yet I'm sure that there are software engineers working (for example) on creating Windows.
bmo | 11 hours ago
I don't think there are engineers who work "on Windows," only engineers that work on various specific aspects of it, which should be smaller and possible to fit in your head. Delegation kind of proves the point: you delegate to someone else to keep the scope of what you need to understand in detail smaller.
mond | 11 hours ago
I don't think this is exactly correct. Well, it depends on whether you count a "Principal Staff Engineer" or technical lead of an entire product area (say, Windows) as an engineer. These people will generally not be intimately familiar with every little thing, but we are (arguably) doing ourselves a disservice by claiming that this level of technical ownership over a giant product is not software engineering anymore.
bmo | 10 hours ago
A smaller group of engineers works on the overall system architecture and design. That doesn't mean that the details of what the pieces are doing don't matter - indeed they do, and those concerns belong to someone specific. The point is, if you appropriately control your scope you can understand the thing you work on in depth, and project size shouldn't make that impossible.
pmarreck | 8 hours ago
Yes, and I think this is also why Conway's Law is a thing.
The design of the code invariably accretes around the shape of the organization that is creating and must maintain that code.
viraptor | 6 hours ago
There's going to be a mix of people. I'm a senior engineer at my $dayjob, working mostly on cross cutting concerns. I jump on what needs to be done and sometimes need to work with projects I've never seen before, sometimes written in languages I've never used before. Apart from a few smaller things I created, I learn parts of systems only as far as necessary; rarely in deep details. I'd call it JIT familiarity rather than deep familiarity and it doesn't seem to align with what's described in the post. I'm sure similar people exist at Microsoft.
pmarreck | 8 hours ago
Also, that you can't work on projects 5 years later that you yourself created but have largely forgotten the details of!!
zetashift | 12 hours ago
I agree with your points, but I think the second point is an area where things can get bikeshedding-y really quickly when it comes to current day use of "engineering", and software development. Implicit trust has been created over so many years and it's suddenly so different.
So I find it hard to put in words why it's different, but my feeling is that I think vibecoders is much more akin to management(bots instead of persons) than software development.
mdaniel | 11 hours ago
I have actually wondered about that, whether the future is "everyone is a manager" but where I think that breaks down is that (thankfully!) my manager does not review PRs or have to constantly check every statement for bald-faced lies. So, maybe closer to "supervising off-shore project"?
mond | 11 hours ago
This post conflates "AI-assisted programming" with "not understanding the code".
In practice this is true more often than not, but in theory it doesn't check out of imo. You can (for example) write all the code yourself, and then use Fable to perform in-depth correctness checks of every single function on top of everything you've been doing.
If you believe that there's any value to AI, this should give strictly better results.
(Yes, this is a fine line to walk and a slippery slope.)
The point is that "caring about truly understanding the code, and finding the right architecture" doesn't strictly disagree with all AI usage.
The reason why it does in practice is due to incentives, often corporate incentives, which care about shipping more than about correctness (and always have, this is an ancient theme).
(So if you only care about shipping something, you'll inevitably use AI heavily. The other implication doesn't hold, people who strongly care about correctness don't inevitably avoid AI usage. Using AI and caring about correctness are not incompatible. In practice it looks like they are, again, often due to corporate incentives.)
toastal | 8 hours ago
& many are temporarily embarrassed corpos so they practice the corpo way aspirationally—even if they can recognize the dangers
emk | 7 hours ago
One of the major ways I use local models is to ask, "So I am trying to do X, Y and Z. Is there any reason this won't work?" When I'm right up against the tightest constraints in a system, this can save me hours of messing around with a dead end. The model typically responds with one of:
When the code really matters, I don't let the model write very much code. But I'm still happy to use it as a critic and "scout".
mt | 15 hours ago
Why not just call it "real programming"? AI-free still favors AI by construction (something something Lakoff, probably).
jrwren | 14 hours ago
other industries have a name for things that are made by people instead of machines:
hand made
viraptor | 13 hours ago
Or "manual".
lalitm | 13 hours ago
manual is good because it contrasts with "automatic programming" (https://antirez.com/news/159).
Rexxar | 6 hours ago
It would be better IMHO to emphasize that all choices are made consciously and deliberately. Maybe something like "deliberate programming", "active programming" or "Intentional Programming" ?
lumi | 4 hours ago
thoughtful programming? :D
alanmeira | 2 hours ago
it is just programming. AI-assisted programming is vibecoding.
bmo | 11 hours ago
I really appreciate this bold ethos. It's easy to pick at it because of course nothing can really be 100% reliable. But, IMO, having this confidence and being willing to put in understanding and effort is the way we get better software. I think when Andrew Kelley said "we are learning that software quality was maintained only through the will of software engineers" this is the type of person he referenced.
purplesyringa | 8 hours ago
Thanks. I've actually originally meant to write the post about the way I approach software, covering this attitude and bug blindness and the responsibility we bear to keep software running, before realizing I'm digressing and pivoting to this topic. The 100% comment is a relic of that, and I probably wouldn't leave it if I polished the post more, but I'm glad someone understood it properly. :)
amirouche | 9 hours ago
I agree with the naming complaint: handing "engineer" to the AI side and keeping "artisanal" for ourselves was a bad trade, and Hillel Wayne's line about us lacking a rich enough vocabulary is the right diagnosis.
Where I part ways: I take great care of code, at work and outside, I dig into whatever I lay eyes on, and I also use AI assistance without reviewing every line. I never reviewed every line of the dozen professional codebases I've worked in either. That doesn't make me a second-class engineer, developer, coder, or whatever the word is this month. What tires me is the speed. Good, popular, money-making software takes years to settle and earn its name; the labels around AI are being handed out in weeks. The conversation is bipolar, and I don't fit on either pole. Without the hype I'd use these tools more, more openly, and take the time to craft.
Perfection is a limit, not a place.
travisgriggs | 9 hours ago
For me, it is both the journey and the end. And it's about caring. Andrew Kelly circled it in his black pill talk:
I think for many seasoned SWE's we worked ourselves into positions (parts luck, and parts hard work) where caring mattered. And we've opined voluminously about the legion peers who just don't seem to care. It is fulfilling to care and feel like it matters. I think that's a very human thing. And I think it's been more than just a side effect emotion for a subset of programmers/coders/engineers/analysts/call-them-what-you-will. It has been, too date, and an essential ingredient. It's the "more cowbell" that helped us get where we were today. I can't imagine us having many of the nice things we have in software, if it wasn't for the simple "cared to make the effort" that many have along the way. For a great retro take on where caring can take you, (re)read the Pacific Tech Calculator Story (https://www.pacifict.com/story/)
Prompt coding seems like a thing that changes how we care about software. Some will argue "less", a few "more," many "different". As I watch this all unroll on the stage, that is the ingredient that is being reconsidered and reformulated.
pmarreck | 8 hours ago
It's "artisanal/bespoke tradcoder" ;)
gulbanana | 3 hours ago
What's with the dig at PVS-Studio? Static analysis tools seem like a "real engineering" thing to me.
alanmeira | 2 hours ago
I prefer to call AI-assisted programming vibecoding and people that aren't programmers are vibecoders, no need to change what a programmer mean.