Don't call yourself an artisanal programmer
21 points by yarmak
21 points by yarmak
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
someone please get this person on the world’s most important problems that we can’t afford to get wrong
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.
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.
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.
This would mean you can't be a serious software engineer if you work on projects larger than yourself.
Also, that you can't work on projects 5 years later that you yourself created but have largely forgotten the details of!!
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"?
So, maybe closer to "supervising off-shore project"?
That's exactly the correct analogy and has been for a long time:
With offshore teams you need to form every question in a way that can't be answered with a yes/no option. You need to ask for live demos with input you provide for example. You don't need to review every line of code, you need to give them constraints. "With an input I give, that's based on this spec, the system must return the results in X milliseconds".
The exact same works for AI engineered projects. You define the shape of the output and the AI will color in the shape so to speak.
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.)
& many are temporarily embarrassed corpos so they practice the corpo way aspirationally—even if they can recognize the dangers
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:
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".
Why not just call it "real programming"? AI-free still favors AI by construction (something something Lakoff, probably).
other industries have a name for things that are made by people instead of machines:
hand made
I personally don't like calling something written on a computer hand made, just like a text is not hand written.
Or "manual".
manual is good because it contrasts with "automatic programming" (https://antirez.com/news/159).
I'm not sure this is the right word though: "hand-made" software doesn't shy away from automation tools like compilers, and in practice hardly ever bootstraps the dev environment from scratch. Except perhaps Forth.
Even if we were to bootstrap all the software from scratch like this was a PDP-11, the first order of business would be to automate as much as we possibly can. Assembly instead of machine code, a higher-level language, text editor, multi-task OS... The common thread to this approach isn't that it's made by hand, it's that it is reproducible. Reliable even, once we fix the bugs. Deterministic, mostly. Most importantly, every step of the way we are manipulating a perfectly predictable formal system.
That's what we lose with prompts. The maths. LLMs aren't formal systems. Their behaviour is not only stochastic and unpredictable, it is incomprehensible. No one today can actually look at the weights and have the faintest idea what they mean without actually running them. It's the difference between a text editor and a secretary: the text editor will input exactly what you type, maybe check your spelling and grammar according to precise rules encoded into it. The secretary on the other hand might rephrase your spoken words to something more professional, might add standard pleasantries (dear Sir, regards...) without needing to be asked explicitly, she will even flesh out an entire, polite letter, where you just said "tell them to get lost". She will capture your intent, catch your mistakes, and in some unfortunate rare cases make mistakes of her own. Most importantly though, the words she writes on your behalf will never be yours.
Neither is the code Claude wrote for you. You didn't author it, you asked an opaque entity to do it for you. Even if you coded an LLM engine from scratch, scrapped the web with a tool you wrote yourself, and wasted your life classifying stuff and score outputs... the code it would write for you would not truly be yours.
"Vibecoding" is a misnomer. It gives the impression you kinda sorta coded the thing. But you didn't. You outsourced coding to another entity, then called it your own. Either you're like those CEOs that say (even believe!) they "created jobs" or "built a company", or you know deep down that saying "you vibecoded" something is kind of dishonest. And it eats at you.
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" ?
it is just programming. AI-assisted programming is vibecoding.
AI-assisted programming is vibecoding.
I would go even further and call that "delegating" or something. Vibecoding isn't coding at all, it's asking another entity to code for you.
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. :)
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.
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.
What's with the dig at PVS-Studio? Static analysis tools seem like a "real engineering" thing to me.
I prefer to call AI-assisted programming vibecoding and people that aren't programmers are vibecoders, no need to change what a programmer mean.
I want that 100%. I can only begin to achieve this with deep connection to code, so I refuse to use LLMs, since they isolate me from the low-level details that matter and cannot guarantee correctness by construction.
Didn't want to quote the whole paragraph, but I kinda agree and also disagree with this part.
Ignoring LLMs per se, if you just see it as any other tool (like static analysis) that would give you a review what might be wrong, you still have to decide whether to fix it or if it's a false positive or just a style thing. And then on the other hand I don't see how it makes it worse (we're talking about the output per se, I think, not under the premise LLM=bad), because then you could also argue getting any input from any rando on the internet who gives you a code review also detracts from your 100%?
Also maybe I've been doing this for too long - I'm the last person I'd trust with 100% correctness. Doesn't mean I'm not trying, but I'm under no impression that it works.
Terminology-wise, I’ll use “AI-assisted coding” whenever AI is used and “AI-free software engineering” when doing stuff by hand
I know this ship has sailed, but I really wish we could stop pretending there's any "I" in what is called AI today. I try pretty hard to use the term LLMs when I talk about LLMs, and when people look at me puzzled I explain to them how they aren't actually intelligent. It gets through to some people, but mostly not. I think this goes a long way to explain why many people give up cognitive control when presented with so-called AI - they're told it's intelligent, and it "knows" more than they do, particularly about subjects they can't spot the mistakes in. And everyone perpetuates this by calling it AI.
Could we say "LLM-assisted coding" and "[LLM-free] software engineering?". Maybe it's not even worth trying to have that fight.