Summarizer

I was in the same camp until a few months ago. I now think they're valid tools, like compilers. Not in the sense that everyone compares them (compilers made asm development a minuscule niche of development). But in the sense that even today many people don't use compilers or static analysis tools. But that world is slowly shrinking. Same for LLMs, the non LLM world will probably shrink. You might be able to have a long and successful career without touching them for code development. Personally I'd rather check them out since tools are just tools.

"What an LLM is to me is the most remarkable tool that we've ever come up with, and it's the equivalent of a e-bike for our minds"

> they've stolen a mountain of information In law, training is not itself theft. Pirating books for any reason including training is still a copyright violation, but the judges ruled specifically that the training on data lawfully obtained was not itself an offence. Cloudfare has to block so many more bots now precisely because crawling the public, free-to-everyone, internet is legally not theft. (And indeed would struggle to be, given all search engines have for a long time been doing just that). > As the arms race continues AI DDoS bots will have less and less recent "training" material My experience as a human is that humans keep re-inventing the wheel, and if they instead re-read the solutions from even just 5 years earlier (or 10, or 15, or 20…) we'd have simpler code and tools that did all we wanted already. For example, "making a UI" peaked sometime between the late 90s and mid 2010s with WYSIWYG tools like Visual Basic (and the mac equivalent now known as Xojo) and Dreamweaver, and then in the final part of that a few good years where Interface Builder finally wasn't sucking on Xcode. And then everyone on the web went for React and Apple made SwiftUI with a preview mode that kept crashing. If LLMs had come before reactive UI, we'd have non-reactive alternatives that would probably suck less than all the weird things I keep seeing from reactive UIs.

Depends on what level of abstraction you're comfortable with. I have no problem driving a car I didn't build.

Why train to pedal fast when we already got motorcycles? You are preparing for yesterday's needs. There will never be a time when we need to solve this manually like it's 2019. Even in 2019 we would probably have used Google, solving was already based on extensive web resources. While in 1995 you would really have needed to do it manually. Instead of manual coding training your time is better invested in learning to channel coding agents, how to test code to our satisfaction, how to know if what AI did was any good. That is what we need to train to do. Testing without manual review, because manual review is just vibes, while tests are hard. If we treat AI-generated code like human code that requires a line-by-line peer review, we are just walking the motorcycle. How do we automate our human in the loop vibe reactions?

> Why train to pedal fast when we already got motorcycles? You are preparing for yesterday's needs. This is funny in the sense that in properly built urban environment bycicles are one of the best ways to add some physical activity in a time constrained schedule, as we're discovering.

Yes and no. Yes, I recon coding is dead. No, that doesn't mean there's nothing to learn. People like to make comparisons to calculators rendering mental arithmetic obsolete, so here's an anecdote: First year of university, I went to a local store and picked up three items each costing less than £1, the cashier rang up a total of more than £3 (I'd calculated the exact total and pre-prepared the change before reaching the head of the queue, but the exact price of 3 items isn't important enough to remember 20+ years later). The till itself was undoubtedly perfectly executing whatever maths it had been given, I assume the cashier mistyped or double-scanned. As I said, I had the exact total, the fact that I had to explain "three items costing less than £1 each cannot add up to more than £3" to the cashier shows that even this trivial level of mental arithmetic is not universal. I now code with LLMs. They are so much faster than doing it by hand. But if I didn't already have experience of code review, I'd be limited to vibe-coding (by the original definition, not even checking). I've experimented with that to see what the result is, and the result is technical debt building up. I know what to do about that because of my experience with it in the past, and I can guide the LLM through that process, but if I didn't have that experience, the LLM would pile up more and more technical debt and grind the metaphorical motorbike's metaphorical wheels into the metaphorical mud.

You could make the same argument about the printing press. Some people like forming the letters by hand, others enjoy actually writing.

Actually, the invention of the printing press in 1450 created a similar disruption, economic panic and institutional fear similar to what we're experiencing now: For centuries, the production of books was the exclusive domain of professional scribes and monks. To them, the printing press was an existential threat. Job Displacement: Scribes in Paris and other major cities reportedly went on strike or petitioned for bans, fearing they would be driven into poverty. The "Purity" Argument: Some critics argued that hand-copying was a spiritual act that instilled discipline, whereas the press was "mechanical" and "soulless." Aesthetic Elitism: Wealthy bibliophiles initially looked down on printed books as "cheap" or "ugly" compared to hand-illuminated manuscripts. Some collectors even refused to allow printed books in their libraries to maintain their prestige. Sound familiar? From "How the Printing Press Reshaped Associations" -- https://smsonline.net.au/blog/how-the-printing-press-reshape... and "How the Printing Press Changed the World" -- https://www.koolchangeprinting.com/post/how-the-printing-pre...

I've seen this argument a few times before and I'm never quite convinced by it because, well, all those arguments are correct. It was an existential threat to the scribes and destroyed their jobs, the majority of printed books are considered less aesthetically pleasing than a properly illuminated manuscript, and hand copying is considered a spiritual act by many traditions. I'm not sure if I say it's a correct argument, but considering everyone in this thread is a lot closer to being a scribe than a printing press owner, I'm surprised there's less sympathy.

The point being missed is the printing press led to tens of millions of jobs and billions of dollars in revenue. So far, when a new technology is introduced that people were initially afraid of, end up creating a whole new set of jobs and industries.

But the world is better of with the scribes unemployed: ideas get to spread, more people can educate themselves through printed books. Maybe the world is better off with fewer coders, as more software ideas can materialize into working software faster?

Many of the same skills that we honed by investing that time and effort into being good software developers make us good AI prompters, we simply moved another layer of abstraction up the stack.

This does seem to be what many are arguing, even if the analogy is far from perfect.

Exactly! ...If the printing press spouted gibberish every 9 words.

Just you wait until the powers that be take cars away from us! What absolute FOOLS you all are to shape your lives around something that could be taken away from us at any time! How are you going to get to work when gas stations magically disappear off the face of the planet? I ride a horse to work, and y'all are idiots for developing a dependency on cars. Next thing you're gonna tell me is we're going to go to war for oil to protect your way of life. Come on!

This is a poor analogy. Cars (mostly) don't require a subscription.

Can't believe this car bubble has lasted so long. It's gonna pop any decade now!

The reliance on SaaS LLMs is more akin to comparing owning a horse vs using a car on a monthly subscription plan.

Flipping toggle switches went out of fashion many, many, many years ago. We've been describing to trainees (compilers) the dish we want for longer than most on HN have been alive.

Actually, we’ve been formally declaring the logic of programs to compilers, which is something very different.

(Replying to myself because hn) That’s not the only difference at all. A good use of an LLM might be to ask it what the difference between using an LLM and writing code for a compiler is.

Equally a good use for a legacy compiler that compiles a legacy language. Granted, you are going to have to write a lot more boilerplate to see it function (that being the difference, after all), but the outcome will be the same either way. It's all just 1s and 0s at the end of the day.

Sorry friend, if you can’t identify the important differences between a compiler and an LLM, either intentionally or unintentionally (I can’t tell), then I must question the value of whatever you have to say on the topic.

The important difference is the reduction in boilerplate, which allows programs to be written with (often) significantly less code. Hence the time savings (and fun) spoken of in the original article. This isn't really a new phenomenon. Languages have been adding things like arrays and maps as builtins to reduce the boilerplate required around them. The modern languages of which we speak take that same idea to a whole new level, but such is the nature of evolution.

No, when we write code it has a an absolute and specific meaning to the compiler. When we write words to an LLM they are written in a non-specific informal language (usually English) and processed non-deterministically too. This is an incredibly important distinction that makes coding, and asking the LLM to code, two completely different ball games. One is formal, one is not. And yes, this isn’t a new phenomenon.

It's different in some ways (such is evolution), but is not a distinction that matters. Kind of like the difference between imperative and declarative programming. Different language models, but all the same at the end of the day.

The only difference is that newer languages have figured out how to remove a lot of the boilerplate.

Little bit of a sweeping generalization there. There are a huge range of ways in which LLMs are being leveraged for software development. Using a drill doesn’t make you any less of a carpenter, even if you stopped using a screwdriver because your wrists are shot.

That’s the issue, though, isn’t it? Why isn’t it black and white? Clear massive productivity gains at Google or MS and their dev armies should be visible from orbit. Just today on HN I’ve seen claims of 25x and 10x and 2x productivity gains. But none of it starting with well calibrated estimations using quantifiable outcomes, consistent teams, whole lifecycle evaluation, and apples to apples work. In my own extensive use of LLMs I’m reminded of mouse versus command line testing around file navigation. Objective facts and subjective reporting don’t always line up, people feel empowered and productive while ‘doing’ and don’t like ‘hunting’ while uncertain… but our sense of the activity and measurable output aren’t the same. I’m left wondering why a 2x Microsoft of OpenAI would ever sell their competitive advantage to others. There’s infinite money to be made exploiting such a tech, but instead we see highschool homework, script gen, and demo ware that is already just a few searches away and downloadable. LLMs are in essence copy and pasting existing work while hopping over uncomfortable copyright and attribution qualms so devs feel like ‘product managers’ and not charlatans. Is that fundamentally faster than a healthy stack overflow and non-enshittened Google? Over a product lifecycle? … ‘sometimes, kinda’ in the absence of clear obvious next-gen production feels like we’re expecting a horse with a wagon seat built in to win a Formula 1 race.

On the frontend, you have build pipelines, bundlers, CSS frameworks with their own toolchains, progressive web apps, Core Web Vitals, SEO, layout shifts, srcset/responsive images… I've been making web stuff for a similar length of time as Mattias by the sounds of it. I started with Perl but moved to PHP 4 pretty soon after. I recognise this problem but I have different take. All the complexity was there 20 years ago, but we ignored it. That doesn't mean it was simpler. It just means we took crazy (with hindsight) risks. Sure, there were no build pipelines like today, but we had scripts we ran to build things. There was Adobe Pagemill for making site wide changes before we deployed a new version. Back in the day we made those changes, did a very brief check that things worked locally, and then manually FTP'd files to a server, breaking it in the process because a user would see the site change as they navigated. Some of us would put up a maintenance page during an update effectively just blocking all the traffic. That's certainly 'simpler', but it's also much worse for the user, and on a site that did things with data potentially risked corrupting a user's records. It was incredible that things didn't break more often. Maybe they did and we just never realised. We didn't have CSS frameworks but we certainly did have our own in-house templates, and they had separate toolchains. As time went on that toolchain mostly migrated to Wordpress and it's template builder plugins. Again, give me Tailwind over that mess. We had Core Web Vitals and SEO in the form of Urchin Stats. We had layout shift but we called it FOUC. We had kind of had srcset, but it was implemented as a set of Macromedia Dreamweaver mm_ JS image preload and swapping functions. <picture> is a lot nicer. Things are just better now. Writing web software is loads of fun. I also leverage LLMs in my code because they're awesome, but not to simplify things. I don't think the complexity is new. I just think it's visible now.

I have fond (?) memories of WebEdit, a code editor with FTP integration, so you could directly edit your PHP4 files on the server. (And no, we didn't have source control.)

Then it fails and the world doesn't end. You fix it or delegate it and move on. Most people aren't working on code for power grids and fighter jets. There's room for failure. This same argument was used by the old timers when younger programmers couldn't code assembly or C on bare metal systems.

<Here is a joke for you> Factory work began when people could use other people as machines. For example, mechanized looms could weave cloth but each cloth weaving machine needed a machine to run it. So use people. Children, real slaves anyone. Slave labor. Thus began the Factory Age. Now AI can replace people for repetitive labor. AI Can run the machines, it is the new Slave Labor. The problem now is what to do with all the freed slaves? If AI can make us the things that are needed, then how are we needed? We are not. As freed slaves, suddenly we are out of work. We are obsolete. Unfortunately, for corporations that are now rushing to free themselves from the old, difficult, demanding, contentious slaves, they have missed one gigantic element of the equation. Hmmm. What could it be? Can you guess? What could possibly go wrong here? Fortunately, for us - the freed slaves and factory workers - it turns out we are not just slaves after all. We were just trained to be slaves. So we have a future. If we can adapt to being free. And that is not a joke. <End joke. I just made this up, nothing about it is true or even remotely serious. />

If Bill Bryson is to be trusted, the loom actually replaced a massive amount of labor. Prior to invention of labor-savings devices, Britain made 32x less cotton fibre. The inventions in this space put tens of thousands out of work, in what was already a difficult job market due to automation. I’m not sure your first paragraph makes sense. People were dirt cheap, but machines were vastly more productive (and some inventions were stolen so that no royalties had to be paid).

I think it’s easier to manage full-stack development as a solo developer now even without AI. Now TypeScript catches a lot of my mistakes before they reach runtime. Now I have good enough browser automation testing tools to catch regressions in the frontend. Now it’s quick and easy to run a specific database version for each app I’m working on with docker. Now I can automate deployment to the cloud instead of having to rely on an entire IT department. Now I have a scalable way to publish and consume reusable units of code as npm packages. None of this was the case in what this author seems to think were the good old days. If web development seemed easy to him back then, I doubt he was working on complex projects

> On the frontend, you have build pipelines, bundlers, CSS frameworks with their own toolchains, progressive web apps, Core Web Vitals, SEO, layout shifts, srcset/responsive images… I remember when the biggest challenge was IE6 compatibility. I know which I'd choose. In my experience of the IE6 era, tooling was atrocious, and most (all?) cross-browser testing was manual. Varying box models and no devtools? Give me npm framework churn and layers of transpilation any day.

If I remember correctly, it was the first whatever-to-JS transpiler. But it opened the floodgates and "do everything in one language, bridge the gap transparently" has been tried several times since then. And even before that, actually! Before web apps were even a thing, we had DCOM and CORBA and some other similar but less-known frameworks that tried to make OOP in general network-transparent. It worked in principle - you could have distributed object graphs in pretty much arbitrary configurations, going back and forth as needed to capture the semantics. It failed in practice because every time you have a network gap you get a slew of potential issues that just don't exist without it (simply put, your connection and/or the other party may suddenly go away). FWIW I'm not saying that single-language specifically is a bad idea. It's specifically the notion that you can treat a distributed app as a monolithic thing without clearly marked internal boundaries where the network gap is, that fails in real world. But if you expose the gap then you still need to deal with impedance mismatch - e.g. nice your object oriented API no longer works because the object graph can't span the gap, so you need a more procedural (read: REST-style) API with serialization etc. So, this is the point where you basically want a language designed from grounds up with message passing in mind. Blazor, but for something like Erlang or Elixir, perhaps?

I have learned more - not just about my daily driver languages, but about other languages I wouldn't have even cracked the seal on, as well as layers of hardware and maker skills - in the past two years than I did in the 30 years leading up to them. I truly don't understand how anyone creative wouldn't find their productivity soar using these tools. If computers are bicycles for the mind, LLMs are powered exoskeletons with neural-controlled turret cannons.

> I remember when PHP 4 was a thing. jQuery was new and shiny. Sites were built with tables, not divs. Dreamweaver felt like a life hack. Designs were sliced in Photoshop. Databases lived in phpMyAdmin. > It probably didn’t feel like it at the time, but looking back, those were simpler days. jQuery was bloat, there were others like MooTools. People idealize tables but it was not just grid, it was often used as hacks as well, like weird offsets, etc. Dreamweaver produced mess. Sliced designs? "This site is optimized for 800x600" Not saying current state is good. I just find interesting how nostalgia can distort memories even in tech.

Turbo C++ Vibe

On a meta level, seems this trajectory follows Alan Kay: first we made the complex things possible, now we make simple things simple.