[bruce511]

I saw someone use the term "orchestration", which seems to be the word for building the software using LLM tools.

It made me think of the conductor, seemingly the most skillless job in the orchestra. All you do is wave the batton, no need to ever play a instrument. If LLMs are doing the hard part (writing code) then we can be the conductor waving the batton.

But of course the visuals are misleading. Being conductor doesn't take the least skill, it takes the most. He hears every instrument individually, he knows the piece intimately, and through his conducting brings a unique expression to a familiar work.

LLMs have made the musician part automated. They'll play whatever you want. No doubt a powerful tool in the hands of a skilled conductor. And a incredible tool for someone who can't play to generate music for themselves.

There's no shortage of "I built it and they won't come" posts here on HN, predating LLMs by decades. Because code has never been the hard part of "software as a business ". LLMs have driven this point home. Code has never been cheaper. Business has never been harder.

[Eddy_Viscosity2]

> Being conductor doesn't take the least skill, it takes the most.

I agree with the gist of your comment, but I have to push back on the above statement. Conducting an orchestra is a different skillset than playing virtuoso violin, but it is not more difficult or more important. Its just different. The same applies to any leadership or management position. A very skilled orchestra can in even hide the fact that the conductor is a bit crap. Same with a company or sports team performing so well that they overcome the weaknesses of a lackluster manager. Even though they will still often get the credit.

[estimator7292]

Conducting an orchestra is not a mechanical activity. In many/most cases, the conductor is doing a live mix of the piece. They control the tempo of the whole orchestea, the volume and accent of different sections and players. They cue in percussion and embellishments. A conductor must know and fully understand the entire score being played. That's upward of a dozen musical threads peing played by 20, 30 people all at once. A conductor's job is to hear each one of these threads individually and simultaneously to shape the music into the final performance they want.

If a conductor's job can be reduced to a metronome, why hasn't it? I've had a credit card sized metronome in my instrument case for 15 years. Most professional musicians carry metronomes. We've had perfectly accurate metronomes for something like 500 years, so why is "conductor" a profession at all?

[thechao]

Vibecoding is the feeling of coding. It's the same feeling people have when they say they can see the picture in their head, but can't quite draw it.

[ffsm8]

If you're talking about the original vibe coding, sure.

But there are many ways to apply LLMs in the development flow.

Only specifying features broadly is like a product manager might is definitely highly luck dependent wrt how buggy it will turn out.

But understanding the feature and determining what needs to be done broadly, then ask the LLM to do so and verify after if the resulting change makes sense according to your mental model of the software is definitely not that.

Also, I disagree with your implied message. I frequently struggle to articulate solutions even if I know how they'd work

This should apply to art even more, because art is strongly supported by emotions - and people may know the feeling of the emotion (of the image), but not have an explicit framework for it yet

[theshrike79]

People are trying to use Vibe Engineering for when you know what needs to be done and how, but are using an LLM as a tool to write the code faster and more efficiently.

The OG definition of Vibe Coding is just playing a client who wants $thing, but doesn't need how to write a line of code.

[ffsm8]

This is the "og definition" of vibe coding

https://x.com/karpathy/status/1886192184808149383?lang=en

He knows how to code, as such your personal definition does not agree with how the term was coined.

Now, 1 year later and people interpret a lot into the term.

in that context I could accept your perspective to that term, but it's certainly not the original meaning

[theshrike79]

True, the original-original by karpathy was more Vibe Engineering, but that term ran away from his definition real fast. =)

[gpi]

In other words the blind leading the blind

[keeda]

Or, if you focus on the "slop" aspect of AI, the bland leading the bland ;-)

[Forgeties79]

> LLMs have made the musician part automated. They'll play whatever you want

I like your metaphor even as someone who can be a bit skeptical of the overly broad promises of LLM’s/AI. But I do think this statement is too generous. It implies way too much actual musical ability. It also means that everything I can imagine musically is possible which it just isn’t, as there are limitations just like with real musicians.

If we want to really make the metaphor work, it’s an orchestra full of very informed people who have read a lot about music and have an idea of what their instrument should sound like and can even make whatever they’re holding sound like the appropriate instrument most of the time sort of. With our direction, our “conducting,” their success goes up.

But ultimately: they aren’t real musicians, they aren’t holding the right instruments, and they haven’t actually been taught how to read music. They are just often good at sort of making it work in a way that approximates what we want.

[bruce511]

Yes, I agree, the musicians aren't mystros. And their technique could use improvement.

But I think the analogy holds (from an output point of view), the musicians will continue to improve, and some sections play better than others. The overall effect is "pleasing" although perhaps not concert quality.

[Forgeties79]

Yeah that I definitely agree with. Appropriately emphasizes how important your input is.

[supriyo-biswas]

I agree, and the corollary of this would be that the most senior engineers (who might be at a staff/principal level at a given company) who have the most amount of domain knowledge, deep understanding of various software architectures, and a product/customer oriented mindset may stand to benefit the most from AI-assisted coding, despite some narratives being peddled around by executives that they could do without senior engineers.

Unfortunately, for junior engineers the CS path has likely become more arduous, and we'd probably see something more of a doctor-like career path for CS students, where they specialize to obtain deeper architectural knowledge, before receiving employment.

[drivebyhooting]

But also the market for conductors is very small. There are 100 musicians but only one conductor in an orchestra.

So what you wrote does not bode well for the profession.

[graemep]

One likely impact of LLM coding is a huge increase in the amount of custom software as it will become cheaper. That could lead to more work, not less, just with a different skill set.

[bruce511]

True. The market for "coders" will likely go down. The market for developers will remain the same (which means go up, the market for developers has always gone up.)

[skybrian]

This "orchestration" software is about people trying to increase productivity by running many instances of a coding agent on the same project, without stepping on each other too much. It doesn't seem to be fully baked yet. A "shared nothing" architecture where you work have each instance work on a distinct project seems simpler if you want to spin more plates.

[bicepjai]

Conductor of an orchestra and current skillet of managing a coding agent feels intuitive to me which addresses understanding the differences in management and skill set. Great analogy.

[solumunus]

> Business has never been harder.

Really though? That seems completely wrong.

[sublinear]

So then why did MIDI not replace musicians and conductors many decades ago? Why do we even bother thinking in terms of sheet music, or programs in terms of code?

[tjr]

It kinda sorta did. Decades ago, all music was played by live players. Today, there are lots of albums, lots of background music on television, radio, etc., that is made mostly or entirely using MIDI-controlled virtual instruments. No longer do you need to book an actual chamber orchestra for a little 30-second spot on some cooking show.

So those musicians are no longer getting booked for that bit of music. Instead, one person produces it in their home studio. But, there’s now an industry for creating software tools that support that workflow, and there are a lot more opportunities for such music than there used to be. The amount of music used in background spots on television is astounding.

Things changed. Some jobs diminished (studio players?) or went away altogether (music copyists?). But new work came into existence.

[sublinear]

Yeah my point was that there's not much existing software within a business that's the equivalent of an ad jingle, unless you really split hairs and start counting excel macros or something.

Will there be new software like that? Maybe, but you'll never hear about it. Not only because it's throwaway code, but because the best interface is probably no code at all. The chatbot will instead spin up a VM behind the scenes and never even show the code it generated unless you dig for it.

[tjr]

On the other hand, if there is budget available, like on real movies and bigger television projects, real musicians are still used. And across the board, except for musical styles that explicitly call for electronic sounds, most people agree that using live players would be preferred if only they had the time and money.

I wonder if there’s any parallel to that in software?

[sublinear]

I think the equivalent to "live players" are frontend app devs.

It's a deeply unpopular opinion around here, but if a human has to interact with anything that's where most of the effort and budget is going to go. They're still the "rock stars".

That skill set is not merely writing code. It's more about collaboration with all the stakeholders and making a ton of deliberate decisions and compromises. It doesn't matter how "good" an LLM is at writing code for the web. That's subjective, and that's my point. We've had all kinds of no-code solutions for a very long time.

An experienced frontend dev is necessary when the project isn't just for other devs or internal use.