Though, I guess I do treat LLM's as a last resort longshot for when other documentation is failing me.
99% of an LLM's usefulness vanishes, if it behaves like an addled old man.
"What's that sonny? But you said you wanted that!"
"Wait, we did that last week? Sorry let me look at this again"
"What? What do you mean, we already did this part?!"
Further, they can't write code that fast, because you have to spend 1000x explaining it to them.
I don't think current LLMs take you all the way but a powerful code generator is a useful think, just assemble guardrails and keep an eye on it.
I now understand why Altman announced "Code Red" at OpenAI. If their tools don't catch up drastically, and fast, they'll be one for the history books soon. Wouldn't be the first time the big, central early mover in a new market suddenly disappears, steamrolled by the later entrants.
That doesn't mean the agents are amazing, but they can be useful.
instead of telling me about z option it keeps hallucinating something that doesnt exist and even says its in the docs when it isnt.
Literally just wasting my time
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.
That's what LLMs take away. Nothing is given back to the community, nothing is added to shared knowledge, no differing opinions are exchanged. It just steals other people's work from a time when work was still shared and discussed, removes any indication of its source, claims it's a new thing, and gives you no way to contribute back, or even discuss it and maybe get confronted with different opinions of even discovering a better way.
Let's not forget that one of the main reasons why LLMs are useful for coding in the first place, is that they scraped SO from the time where people still used it.
You can absolutely learn from an LLM. Sometimes.documentation sucks and the LLM has learned how to put stuff together feom examples found in unusual places, and it works, and shows what the documentation failed to demonstrate.
And with the people above, I agree - sometimes the fun is in the end process, and sometimes it is just filling in the complexity we do not have time or capacity to grab. I for one just cannot keep up with front end development. Its an insurmountable nightmare of epic proportions. Im pretty skilled at my back end deep dive data and connecting APIs, however. So - AI to help put together a coherent interface over my connectors, and off we go for my side project. It doesnt need to be SOC2 compliant and OWASP proof, nor does it need ISO27001 compliance testing, because after all this is just for fun, for me.
The code that LLM outputs, has worked well enough to learn from since the initial launch of ChatGPT. This even though back then you might have to repeatedly say "continue" because it would stop in the middle of writing a function.
Necessarily, LLM output that works isn't gibberish.
Especially in this context, if a mystery box solves a problem for me, I can look at the solution and learn something from that solution, c.f. how paper was inspired by watching wasps at work.
Even the abject failures can be interesting, though I find them more helpful for forcing my writing to be easier to understand.
Also, it's actually fun watching LLMs debug. Since they're reasonably similar to devs while investigating, but they have a data bank the size of the internet so they can pull hints that sometimes surprise even experienced devs.
I think hard earned knowledge coming from actual coding is still useful to stay sharp but it might turn out the balance is something like 25% handmade - 75% LLM made.
they have a data bank the size of the internet so they can
pull hints that sometimes surprise even experienced devs.
it might turn out the balance is something like 25% handmade - 75% LLM made.
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.
That is simply not true. Freely available on the web doesn't mean it's in the Public Domain. The "lawfully obtained" part of your argument is patently untrue. You can legally obtain something, but that doesn't mean any use of it is automatically legal as well. Otherwise, the recent Spotify dump by Anna's Archive would be legal as well.
It all depends on the license the thing is released under, chosen by the person who made it freely accessible on the web. This license is still very emphatically a legally binding document that restricts what someone can do with it.
For instance, since the advent of LLM crawling, I've added the "No Derivatives" clause to the CC license of anything new I publish to the web. It's still freely accessible, can be shared on, etc., but it explicitly prohibits using it for training ML models. I even add an additional clause to that effect, should the legal interpretation of CC-ND ever change. In short, anyone training an LLM on my content is infringing my rights, period.
Doesn't need to be.
> The "lawfully obtained" part of your argument is patently untrue. You can legally obtain something, but that doesn't mean any use of it is automatically legal as well.
I didn't say "any" use, I said this specific use. Here's the quote from the judge who decided this:
5. OVERALL ANALYSIS.
After the four factors and any others deemed relevant are “explored, [ ] the results [are] weighed together, in light of the purposes of copyright.” Campbell, 510 U.S. at 578. The copies used to train specific LLMs were justified as a fair use. Every factor but the nature of the copyrighted work favors this result. The technology at issue was among the most transformative many of us will see in our lifetimes.
> Otherwise, the recent Spotify dump by Anna's Archive would be legal as well.
I specifically said copyright infringement was separate. Because, guess what, so did the judge the next paragraph but one from the quote I just gave you.
> For instance, since the advent of LLM crawling, I've added the "No Derivatives" clause to the CC license of anything new I publish to the web. It's still freely accessible, can be shared on, etc., but it explicitly prohibits using it for training ML models. I even add an additional clause to that effect, should the legal interpretation of CC-ND ever change. In short, anyone training an LLM on my content is infringing my rights, period.
It will be interesting to see if that holds up in future court cases. I wouldn't bank on it if I was you.
Yes, but I can't stop them, can you?
> But I'm glad you're able to have your fun.
Unfortunately I have to be practical.
> Doubtful. As the arms race continues AI DDoS bots will have less and less recent "training" material. Not a day goes by that I don't discover another site employing anti-AI bot software.
Almost all these BigCos are using their internal code bases as material for their own LLMs. They're also increasingly instructing their devs to code primarily using LLMs.
The hope that they'll run out of relevant material is slim.
Oh, and at this point it's less about the core/kernel/LLMs than it is about building ol' fashioned procedural tooling aka code around the LLM, so that it can just REPL like a human. Turns out a lot of regular coding and debugging is what a machine would do, READ-EVAL-PRINT.
I have no idea how far they're going to go, but the current iteration of Claude Code can generate average or better code, which is an improvement in many places.
The hope that they'll run out of relevant material is slim.
> If big corps are training their LLMs on their LLM written code <<and human reviewed code>>…
The last part is important.
Instead you’d learn it, remember it, and it would be useful next time. But it’s not.
Some people will try to vibe out everything with LLMs, but other people will use them to help engage with their coding more directly and better understand what's happening, not do worse.
I've been programming for 15+ years, and I think I've forgotten the overwhelming majority of the things I've googled. Hell, I can barely remember the things I've googled yesterday.
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?
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.
All channelling is broken when the model is updated. Being knowledgeable about the foibles of a particular model release is a waste of time.
> how to test code to our satisfaction
Sure testing has value.
> how to know if what AI did was any good
This is what code review is for.
> Testing without manual review, because manual review is just vibes
Calling manual review vibes is utterly ridiculous. It's not vibes to point out an O(n!) structure. It's not vibes to point out missing cases.
If your code reviews are 'vibes', you're bad at code review
> If we treat AI-generated code like human code that requires a line-by-line peer review, we are just walking the motorcycle.
To fix the analogy you're not reviewing the motorcycle, you're reviewing the motorcycle's behaviour during the lap.
My point is that visual inspection of code is just "vibe testing", and you can't reproduce it. Even you yourself, 6 months later, can't fully repeat the vibe check "LGTM" signal. That is why the proper form is a code test.
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.
Code review done visually is "just vibe testing" in my book. It is not something you can reproduce, it depends on the context in your head this moment. So we need actual code tests. Relying on "Looks Good To Me" is hand waving, code smell level testing.
We are discussing vibe coding but the problem is actually vibe testing. You don't even need to be in the AI age to vibe test, it's how we always did it when manually reviewing code. And in this age it means "walking your motorcycle" speed, we need to automate this by more extensive code tests.
However, code review can spot things like "this is O(n^2) when it could be O(n•log(n))", or "you're doing a server round trip for each item instead of parallelising them" etc.
You can also ask an LLM for a code review. They're fast and cheap, and whatever the LLM catches is something you get without having to waste a coworker's time. But LLMs have blind spots, and more importantly all LLMs (being trained on roughly the same stuff in roughly the same way) have roughly the same blind spots, whereas human blind spots are less correlated and expand coverage.
And code smells are still relevant for LLMs. You do want to make sure they're e.g. using a centralised UI style system and not copy-pasting style into each widget, because duplication wastes tokens and is harder to correctly update with LLMs for much the same reason it is with humans: stuff gets missed during the process when it's copypasta.
Take a look here: https://github.com/horiacristescu/archlib/blob/main/examples... (but it's still WIP, I am not there yet)
For the people who just want to solve some problem unrelated to computers but require a computer for some part of the task, yes AI would be more “fun”.
Most of all I find what computers allow humanity to achieve extremely interesting and motivating. I call them the worlds most complicated robot.
I don’t find coding overly fun in itself. What I find fun is the results I get when I program something that has the result I desire. Maybe that’s creating a service for friends to use, maybe it’s a personal IT project, maybe it’s having commercial quality WiFi at home everyone is amazed at when they visit, etc. Sometimes - even often - it’s the understanding that leads to pride in craftsmanship.
But programming itself is just a chore for me to get done in service of whatever final outcome I’m attempting to achieve. Could be delivering bits on the internet for work, or automating OS installs to look at the 50 racks of servers humming away with cable porn level work done in the cabinets.
I never enjoyed messing around with HTML at that much in the 90s. But I was motivated to learn it just enough to achieve the cool ideas I could come up with as a teenager and share them with my friends.
I can appreciate clean maintainable code, which is the only real reason LLMs don’t scratch the itch as much as you’d expect for someone like me.
I don’t enjoy boilerplate. I don’t necessarily enjoy all of the error checking and polishing and minutia in turning algorithms into shippable products.
I find AI can be immensely helpful in making real things for people to use, but I still enjoy doing what I find fun by hand.
Different strokes I guess
I just was pushing back on the “you aren’t into computers if you don’t get intrinsic joy out of programming itself” bit.
I'm a stereotypical nerd, into learning for its own sake.
I can explain computers from the quantum mechanics of band gaps in semiconductors up to fudging objects into C and the basics of operating systems with pre-emptive multitasking, virtual memory, and copy-on-write as they were c. 2004.
Further up the stack it gets fuzzy (not that even these foundations are not; "basics" of OSes, I couldn't write one); e.g. SwiftUI is basically a magic box, and I find it a pain to work with as a result.
LLM output is easier to understand than SwiftUI, even if the LLM itself has much weirder things going on inside.
I think I can describe the principles at work with DNS, but not all of how IP packets are actually routed; the physics of beamforming and QAM, but none of the protocol of WiFi; the basics of error correction codes, but only the basics and they're probably out of date; the basic ideas used in private key crypto but not all of HTTPS; I'd have to look up the OSI 7-layer model to remember all the layers; I understand older UI systems (I've even written some from scratch), but I'm unsure how much of current web browsers are using system widgets vs. it all being styled HTML; interrupts as they used to be, but not necessarily as they still are; my knowledge of JavaScript is basic; and my total knowledge of how certificate signing works is the conceptual level of it being an application of public-private key cryptography.
I have e.g. absolutely no idea why Chrome is famously a memory hog, and I've never learned how anything is scheduled between cores at the OS level.
I had a bit of an identity crisis with AI first landed and started producing good code. “If I’m not the man who can type quickly, accurately, and build working programs… WHO AM I?”
But as you pointed out, I quickly realized I was never that guy. I was the guy who made problems go away, usually with code.
Now I can make so many problems go away, it feels like cheating. As it turns out, writing code isn’t super useful. It’s the application of the code, the judgement of which problems to solve and how to solve them, that truly mattered.
And that sparks a LOT of joy.
I wanted that fixed, and I had given up on ever seeing it fixed. Suddenly, in only two hours, I had it fixed. And I learned a lot in the process, too!
To each their own! I think the market for folks who understand their own problems is exploding! It’s free money.
Take a look at yourself and honestly ask yourself why you felt the need to shit on a random stranger's hobby project without knowing anything about it. What in you is so hurt that you had to hurt another?
SIP and the transition to a read-only system volume are the only two things that I remember broke things that I noticed.
It’s not Windows-level of backwards compatibility, but it’s quite good overall from the user side.
Just yesterday for example, I used AI to build a GTK app that has a bunch of sports team related sound effects built into them. I could have coded this by hand in 45 minutes, but it only took 10 minutes with AI. That's not the best part though. The best part is that I was able to use AI to get it building into an app image in a container so I can distribute it to myself as a single static file that I can execute on any system I want. Dicking with builds and distribution was always the painful part and something that I never enjoyed, but without it, usage is a pain. I've even gone back to projects I built a decade ago or more and got them building against modern libraries and distributed as RPMs or app images that I can trivially install on all of my systems.
The joy is now in the results rather than the process, but it is joy nonetheless.
There is immense pleasure in a nice piece of code - something that is elegant, clever and simple at the same time.
Grinding out code to get something finished - less fun…
For that, having elegant and simple software is not needed; getting features fast to try out how they work is the basis of the pleasure, so having to write every detail by hand reduces the fun.
Building the instrument would be electrical engineering.
Playing the instrument would be writing software.
Is it necessary to pay $200/mo to actually ship things or will $20/mo do it? Obviously I could just try it myself and see how far I get bit I'm curious to hear from someone a bit further down the path.
I'll use it for a few hours at a time, a couple days a week, often while watching TV or whatever. I do side projects more on long rainy weekends, and maybe not even every week during the summer. I'll hit the limit if I'm stuck inside on a boring Sunday and have an idea in my head I really wanted to try out and not stop until I'm done, but usually I never hit the limit. I don't think I've hit the limit since I switched my default to Haiku FWIW.
The stat's say I've generated 182,661 output tokens in the last month (across 16 days), and total usage if via API would cost $39.67.
You can vibe code, i.e. no code review, but this builds up technical debt. Think of it as a junior who is doing one sprint's worth of work every 24 hours of wall-clock time when considering how much debt and how fast it will build up.
I started on the $20 plans for a bit of an experiment, needing to see about this whole AI thing. And for the first month or two that was enough to get the flavor. It let me see how to work. I was still copy/pasting mostly, thinking about what to do.
As i got more confident i moved to the agents and the integrated editors. Then i realised i could open more than one editor or agent at a time while each AI instance was doing its work.
I discovered that when I'm getting the AI agents to summarise, write reports, investigate issues, make plans, implement changes, run builds, organise git, etc, now I can alt-tab and drive anywhere between 2-6 projects at once, and I don't have to do any of the boring boiler plate or administrivia, because the AI does that, it's what its great for.
What used to be unthinkable and annoying context switching now lets me focus in on different parts of the project that actually matter, firing off instructions, providing instructions to the next agent, ushering them out the door and then checking on the next intern in the queue. Give them feedback on their work, usher them on, next intern. The main task now is kind of managing the scope and context-window of each AI, and how to structure big projects to take advantage of that. Honestly though, i don't view it as too much more than functional decomposition. You've still got a big problem, now how do you break it down.
At this rate I can sustain the $100 claude plan, but honestly I don't need to go further than that, and that's basically me working full time in parallel streams, although i might be using it at relatively cheap times, so it or the $200 plan seems about right for full time work.
I can see how theoretically you could go even above that, going into full auto-pilot mode, but I feel i'm already at a place of diminishing marginal returns, i don't usually go over the $100 claude code plan, and the AIs can't do the complex work reliably enough to be left alone anyway. So at the moment if you're going full time i feel they're the sweet spot.
The $20 plans are fine for getting a flavor for the first month or two, but once you come up to speed you'll breeze past their limitations quickly.
Which means that a sensible way to go about those things is to start with a $20 subscription to get access to the best models, and then look at your extra per-token expenses and whether they justify that $200 monthly.
I do code golf for fun. My favorite kind of code to write is code I'll never have to support. LLMs are not sparking joy. I wish I was old enough to retire.
Sometimes, the journey is the destination.
It's just that if you really like to work on your craftsmanship, you spend most of the time rewriting/remodelling because that's where the fun is if you're more on the /making/ things side of the spectrum, and LLMs don't really assist in that part (yet?). Maybe LLMs could be used to discuss ways to model a problem space?
You can use LLMs in whatever way works for you. Objections like the ones in this thread seem to assume that the LLM determines the process, but that’s not true at present.
Perhaps they’re worrying about what might happen in future, but more likely they’re just resisting change in the usual way of inventing objections against something they haven’t seriously tried. These objections serve more as emotional justifications to avoid changing, than rational positions.
I still enjoy writing code as well, but I see them as separate hobbies. LLMs can take my hand-optimized assembly drag racing or the joy of writing a well-crafted library from my cold dead hands, but that's not always what I'm trying to do and I'll gladly have an LLM write my OCI layout directory to CPIO helper or my Bazel rule for putting together a configuration file and building the kernel so that I can spend my time thinking about how the big pieces fit together and how I want to handle trust roots and cold starts.
I basically don’t outsource stuff to an LLM unless I know roughly what to expect the LLM output to look like and I’m just saving myself a bunch of typing.
“Could you make me a Go module with an API similar to archive/tar.Writer that produces a CPIO archive in the newcx format?” was an example from this project.
This pattern of LLM usage has been great for leaning the other's skill set so we can more effectively review each other's code. I can spend a week planning and iterating with Claud on TypeScript, then have my peer review and correct both the implemented outcome _and_ the plan that produced it, allowing me to learn how to drive the LLM more effectively in my non-preferred language. The same is true of him, he's able to autonomously learn and iterate on Go in a way that's efficient and respectful of my time.
More anecdotal evidence supporting the concept these tools are a super-power for experienced engineers, especially when you have a small group of them working together in multiple languages.
Much of the time, it generates basically what I would have written, but faster. Sometimes, better, because it has no concept of boredom or impatience while it produces exhaustive tests or fixes style problems. I review, test, demand refinements, and tweak a few things myself. By the end, I have a working thing and I've gotten a refresher on things anyway.
I was working on an open source contribution for a few days. Something that I struggled with, but I enjoyed the challenge and learned a lot from it.
As it happened someone else submitted a PR fixing the same issue around the same time. I wasn't bothered if mine got picked or not, it happens. But I remember looking at how similar both of our contributions were and feeling like we were using our brains as computers, just crunching algorithms and pumping in knowledge to create some technical code that was (at the time) impossible for a computer to create. This stayed with me for a while and I decided that doing this technical algorithm crunching wasn't the best use of my human brain. I was making myself interchangeable with all the other human (and now AI) code crunchers. I should move on to a higher level, either architectural or management.
This was a big deal for me because I did love (and still do) deeply understanding algorithms and mathematics.
I was extremely fortunate with timing as it was just around one year before AI coding became mainstream but early enough that it wasn't a factor in this shift. Now an AI could probably churn out a decent version of that algorithm in a few minutes.
I did move on to open my own business with my partner and haven't written much code in a few years. And when I do now I appreciate that I can focus on the high level stuff and create something that my business needs in a few hours without exhausting myself on low level algorithm crunching.
This isn't meant to put down the enjoyment of writing code for code's sake. I still do appreciate well written code and the craft that goes into it. I'm just documenting my personal shift and noting that enjoyment can be found on both sides.
I have an extensive media collection of very large VR video files with very unhelpful names. I needed to figure out a good way to review which ones I wanted to keep and discard (over 30TB, almost 2000 files). It was fun sitting using Cursor with Claude to work on setting up a quick web UI, with calls out to ffmpeg to generate snapshots. It handled the “boring parts” with aplomb, getting me a html page with a little JavaScript to serve as my front end, and making a super simple API. All this was still like 1000 lines and would have taken me days, or I would have copied some boilerplate then modified it a little.
The problems Claude couldn’t figure out were also similarly interesting, like its syntax to the ffmpeg calls were wrong and not skipping all the frames we didn’t want to generate, so it was taking 100x longer to generate than was necessary seeking through every file, then I made some optimizations in how I had it configured, then realizing I’d generated thumbnails for 3 hours only for them to not display well on the page as it was an 8x1 tile.
At that point Claude wanted to regenerate all the thumbnails and I said “just display the image twice, with the first half displayed the first time and the second half displayed the second time, saving myself a few hours. Hacky, but for a personal project, the right solution.
I still felt like I was tinkering in a way I haven’t in awhile, and a project that I’d never have gotten around to and instead have just probably bought another new hard drive, took me a couple hours, most of which was actually marking the files as keep or delete. I ended up deleting 12TB of stuff I didn’t want, which it felt cool to write myself a bespoke tool rather than search around on the off chance that such a thing already exists.
It also gave me a mental framework of how to approach little products like this in the future, that often a web ui and a simple API backend like Node making external process calls is going to be easier than making a full fat windows UI.
I have a similarly sized STL library from 3D printing and think I could apply mostly the same idea to that, in fact it’s 99% the same except for swapping out the ffmpeg call to something to generate a snapshot of the stl at a few different angles.
Sometimes there are people who enjoy both. Sometimes there are people that really like driving but not the tinkering and some who are the opposite.
But I'd argue that if anyone wants to jump into technical stuff ; it has never been so openly accessible - you could join some niche slack where some competent programmers were doing great stuff. Today a solo junior can ship you a key-val that is going to be fighting redis in benchmarks.
It really is not a time to slack down in my opinion - everything feels already existing and mostly already dealt with. But again - for those who are frustrated with the status-quo ; they will always find something to do.
I get you however that this has created a very different space where past acquired skill-sets don't necessarily translate as well today - maybe it's just going to be different to find it's space than it was 10 years ago.
I like that the cards have be re-dealt though - it's arguably way more open than the stack-overflow era and pre-ai where knowledge was much more difficult to create.
I decided to write an app in Rust with a React UI, and Claude wrote almost all the typescript for me.
So I’ve used Claude at both ends of the spectrum. I had way more fun in every situation.
AI is, fortunately, very bad at the things I find fun, at least for now, and very good at the things I find booooring (read in Scot Pilgrim voice).
its getting years of sideprojects off the ground for me
now in languages I never learned or got professional validation for: rust, lua for roblox … in 2 parallel terminal windows and Claude Code instances
all while I get to push frontend development further and more meticulously in a 3rd. UX heavy design with SVG animations? I can do that now, thats fun for me
I can make experiences that I would never spend a business Quarter on, I can rapidly iterate in designs in a way I would never pay a Fiverr contractor or three for
for me the main skill is knowing what I want, and its entirely questionable about whether that’s a moat at all but for now it is because all those “no code” seeking product managers and ideas guys are just enamored that they can make a generic something compile
I know when to point out the AI contradicted itself in a code concept, when to interrupt when its about to go off the rails
So far so great and my backend deployment proficiency has gone from CRUD-app only to replicating, understanding and superpassing what the veteran backend devs on my teams could do
I would previously call myself full stack, but knowing where my limits in understanding are
Me from 9 days ago: https://news.ycombinator.com/item?id=46391392#46398917
> I don't know but to me this all sounds like the antithesis of what makes programming fun. I don't have productivity goals for hobby coding where I'd have to make the most of your half an hour -- that sounds too much like paid work to be fun. If I have a half an hour, I tinker for a half an hour and enjoy it. Then I continue when I have another half an hour again. (Or push into night because I can't make myself stop.)
Reading it like this makes it obvious to me that what you find fun is not necessarily what other people find fun. Which shouldn't come as a surprise. Describing your experience and preferences as something more is where the water starts getting muddy.
This was a fun weekend but I would have procrastinated forever without a coding agent.
i am in your camp, i get 0 satisfaction out of seeing something appear on the screen which i don't deeply understand
i want to feel the computer as i type, i've recently been toying with turning off syntax highlighting and LSPs (not for everyone), and i am surprised at the lack of distractions and feeling of craft and joy it brings me
AI changes that. If someone wants to code in a new area, it's 10000000x easier to get started.
What if the # of handwritten lines of code is actually increasing with AI usage?
I think the classic division of problems being solved might, for most people, solve this seeming contradiction.
For every problem, X% is solving the necessary complexity of the problem. Taming the original problem, in relation to what computers are capable of doing. With the potential of some relevant well implemented libraries or API’s helping to close that gap.
Work in that scenario rarely feels like wasted time.
But in reality, there is almost always another problem we have to solve, the Y%=(1-X) of the work required for an actual solution that involves wrangling with mismatches in available tools from the problem being solved.
This can be relatively benign, just introducing some extra cute little puzzles, that make our brains feel smart as we successfully win wack-a-mole. A side game that can even be refreshing.
Or, the stack of tools, and their quirks, that we need to use can be an unbounded (even compounding) generative system of pervasive mismatches and pernicious non-obvious, not immediately recognizable, trenches we must a 1000 little bridges, and maybe a few historic bridges, just to create a path back to the original problem. And it is often evident that all this work is an artifact of 1000 less than perfect choices by others. (No judgement, just a fact of tool creation having its own difficulties.)
That stuff can become energy draining to say the list.
I think high X problems are fun to solve. Most of our work goes into solving the original problem. Even finding out it was more complex than we thought feels like meaningful drama and increase the joy of resolving.
High Y problems involve vast amounts of glue code, library wrappers with exception handling, the list in any code base can be significant. Even overwhelm the actual problem solving code. And all those mismatches often hold us back, to where our final solution inevitable has problems in situations we hope never happen, until we can come back for round N+1, for unbounded N.
Any help from AI for the latter is a huge win. Those are not “real” problems. As tool stack change, nobody will port Y-type solutions forward. (I tell myself so I can sleep at night).
So that’s it. We are all different. But what type of acceleration AI gives us on type-Y problems is most likely to feel great. Enabling. Letting us harder on things that are more important and lasting. And where AI is less of a boost, but still a potentially welcome one, as an assistant.
Some people have goals of actually finishing a project instead of just "tinkering"... and that's ok. Some say it might even be necessary.
LLMs don't make everyone better, they make everything a copy.
The upwards transfer of wealth will continue.
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'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.
What makes it even more odd for me is they are mostly describing doing nothing when using their agents. I see the "providing important context, setting guardrails, orchestration" bits appended, and it seems like the most shallow, narrowest moat one can imagine. Why do people believe this part is any less tractable for future LLMs? Is it because they spent years gaining that experience? Some imagined fuzziness or other hand-waving while muttering something about the nature of "problem spaces"? That is the case for everything the LLMs are toppling at the moment. What is to say some new pre-training magic, post-training trick, or ingenious harness won't come along and drive some precious block of your engineering identity into obsolescence? The bits about 'the future is the product' are even stranger (the present is already the product?).
To paraphrase theophite on Bluesky, people seem to believe that if there is a well free for all to draw from, that there will still exist a substantial market willing to pay them to draw from this well.
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.
Anyone with access to the internet can use an LLM to do things.
Maybe the world is better off with fewer coders, as more software ideas can materialize into working software faster?
I say this as someone who has been extremely sceptical over their ability to code in deep, complicated scenarios, but lately, claude opus is surprising me. And it will just get better.
Not really, it just transforms into a question of how many of those jobs are meaningful anyway, or more precisely, how much output from them is meaningful.
Not every task will be suitable at the moment, but many are. Give claude lots of direction (I've been creating instructions.txt files) and iterate on those. Ask claude to generate a plan and write it out to a file. Read the file, correct what needs correcting, then get it to implement. It works pretty well, you'll probably be surprised. I'm still doing a lot of thought work, but claude is writing a lot of the actual code.