And? How valuable are individual lines of code? To the author's point, I'm sure AI can translate individual sentences perfectly, but miss the nuance of communication in a bigger project or body of text. In the same vein, when was the last time someone put an AI on a ralph loop, posted the result on r/vibecoding and ended up with actual users.
Don't care, only time I've measured them was personal curiosity about hand-written projects, and one time I was trying to work out how many blank comments a co-worker had put into their codebase*.
How valuable are features? Management kept giving me them, and I always just assumed they'd decided which ones were important. But I've seen git histories of apps where the same feature was added twice, 5 years apart, by the same developer.
> In the same vein, when was the last time someone put an AI on a ralph loop, posted the result on r/vibecoding and ended up with actual users.
How often do the megacorps currently boasting that 80% of their code is now vibed, post anything (other than adverts) to reddit?
* 20% of the whole project, or 24 thousand blank comments.
A simple browser tower defense to enjoy during your lunch break. Written in Kotlin, TeaVM has made it possible to run surprisingly complex Java games, didn't expect it!
Personal story time: for me it was falling for the indie hacker stuff near covid and realizing the same stuff.
The best solo business is to pretend you are successful i.e. "I'm sitting on the beach sipping my drink while Claude is coding my app that's raking in 20k MRR, just use my {SEO|Social Media|Referral} tool and that will be you!". Hope to get enough people suckered in to become a "voice in the bootstrapper community" i.e. your posts filled with generic tropes get shared around X. But ultimately the product is the (fake) lifestyle. Most of the products in that eco system are not used by anyone in the productive economy, it's a pyramid ponzi of users believing they are getting valuable advice.
That said, I do still build stuff "Solo", because I enjoy the process of making and I can take the time time to meet my own quality standards (classic trope in that community even before AI was "you just gotta build you MVP in 3 days, ship quickly!" and it ends up causing you to churn out soulless software that obviously nobody will use unless they are your bootstrapping internet buddy).
Lot of people I know from those days are still trying to make it and wasted a lot of time/money! Not all bad for me personally though - I learned a lot about entrepeneurship, spotting fakes, etc. and was much more naive and younger then.
Building is not any less important now, AI just highlights this fact. The software I work on is the difference between people getting paid or not, which those people consider very important - I use AI to do that by letting it improve the quality of the software, with less bugs, more performance etc.
The 10000th social media spammming SaaS being built in public is no less important now than it was before AI - we can just see how irrelevant it is now that it can also be built faster, by virtually anybody.
Aaaannnnd they're out of business and it was because of slowing demand and tightening credit the whole time.
Here in Europe this is not a thing, I've been hearing about such cases mostly from the US where it's clear that there is a recession going - I don't know why this is not blatantly obvious to everyone who does not view reality as whatever is said by the talking heads on TV.
Yeap, and people are still forcing juniors to make small code changes when they should be learning by creating entire apps on their own, deploying them, etc. WITH a senior giving them feedback occasionally. I think people are going to take a while to catch on though, for better or worse....
Yeah, IMO one of the first things we'll see change is more of a migration back to monoliths. Right now adding a feature has to go through multiple teams, a dozen services, a coordinated implementation and deployment schedule, a Byzantine and often manual set of integration tests, etc. Yeah AI can help with that, but the point is that AI doesn't need it. On a monolith, it sucks for dev teams because parallel development at large scale is difficult and other teams' bugs can delay the launch of your unrelated project. Hence, microservices became popular. With AI, development happens so fast that it's largely serial. So there's no real coordination needed. A whole feature is one PR, one set of tests, one app to run locally if you want, one deployment, one thing to look at and roll back if there's a bug. Creates a virtuous cycle all the way up.
I imagine lots of established companies will struggle migrating back to that pattern, but I have to think most new companies will head in that direction, which should let them catch up quickly.
This is 100% an issue on the side of the senior developers. Imagine saying "these juniors are useless" because you are making them work in assembly, but C has just been released. You are giving them menial work that is no longer required to do by humans. Instead of giving them the task "update these email templates", the norm should be: "create this new service that automates an internal process". They will make mistakes and they will learn - but what they will be doing is going to be very useful and also give them chance to grow the necessary skills for this new era, with the supervision of a senior.
By making them walk into the landmines and forcing them to fix it - that is how everyone became a good programmer. It's just the scope that has changed.
> For example, to add pagination to this website, I would read the Jekyll docs, find the right plugin to install, read the sample config, and make the change. Possibly this wouldn’t work, in which case I would Google it, read more, try more stuff, retest, etc. In this process it was hard not to learn things.
How is this any different than building Ikea furniture? If I build my "Minska" cupboard using the step-by-step manual, did I learn something profound?
If you've never put a cupboard together, you would have learned what the different parts, what size of screws to use (in the rough sense),... You may have forget it right after, but when someone ask you to help them, you will be a bit more proficient than someone with no experience.
But the nice thing about a cupboard and its components is that they are real objects, so the remembrance is done with the whole body (like the feeling of a screw not correctly inserted). Software development is 90% a mental activity.
Firstly, if you're doing those steps, you're building your own tutorial, not just following the exact steps in a manual provided with the software. The sample config won't be exact or perfect for your setup, so you'll need to say least figure out how to adjust it to your needs.
That said, I think you're still leaning things building IKEA-style software. The first time I learned how to program, I learned from a book and I tried things out by copying listings from the book by hand into files on my computer and executing them. Essentially, it was programming-by-IKEA-manual, but it was valuable because I was trying things out with my own hands, even if I didn't fully understand every time why I needed the code I'd been told to write.
From there I graduated to fiddling with those examples and making changes to make it do what I wanted, not what the book said. And over time I figured out how to write entirely new things, and so on and so forth. But the first step required following very simple instructions.
The analogy isn't perfect, because my goal with IKEA furniture is usually not to learn how to build furniture, but to get a finished product. So I learn a little bit about using tools, but not a huge amount. Whereas when typing in that code as a kid, my goal was learning, and the finished product was basically useless outside of that.
The author's example there feels like a bit of both worlds. The task requires more independent thought than an IKEA manual, so they need to learn and understand more. But the end goal is still practical.
reply