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.
We'll see which one it is in a few months.
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 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.
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.
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.
It's like saying if you don't learn to use a smartphone you'll be left behind. Even babies can use it now.
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
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.
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.
Everything is temporary to some extent.
But... I guess nowadays you can be vague and it'll get the gist of 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 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.
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 :)
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.
Using nano banana does not require arcane prompt engineering.
People who have not learnt image prompt engineering probably didn't miss anything.
The irony of prompt engineering is that models are good at generating prompts.
Future tools will almost certainly simply “improve” you naive prompt before passing it to the model.
Claude already does this for code. Id be amazed if nano banana doesnt.
People who invested in learning prompt engineering probably picked up useful skills for building ai tools but not for using next gen ai tools other people make.
Its not wasted effort; its just increasingly irrelevant to people doing day-to-day BAU work.
If the api prevents you from passing a raw prompt to the model, prompt engineering at that level isnt just unnecessary; its irrelevant. Your prompt will be transformed into an unknown internal prompt before hitting the model.
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...!)
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.
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.
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.
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.
Oooh, let me dive in with an analogy:
Screwdriver.
Metal screws needed inventing first - they augment or replace dowels, nails, glue, "joints" (think tenon/dovetail etc), nuts and bolts and many more fixings. Early screws were simply slotted. PH (Philips cross head) and PZ (Pozidrive) came rather later.
All of these require quite a lot of wrist effort. If you have ever screwed a few 100 screws in a session then you know it is quite an effort.
Drill driver.
I'm not talking about one of those electric screw driver thingies but say a De W or Maq or whatever jobbies. They will have a Li-ion battery and have a chuck capable of holding something like a 10mm shank, round or hex. It'll have around 15 torque settings, two or three speed settings, drill and hammer drill settings. Usually you have two - one to drill and one to drive. I have one that will seriously wrench your wrist if you allow it to. You need to know how to use your legs or whatever to block the handle from spinning when the torque gets a bit much.
...
You can use a modern drill driver to deploy a small screw (PZ1, 2.5mm) to a PZ3 20+cm effort. It can also drill with a long auger bit or hammer drill up to around 20mm and 400mm deep. All jolly exciting.
I still use an "old school" screwdriver or twenty. There are times when you need to feel the screw (without deploying an inadvertent double entendre).
I do find the new search engines very useful. I will always put up with some mild hallucinations to avoid social.microsoft and nerd.linux.bollocks and the like.