It's very interesting to me how many people presume that if you don't learn how to vibecode now you'll never ever be able to catch up. If the models are constantly getting better, won't these tools be easier to use a year from now? Will model improvements not obviate all the byzantine prompting strategies we have to use today?

A good analogy might be synthesized music.

In the early days, the interfaces were so complex and technical, that only engineers could use them.

Some of these early musicians were truly amazing individuals; real renaissance people. They understood the theory, and had true artistic vision. The knew how to ride the tiger, and could develop great music, fairly efficiently.

A lot of others, not so much. They twiddled knobs at random, and spent a lot of effort, panning for gold dust. Sometimes, they would have a hit, but they wasted a lot of energy on dead ends.

Once the UI improved (like the release of the Korg M1 sampler), then real artists could enter the fray, and that’s when the hockey stick bent.

Not exactly sure what AI’s Korg M1 will be, but I don’t think we’re there, yet.

I have been a lead engineer for a few decades now, responsible for training teams and architecting projects. And I've been working heavily with AI.

I know how to get Claude multi-agent mode to write 2,500 lines of deeply gnarly code in 40 minutes, and I know how to get that code solid. But doing this absolutely pulls on decades on engineering skill. I read all the core code. I design key architectural constraints. I invest heavily in getting Claude to build extensive automated verification.

If I left Claude to its own devices, it would still build stuff! But with me actively in the loop, I can diagnose bad trends. I can force strategic investments in the right places at the right times. I can update policy for the agents.

If we're going to have "software factories", let's at least remember all the lessons from Toyota about continual process improvement, about quality, about andon cords and poke-yoke devices, and all the rest.

Could I build faster if I stopped reading code? Probably, for a while. But I would lose the ability to fight entropy, and entropy is the death of software. And Claude doesn't fight entropy especially well yet, not all by itself.

What I've found out is that a lot of people don't actually care. They see it work and that's that. It's impossible to convince them otherwise. The code can be absolutely awful but it doesn't matter because it works today.

That's been my experience, too.

I have been able to write some pretty damn ambitious code, quickly, with the help of LLMs, but I am still really only using it for developing functions, as opposed to architectures.

But just this morning, I had it break up an obese class into components. It did really well. I still need to finish testing everything, but it looks like it nailed it.

I like the analogy but I think you are underestimating how much random knob twiddling there is in all art.

Francis Bacon and The Brutality of Fact is a wonderful documentary that goes over this. Bacon's process was that he painted every day for a long time, kept the stuff he liked and destroyed the crap. You are just not seeing the bad random knob twiddling he did.

Picasso is even better. Picasso had some 100,000 works. If you look at a book that really gets deep to the more obscure stuff, so much of Picasso is half finished random knob twiddling garbage. Stuff that would be hard to guess is even by Picasso. There is this myth of the genius artist with all the great works being this translation of the fully formed vision to the medium.

In contrast, even the best music from musical programming languages is not that great. The actual good stuff is so very thin because it is just so much effort involved in the creation.

I would take the analogy further that vibe coding in the long run probably develops into the modern DAW while writing c by hand is like playing Paganini on the violin. Seeing someone playing Paganini in person makes it laughable that the DAW can replace a human playing the violin at a high level. The problem though is the DAW over time changes music itself and people's relation to music to the point it makes playing Paganini in person on the violin a very niche art form with almost no audience.

I read the argument on here ad nauseam about how playing the violin won't be replaced and that argument is not wrong. It is just completely missing the forest for the trees.

I think this is very well stated. I’m gonna say something that’s far more trite, but what I’ve noticed is that in an effort to get a better result while assisting AI coding, I have to throw away any concept I previously held about good code hygiene and style. I want it to be incredibly verbose. I want to have everything explicitly asserted. I want to have tests and hooks for every single thing. I want it to be incredibly hard for the human to work directly on it …

That sounds a lot like “twiddling knobs at random,” to me.

Exactly. The fact that an LLM isn't very good at helping you fix basic organizational issues like this is emblematic. Quoting the article: "We have automated coding, but not software engineering."

> Sometimes, they would have a hit, but they wasted a lot of energy on dead ends.

We'll see which one it is in a few months.

Common sense.

If you can use an imperfect tool, perfectly, you’ll beat people using them imperfectly. As long as the tool is imperfect, you won’t have much competition.

That’s where we are, right now. Good engineers are learning how to use klunky LLMs. They will beat out the Dunning-Kruger crew.

Once the tool becomes perfect, then that allows less-technical users into the tent, which means a much larger pool of creativity.

I think so, that's why I think that the risk of pretty much ignoring the space is close to zero. If I happen to be catastrophically wrong about everything then any AI skills I would've learned today will be completely useless 5 years from now anyway, just like skills from early days of ChatGPT are completely useless today.

It's hilarious. The whole point of "vibe coding" is that you don't need to learn or know anything.

It's like saying if you don't learn to use a smartphone you'll be left behind. Even babies can use it now.

That's another dumb thing that unfortunately some people can be led to believe. There have been parents who genuinely thought that screen time would make their kids digitally savvy and prepared for the future.

It has worked out quite well for some of them, but there's a lot of devil in the details of the implementation of that screentime that led to eg Mark Zuckerberg vs Markiplier.

Leave them with an old Toshiba and an Ubuntu cd. Good luck kid.

Nah, a pile of PC parts and DOS and Doom floppies.

I do think there's value in trying out fully vibe coding some toy projects today (probably nothing real or security sensitive haha).

The AI will get better at compensating, but I think some of it's weaknesses are fundamental, and are going to be showing up in some form or another for a while yet

Ex, the AI doesn't know about what you don't tell it. There's a LOT of context we take for granted while programming (especially in a corporate environment). Recognizing what sort of context is useful to give the AI without distracting it (and under what conditions it should load/forget context), I think is going to be a very valuable skill over the next few years. That's a skill you can start building now

Even if that were true you'd still need to be good at UX

The new claude/opus, esp, with additional skills is actually pretty decent with UX.

I do think that there's some meta-skills involved here that are useful, in the same way that some people have good "Google-fu". Some of it is portable, some of it isn't.

I think if you orient your experimentation right you can think of some good tactics that are helpful even when you're not using AI assistance. "Making this easier for the robot" can often align with "making this easier for the humans" as well. It's a decent forcing function

Though I agree with the sentiment. People who have been doing this for less than a year convinced that they have some permanent lead over everyone.

I think a lot about my years being self taught programming. Years spent spinning my wheels. I know people who after 3 months of a coding bootcamp were much further than me after like ... 6 years of me struggling through material.

> in the same way that some people have good "Google-fu"

or, perhaps, in the same way that google-fu over time became devalued as a skill as Google became less useful for power users in order to cater to the needs of the unskilled, it will not really be a portable skill at all, because it is in the end a transitory or perhaps easily attainable skill once the technology is evenly distributed.

Perhaps, but in Google's case that's, what, 10 years of value I got out of knowing how to write good searches? Probably more honestly.

Everything is temporary to some extent.

Are the early tricks for LLMs still useful today?

I mean the high level stuff is still there right? Be straightforward, leave the right kind of pointers into the thing, say the right kind of things.

But... I guess nowadays you can be vague and it'll get the gist of it.

I think the AI-coding skill that is likely to remain useful is the ability (and discipline) to review and genuinely understand the code produced by the AI before committing it.

I don't have that skill; I find that if I'm using AI, I'm strongly drawn toward the lazy approach. At the moment, the only way for me to actually understand the code I'm producing is to write it all myself. (That puts my brain into an active coding/puzzle solving state, rather than a passive energy-saving state.)

If I could have the best of both worlds, that would be a genuine win, and I don't think it's impossible. It won't save as much time as pure vibe coding promises to, of course.

> I think the AI-coding skill that is likely to remain useful is the ability (and discipline) to review and genuinely understand the code produced by the AI before committing it.

> I don't have that skill; I find that if I'm using AI, I'm strongly drawn toward the lazy approach. At the moment, the only way for me to actually understand the code I'm producing is to write it all myself. (That puts my brain into an active coding/puzzle solving state, rather than a passive energy-saving state.)

When I review code, I try to genuinely understand it, but it's a huge mental drain. It's just a slog, and I'm tired at the end. Very little flow state.

Writing code can get me into a flow state.

That's why I pretty much only use LLMs to vibecode one-off scripts and do code reviews (after my own manual review, to see if it can catch something I missed). Anything more would be too exhausting.

I've had reasonable results from using AI to analyse code ("convert this code into a method call graph in graphml format" or similar). Apart from hallucinating one of the edges, this worked reasonably well to throw this into yED and give me a view on the code.

An alternative that occurred to me the other day is, could a PR be broken down into separate changes? As in, break it into a) a commit renaming a variable b) another commit making the functional change c) ...

Feel like there are PR analysis tools out there already for this :)

Don't you think automated evaluation and testing of code is likely to improve at an equally breakneck pace? It doesn't seem very far-fetched to soon have a simulated human that understands software from a user perspective.

Yup, this is why even though I like ai coding a lot, and am pretty enthusiastic about it, and have fun tinkering with it, and think it will stick around and become part of everyday proper software development practice (with guardrails in place), I at least don't go telling people they need to learn it now or they'll be obsolete or whatever. Sitting back and seeing how this all works out — nobody really knows imo, I could be wrong too! — is a valid choice and if ai does stick around you can just hop in when the landscape is clearer!

The image generation side of the story is the prophecy.

I can confidently say that being able to prompt and train LoRAs for Stable Diffusion makes zero difference for your ability to prompt Nano Banana.

And most artists using the tools are still training LoRAs for Flux, Qwen, ZIT/ZIB, etc. Nano Banana is a useful tool, but not for the best work.

> Claude already does this for code. Id be amazed if nano banana doesnt.

Nano Banana is actually a reasoning model so yeah it kinda does, but not in the way one might assume. If you use the api you can dump the text part and it's usually huge (and therefore expensive, which is one drawback of it. It can even have "imagery thinking" process...!)

And if you can never catch up, how would someone new to the game ever be a meaningful player?

If you’ve never driven a model T, how would you ever drive a corolla? If you never did angular 1, how would you ever learn react? If you never used UNIX 4, you’ll be behind in Linux today. /s

>if you don't learn how to vibecode now you'll never ever be able to catch up

There's a dissonance I see where people talk about using AI tools leading to an atrophy of their abilities to work with code, but then expecting that they need no mastery to be able to use the AI tooling.

Will the AI tooling become so much better that you need little to no mastery to use it? Maybe. Will those who have a lot of fundamentals developed over years of using the tooling still be better with that tooling than the "newbs"? Maybe.

That's my take. I know LLMs arent going away even if the bubble pops. I refuse to become a KPI in some PM's promotion to justify pushing this tech even further, so for now I don't use it (unless work mandates it).

Until then, I keep up and add my voice to the growing number who oppose this clear threat on worker rights. And when the bubble pops or when work mandates it, I can catch up in a week or two easy peasy. This shit is not hard, it is literally designed to be easy. In fact, everything I learn the old way between now and then will only add to the things I can leverage when I find myself using these things in the future.

There is a huge amount of superstition around prompting. I've copied and pasted elaborate paragraph long results and then gotten. Same or better results with only a few words.

People write long prompts primarily to convince themselves that they're casting some advanced spell. As long as the system prompt is good you should start very simply and only expand if results are unsatisfactory.

FOMO is hell of a drug.

I think there's something to this, but I also there there's something to the notion that it'll get easier and easier to do mass-market work with them, but at the same time they'll become greater and greater force multipliers for more and more nuanced power users.

It is strange because the tech now moves much faster than the development of human expertise. Nobody on earth achieved Sonnet 3.5 mastery, in the 10k hours sense, because the model didn't exist long enough.

Prior intuitions about skill development, and indeed prior scientifically based best practices, do not cleanly apply.

Exactly. If it’s so easy (which is the point) then there’s no risk at all. Just pick it up if/when it’s definitely useful.

Model improvement. But certainly also the cli tool itself. That's where all the planning takes place

It's like some companies with huge interests are spreading FOMO, isn't it?

knowing how to properly use AI is a skill, there are new tools, new patterns, new primitives etc. you will be unpracticed.

great stuff; I've had almost exactly the same experience. I think blow-by-blow writeups like this are a sorely needed antidote to the hype

I started having a much easier time with mathematics when I realized and got comfortable with this idea. In hindsight it should've been obvious to me as a programmer - when I'm building something, I don't ideate in terms of individual lines of code, after all

yeah, this is what i was trying to get at with that notion of "proof-affinity"; imo a well-structured codebase is one in which you can easily prove stuff to yourself about code you didn't necessarily write

yes, what i had in mind were more proof sketches than proofs

I was thinking the same thing!

In any other industry the “worker class” would be sabotaging the machines.

In the merry software world, the challenges of improving our potential replacements are far too interesting and satisfying to leave room for any worry about consequences! :)

not launched yet! I will put up a post when it launches; coming in a few months!

Part 1 is at https://the-nerve-blog.ghost.io/baking-the-y-combinator-from...

With thread https://news.ycombinator.com/item?id=43636230

"And yes, cheating has always existed. But this isn’t traditional cheating. It’s ambient, platform-approved, investor-funded cognitive offloading." really appreciated this bit, it's insane how much some of these vendors equivocate when you call them out on this kind of thing

yeah agreed, I think there are plenty of ways to live a successful and fulfilling 'linear' life