Really enjoyed this post.<p>> Putting aside existential risks, I don't see a future where a lot of jobs don't cease to exist.<p>I'm personally betting on the plateau effect with LLMs. There are two plateaus I see coming that will require humans to fix no matter what we do:<p>1. The LLMs themselves plateau. We're already seeing new models get worse, not better at writing code (e.g., Sonnet 3.5 seems to be better than 3.7 at coding). This could be a temporary fluke, or, an inherent reality of how LLMs work (where I tend to land).<p>2. Humans will plateau. First, humans themselves will see their skills atrophy as they defer more and more to AI than struggling to solve problems (and by extension, learn new things). Second, humans will be disincentivized to create new forms of programming <i>and</i> write about them, so eventually the inputs to the LLM become stale.<p>Short-term, this won't appear to be true, but long-term (on the author's 10+ year scale), it will be frightening. Doubly so when systems that were primarily or entirely "vibe coded" start to break in ways that the few remaining humans responsible for maintaining them don't understand (and can't prompt their way out of).<p>And that's where I think the future work will be: in fixing or replacing systems unintentionally being broken by the use of AI. So, you'll either be an "AI mess fixer" or more entrepreneurial doing "artisan, hand-crafted software."<p>Either of those I expect to be fairly lucrative.
Why do articles like this always say things like "I've used LLMs to get some stuff done faster" and then go on to describe how LLMs get them to spend more time and money to do a worse job? You don't need LLMs to frustrate you into lowering your standards, the power to do that was within you all along.
The "glue" comment here reflects a view from someone who does mostly software work. That's been the situation since mechanized production lines were first built. The job of the humans is not direct labor. It's to monitor the machinery, restart it, and fix it.<p>Power looms were probably the first devices like this. Somebody has to thread the loom, but then it mostly runs by itself.[1] Production lines with lots of stations will have shutdowns, where a drill bit broke or there's dirt on a lens or some consumable ran out. Exceptions are hard to automate, and factory design focuses on minimizing exceptions and bypassing stuck cells.<p>It's helpful to understand how a factory works when watching how software development is changing.
There's commonality.<p>So the phrase "vibe coding" is only two months old.[2] How widespread will it be in two years?<p>[1] <a href="https://www.youtube.com/watch?v=WyRW9XOuUdU" rel="nofollow">https://www.youtube.com/watch?v=WyRW9XOuUdU</a><p>[2] <a href="https://en.wikipedia.org/wiki/Vibe_coding" rel="nofollow">https://en.wikipedia.org/wiki/Vibe_coding</a>
AI is unlikely to take away jobs from software engineers. There’s no natural upper bound on the amount of software people can consume - unlike cars, food or houses.<p>Software engineers ultimately are people with “will to build”. Just as hedge fund people have a “will to trade”. The code or tooling is just a means to an end.
"I like fixing thorny bugs". Not me. Any tool that can get me to the solution faster is always welcome. IME, AI does well handling the boring parts.
I’ve been having a different experience. Asking Claude to fix the bug again and again is annoying, so I’m still working on “pull pieces at a time, understanding each” so I do fix the bug myself when it’s faster to do so. In fact, the majority of times I’ve been using the LLM to build tiny libraries for me to avoid the need for the LLM in the running app. Kind of like StackOverflow on steroids. I don’t feel as the glue, but only having a superior tooling to get info I need fast.
I'm still pretty pessimistic on all this. Just today, I had what should have been an obvious win for an LLM coding assistant to help me. I was writing a go function that converts one very long struct into a second very long struct. The transformation was almost entirely wrapping the fields of the first struct in a wrapper in a completely rote way. If FieldA was an int on src, I wanted a dest{ FieldA: Wrapper{ Value: src.FieldA, Ratio: src.FieldA/Constant }, ... }.<p>It couldn't do it. I prefilled in all the fields (hundreds) and told it just to populate them, but it tried to hallucinate new fields, it would do one or two then both delete the fields I had added and add a comment saying 'then do the rest'. I tried a bunch of different prompts.<p>I can see how some vibe coders could make useful things, but most of my attempts to use LLMs in anything not-from-scratch are exercises in frustration.
There is a story about this by Stanislaw Lem: "Elsewhere Tichy meets a race of aliens (called "Indioci" in the Polish original, "Phools" in the English translation) who, desiring perfect harmony in their lives, entrust themselves to a machine, which converts them into shiny discs to be arranged in pleasant patterns across their planet." - <a href="https://en.m.wikipedia.org/wiki/Ijon_Tichy#Stories" rel="nofollow">https://en.m.wikipedia.org/wiki/Ijon_Tichy#Stories</a><p>(Not glue, but close enough.)
Nothing stopping anyone fixing thorny bugs for fun! And hobby computing is more accessible now than ever.<p>If you build stuff for others AI (mostly) removes typing and debugging from the equation; that frees you to think harder about what you’re building and how to make it most useful. And because you’re generally done sooner you can get the thing into your users’ hands sooner, increasing the iterations.<p>It’s win-win.
Well written, I agree with the basic premise of the idea, I just think the changes will be even more dramatic.<p>A lot of us are stationary, thinking stuff and other people around us will be automated, but not us, “I am special”, well I fear a lot of people will find out just how much special they unfortunately are (not).
> I don't see a future where a lot of jobs don't cease to exist.<p>And the complete lack of a game plan of a societal level is starting to get worrying.<p>If we’re going to UBI this then we’re going to need a bit more of a plan than some toy studies
Really interesting that I have so far had hardly any use for code generators except when some glue was needed. Possibly this new revolution may be headed in multiple conflicting directions simultaneously?
On the plus side, at least when I'm old and not so mentally sharp, my personal AI can tell me when I'm being scammed or why the wifi isn't working.
So there's a wrong way and a right way to code with LLMs. The wrong way is to ask the LLM to write a bunch of code you don't understand, and to keep asking it to write more and more code to fix the problems each iteration has. That will lead to a massive tower built on sand, where everything is brittle and collapses at the slightest gust of wind.<p>The right way is to have it autocomplete a few lines at a time for you. You avoid writing all the boilerplate, you don't need to look up APIs, you get to write lines in a tenth of the time it would normally take, but you still have all the context of what's happening where. If there's a bug, you don't need to ask the LLM to fix it, you just go and look, you spot it, and you fix it yourself, because it's usually something dumb.<p>The second way wins because you don't let the LLM make grand architectural choices, and all the bugs are contained in low-level code, which is generally easy to fix if the functions, their inputs, and their outputs are sane.<p>I like programming as much as the next person, but I'm really not lamenting the fact that I don't have to be looking up parameters or exact function names any more. Especially something like Cursor makes this much easier, because it can autocomplete as you type, rather than in a disconnected "here's a diff you won't even read" way.
Hot take: we were already glue. We take in ideas / directives from product people and turn that into instructions for a computer to use to build a software package.<p>The only difference in a “vibe coding” world is that now these “instructions” that we pass to the computer are in English, not Java.