0.0 Context Setting

Monday, 24 August 2026, in Portland, Oregon. I had the idea for this yesterday, maybe? And then started writing it up, and finished it today.

0.1 Events: How People Work

Next up:

• How People Work, Live! ... with Margo Stern, on Friday 28 August, 9am Pacific

Margo Stern, the author of Good Work: Managing Yourself and Managing Managing, a two-sided book that shares all the tips, tricks, hacks and cheat codes to working in tech. Drawing not only on her experience managing and being an IC at places like Google, Twitter, and Lyft, she shares the wisdom from interviews with PMs, Designers and Engineers who have been there too. Margo is also a Staff Content Designer at Lyft, and she lives in San Francisco, CA.

... and continuing the weekly clinic, you can register for How People Work... Does Happy Hour! this Tuesday 25 August at 1pm Pacific. Only one place out of ten registered so far, so let’s get a few more people in, yeah?

If I’ve done things right, you can now listen to How People Work, Live! as a podcast. It’s not in the Apple Podcasts directory yet, but it should turn up there soon. In the meantime if you’re also a background video person, there’s always the YouTube channel. (Sigh: smash like, smash subscribe, all those things. I am also trying to figure out whether/how I can snip these things into vertical video, too.)

If you’re enjoying the show, remember that it’s actually based on my workshop! You can read more about it there, and get in touch with me by email, or book some time to have a short meet-and-greet about it. Mention the show and you’ll get a discount, too.

---

1.0 Some Things That Caught My Attention

1.1 It’s all vibes, until it’s not

You know a long time ago there was a thing that came out that let non-programmers make software. And it let them make terrible software. Really bad. The UI was bad. The data model underlying everything was probably bad. I have absolutely no citations here, but just trust me: it let you make bad software.

It also let you make bad software that worked. It would also, honestly, let you make good software, it’s just that it was easy for you to make software period.

You didn’t really have to learn very much programming, comparatively, to make the software either: a lot of it was about just dragging stuff around and then plooping it down and wiring it up.

I am, of course, talking about Visual Basic¹. (Apparently, we call it Visual Basic classic, now)

Could the software that people made with Visual Basic be better? It probably could. Was it easy to write buggy software? Probably! Did it have problems with version control? Definitely! Did it make it easy to write secure software? Probably not, but this was the 90s. You didn’t have to write secure software then because nothing was connected to anything and hardly anyone used computers back then anyway².

But this probably buggy, probably difficult to use software was still often better than the alternative: which was no software at all.

There’s this thing these days called vibe-coding, and... the thing is, it’s not a helpful term anymore. The problem is in the word vibe.

Vibes are... careless in that the way that they are not thoughtful. They can be slapdash, they can be throwaway. They are clearly not serious. So of course vibe-coding is bad. It is unserious, it is not proper, it is playing, it is toylike, it is playing, it is lazy: all of that stuff.

But that’s just one way of describing a process of interacting with a sort-of-computer program that in the end, generates code. And I get it, agentic coding isn’t necessarily reproducible. It can be highly variable output. But it is a process that generates code, and we can assume (or at least I believe we have evidence, but I personally haven’t checked) that while yes if you put garbage (vibes) in then you get garbage (vibes) code out, if you put in slightly less garbage then maybe, just maybe, you get slightly less garbage out. (Especially, I think, if you actually run that garbage through some tests and then go in a loop a few times)

Back when vision language models were all the new hotness, we had a period where prompt engineers were also the new hotness. People who’d discovered that if you added the words “hdr” or “bokeh” or “50mm 1.2” you got “better” imagery from your visual model. You’d end up with what would read like kind of funny nonsensical strings, like:

“high quality studio lit portrait 50mm 1.2f bokeh vogue magazine cover professional photographer”

and you know what? That looks like babbling³. I used to be really into linguistics and as part of that did a dissertation-ish thing on child language acquisition. It looks like experimenting with making sounds with language and seeing what happens in response to those sounds.

People are “getting better” at prompting as large language models are evolving and their capabilities are being explored.

I wrote before about how distressing it can feel, in some sense, when you can get a large language model to generate a new proof or disproof of a theorem just by telling it to try harder or “do a breakthrough”. I mean, honestly! “Do a breakthrough!” And yet, one was generated.

So sure. There is a sloppy, vibe-y way of instructing a program to generate code. The program that’s being instructed relies on a bunch of sophisticated statistics, sure. But I do think that there’s a less sloppy, vibe-y way of instructing that program. Which is why I think it’s important to accept that vibe-coding, whatever you want to call it, is just one end of a continuum. On that one end you have the vibing. On the other you have... not that. You have formal specs. You have more structure. You have tests. You have a system of approval that sure, may also be administered by other large language models, but nonetheless is a system.

You know what else feels like vibe-coding?

Vibe home improvement. I mean, anyone can do vibe home improvement or vibe DIY. You just get one of those tools you can buy and start hitting things. You can do really dangerous things. You can start doing things that are genuinely useful but also might, like, kill someone? You can do stuff with water and electricity and I don’t know structural engineering that can start off pretty cheap but then end up pretty expensive.

You could also do home improvement properly. You could read lots of guides, you could take classes, you can learn how to plan and draw diagrams. You could do all of that, or you could I don’t know just get a bunch of liquid nails and go nuts.

If you’ve ever brought a house -- and I know I’ve written about this before -- then I’m pretty sure that you’ve encountered the physical equivalent of vibe coding. The previous owner(s) will have embarked on projects and maybe finished them or maybe not because they ended up being “good enough”. There may be two-way or three-way switches to control lights that... kind of work? You may have looked at the electrical panel and then realized that none of the labels on it are a) accurate or b) helpful, and then considered: one day, one day I will turn everything off and then plug in a thing to each single thing and then I will document it. And then chances are you won’t do that.

So. You are already surrounded by vibe implementations.

Thing is, more people interact with vibe DIY than vibe software (for now!) and people in general don’t like it when they are injured or killed or otherwise, or when they spend hundreds of thousands of local currency in buying something and then have it fall over, or onto, or collapse, or so on.

Which is also why we end up with things like building codes and insurance and bonded contractors and general contractors and inspections and so on. Not that that really changes much, in a sense, because sure you can buy a house and then you do an inspection and the inspection shows that most of the house was built on a memory unsafe language and never ever had even the most elementary fuzzing done on it so now you need to, like, have a security audit and who’s going to pay for that, hmm? The owner might not want to get that asbestos abatement done so in the end it’s just down to who’s going to blink first. Do they need it sold, or do you need to buy it? As with The Other Thing, we’ve established that all we’re doing now is haggling over price. So maybe you take the hit and you say sure, I know about the asbestos now or I know about the fact that you’re using some libraries that are several major versions out of date, but hey I don’t care. Or maybe it’s the other way around and you’re the seller and you really don’t want to know about the results of that inspection because now you’re on notice and before you know it someone is insisting you need to rewrite your entire house in rust.

But we do have building codes and then we do have inspectors. And then you can still end up with buying a house where there’s a “bedroom” but it’s not technically a “bedroom” because the egress isn’t quite large enough, but sure we can use it as a bedroom. Just like how that spreadsheet is actually a database but it’s a spreadsheet, you know?

So I guess we could have code and inspections for software. Sure, we could do that. The amount of software out there significantly exceeds our ability to inspect it though, doesn’t it? I mean, no? It doesn’t? The whole point of this newsletter occasionally is to say: well we could, if we decided it was important enough. If we really wanted to, we could figure out a way. We could mandate testing. We could mandate scanning binaries. We could--

hang on, isn’t that what certain app stores do? Isn’t that what they try to do, implement some sort of standard and then say you’re not allowed to distribute software that might be harmful because it might crash or otherwise or be a security risk?

But at the same time we don’t like those stores because they restrict freedom. (That’s actually a specious argument: what we don’t like is that those stores are the only option for distributing software on those platforms. But, the platform owners counter: those platforms are valuable because there’s only one way to distribute software on them, and because they’re administering some sort of rules and standards for the first goddamn time).

Wait, they restrict freedom? See, I think the deal with software engineers is that they like to be able to vibe code. They like to be able to do things unseriously, without limit, to play, to create things quickly and sloppily that sure they’re dangerous, but if there were better ways to create less dangerous software but also as quickly, then that would be okay? The vibe-ness is just one aspect, it’s in the carefree nature, it’s in, well, the hacking and the 60s counter-culture, isn’t it? Software wants to be free. Software -- perversely, because it only works because of rules -- doesn’t want to follow rules. Or rather the entire human culture of software so far doesn’t want to follow rules.

It used to, though. It used to, I think, when computing was gendered, when it was a thing women did, when calculating was something else, when Real Men [sic] made software that would land someone on the goddamn moon using the computing equivalent of a few pieces of string wound around a cylinder, written while giving birth. Vibe coding -- that end of it -- that is not necessarily the maintenance end of things, it is not the long-term care of things, it is the throw-something-out of things, but we would do better, I think to confuse the nature of the operation of the tool with the capabilities of the tool. Be careless with the tool and sure, generate careless code. That does not mean the tool can only generate careless code. (There can be other problems with the code that’s generated, I agree and will admit to).

There is something funny here, too. That the closer and closer to a spec you get, the closer to some sort of agreed-upon shared language and grammar the closer you get to, what, actually writing code? A lot of this stuff can read like pseudo-code anyway. Is there some weird part of this entire journey where what’s happening can be likened more to style-transfer, where you take a photo and say “make this look like a professional photographer I looked up on Wikipedia took it”, but you’re doing it with code? Isn’t that what porting is, anyway?

All of this applies only to code, of course. Not to language, not to writing. And I think it’s easier to think of what these programs are doing as generation, not as writing, if you want to split that (useful, I think) hair. Words and sentences are being generated, but writing is not happening, and sure that can be species chauvinism if you want. The code compiles. The code has to be run through something else and in the end, at the very end, it either runs or it doesn’t. And before that, there are tests that can be passed or failed. That’s not writing, that’s maths.

There are people who are going to want to use these things sloppily and to create code based on vibes and it will be sloppy and it will be vibe-like and it will be bad, and all of those things and yes, yes, yes: I know. Every single line of this code was built on stolen data, and is created in datacenters that are being built without community consultation (or even without communities being informed, in secret), perpetuating racism.

I suppose in a way my point is this: yes, agentic coding is a tool, and yes, you can used the tired analogy that it is a tool that can be dangerous and can maim and so on, and that it’s a tool that deserves the proper respect. One way of thinking about this is that the tool doesn’t live in isolation, that it can be surrounded by an infrastructure and ecosystem that can help what’s generated by the tool be safer.

What’s perhaps more interesting about this whole generative AI thing in the context of code is that it doesn’t just have to generate code. It can generate the tests as well. Sometimes generating the tests is part of the whole “harness” that involves generating the code in the first place, and yes, in some ways people will treat this as letting the idiot villager not only make the thing, but the idiot villager be in charge of checking whether the thing works.

An aside: the distressing un-computer-like thing about how these things work that also makes total sense is that if you instruct them to “do it again check” then the program will “do it again and check”. Yes there is the risk that the check will miss something (or may even fabulate something!), but again, that’s what you’d ask a human to do anyway. It’s un-computer-like because our whole experience of computers is that they’re supposed to get things right the first time and that they’re supposed to be (or are marketed to be) infallible.

It would be folly to assume that everyone using LLMs to write code is an idiot. It would also be fair to assume that -- given history -- certain kinds of technologists tend to get overexcited about tools and don’t think about secondary implications. I think it’s also reasonable to expect that we have the capacity to learn from history, and I really am the kind of optimist who believes in that. The code that’s being generated by these agents is more likely to be written in safer languages. The code that’s generated by these agents is more likely to be accessible in ways that previous code has not been. It is also a human trait to want things to go faster than they are going (if only, in one respect because marketing promises things it often, or by design, can’t deliver).

A genuine worry here that I share with my friend Laura James is that we have the potential to widen access but that in our current economic and regulatory environment, the signs aren’t good. At some point free will become subscription, and at some point cheap subscriptions will get more expensive and a moat will be dug or a drawbridge will be raised. We still don’t know how much this stuff costs to run, but perhaps we are in a race to discover how much is possible to do on local models running, in a few years at least, on a three-year-old phone.

I suppose I will go back to my original point and realization. More people have always wanted to do things with computers than have the ability to do things with computers. I admit that that’s not everyone -- you need to be able to think in a certain way, and the promise of the learn-to-code camps was that it might encourage or introduce people to thinking algorithmically. Yes there are fewer spreadsheet people than there are non-spreadsheet people, but I would like to believe that people are able to think in terms of instructions and “kinds of data”, and that as much of this is an accessibility issue. (In that way it is both funny and tragic that the method of generating code, ish, is still through a text user interface, although prompting in a chat window and an artifact appearing is a progression, I think).

Computers are capable of so much more, and it’s so irritating that you have to learn syntax and packages and ecosystems and so on. You’d think it would be easier by now, and sure, we have things like Apple Shortcuts, great.

But again, my original point. Vibe coding can be thought of as the irrepressible urge to do home improvement and DIY, a human want to improve your environment and to create tools and affordances. There are other ways to use the same tools to do the same thing in safer ways. It does us a disservice to lump the entire usage of the tool into the careless and carefree end of a spectrum.

---

That’s it! I thought I could do this in fewer words, but apparently not.

How are you doing?

Best,

Dan