The Skill That Matters More Than Coding: Software Composing

The term “vibe coding” has caught on. Type a description into Bolt, hit enter, and — voilà — an app appears. It sounds like magic. No skill required.

Alexander Berger, COO of Bolt, pushes back on that framing. “It’s extremely clear to me that anybody can do it,” he says. But that doesn’t mean nobody needs to learn anything.

The skill isn’t coding. It’s something he calls “software composing,” and it’s surprisingly teachable.

The Problem with “Vibe Coding”

“Vibe coding” implies throwing prompts at AI and hoping something works. It feels lazy, half-baked, imprecise. That word choice matters because it shapes how people think about what this category is.

Alexander prefers “software composing” — a term he’s borrowed from Riley Brown. Composing, like music composition, requires knowledge. You need to know what you’re orchestrating. You need precision.

“If you are trying to make something significantly more complicated, then you’re going to need to do more than describe it the way that an elementary school kid would describe their game,” Alexander explains. “There is a skill set that can be developed.”

The good news: that skill isn’t software engineering. You don’t need to understand algorithms, memory management, or data structures. You don’t need years of programming experience.

What you do need is much simpler — and much more learnable.

Layer 1: Learn the Language

The biggest barrier isn’t technical. It’s vocabulary.

Product managers, designers, and engineers have a shared language. When a PM says “hero section,” a designer knows exactly what that means — the prominent banner at the top of a page. When someone mentions a “pancake menu,” it’s the three-stacked-lines hamburger icon on mobile.

If you don’t know these terms, you can’t ask for them. And if you can’t ask for them precisely, AI can’t deliver them precisely.

“I’d call it software composing, and what is that made up of? It’s multifactorial,” Alexander says. “One [skill] is: you want to get extremely good at describing very specifically what it is you’re trying to build in the language of digital products.”

The solution is deceptively simple: learn the vocabulary. Spend an hour with ChatGPT asking it to teach you the terms product people use.

What’s padding? What’s margin? What’s alignment? What’s a modal? What’s a dropdown versus a select field? These are the 50-100 terms that unlock the ability to describe interfaces precisely.

“With magic, I feel like it’s always you got to know the name of the thing and that gives you the power over it,” Alexander observes. “That is actually how it works in this space.”

Layer 2: Understand APIs

Once you can describe interfaces, the next layer is connecting your app to the outside world.

APIs are how software talks to other software. You might want your Bolt-built app to connect to OpenAI, Stripe for payments, a database, or a CRM. APIs are how you do that.

You don’t need to understand how to build an API or how the technical plumbing works. You just need to understand the concept: two pieces of software exchanging information.

“Being able to speak intelligently about APIs… you don’t need to know how to make these things, but you do need to be able to describe accurately what you want to occur inside your app,” Alexander explains.

He gives a concrete example: “If you want your piece of software that you’re building in Bolt to talk to another piece of software, let’s say OpenAI, because you want to build an AI powered app. Now, I want to connect to the OpenAI API and send the text that I put into my app to open AI and then it’s gonna send some texts back and I wanna display that here, right?”

That’s it. You need to be able to say: “I want to send data to this service and display the result.” You don’t need to know what REST means or how to authenticate or how headers work. Just the concept.

Layer 3: Know When to Stop

For simple apps — websites, lead capture forms, basic SaaS — Layers 1 and 2 are enough. You can go from idea to deployed product with just vocabulary and API concepts.

For complex enterprise software, you’ll need Layer 3: basic backend concepts. Databases, authentication, security. But even here, you don’t need to be an engineer. You need to know what questions to ask.

“There’s definitely things to learn right? And those words and phrases are a great place to start,” Alexander says. “Now when you want to start thinking about backend functionality, there’s that’s where you’ll dip into a software developer or systems architect.”

The key insight: you don’t dip in earlier. Many founders obsess over technical architecture before they’ve validated the product. With Bolt, you validate faster because the building is easier. Only when you’ve proven the idea do you bring in engineers for the complex backend work.

The Hidden Advantage: Curiosity

All three layers presume one thing: you’re willing to learn.

Alexander’s broader philosophy applies here. “If you have an objective and you’re curious about how to solve it and you’re willing to dig in and learn and ask questions of people but also very conveniently of AIs which know that stuff extremely well, that’s really all you’re gonna need to figure out everything that you’re going to need to figure out to be successful with making software in 2025.”

Curiosity beats coding ability. A non-engineer who asks good questions and learns vocabulary will outship a junior developer who assumes they already know everything.

FAQ

Do I need to know any actual code to compose software?

No. Not even HTML, CSS, or JavaScript. You describe what you want in product language. AI translates that to code. The only exception: if you’re building something so complex it requires custom backend logic beyond what Bolt can generate — then you’d need engineer involvement, but by that point you’d have a working prototype.

How long does it take to learn the vocabulary?

Alexander suggests an hour or two with ChatGPT to learn the core 50-100 terms product people use. Then you learn the rest by doing — you’ll encounter new terms as you build, ask AI to explain them, and gradually expand your fluency. It’s like learning any domain language.

What if I describe something and the AI gets it wrong?

That’s where precision matters. If your description is vague, the AI generates something vague. If you’re precise — “I want a hero section with a CTA button, not a hero section with navigation” — the AI can deliver what you need. This is why learning the vocabulary is the first skill.

Is software composing the same as no-code?

Not quite. No-code tools (like Airtable or Make) give you templates and drag-and-drop builders. Software composing is different — you’re describing custom apps to an AI. No-code is broader (includes anyone who avoids traditional coding) but less flexible. Software composing is narrower but more powerful for custom builds.

What if I’m not curious? Can I still use Bolt?

You can, but you’ll be limited to simple templates. Complex builds require learning. Alexander’s point is that the barrier to entry has dropped — you don’t need to be a “math person” or “tech person” anymore. You just need to be willing to learn the vocabulary of your domain.

Do successful Bolt builders have any background in tech?

Not necessarily. Alexander mentions his CEO’s mom built her first website with Bolt. His wife built a site for her small business. The threshold is learning vocabulary and how to think about what software does — not prior technical experience.

How is software composing different from talking to ChatGPT?

Same principle, different execution. With ChatGPT, you describe an idea and get code. You’d still need to deploy it somewhere, host it, maintain it. With Bolt, you describe it and get a deployed, live app immediately. The composing skill is the same; the delivery mechanism is different.

Will this skill become obsolete as AI gets better?

Possibly. As models improve, they might handle vague descriptions better. But right now, precision beats vagueness. Even if AI gets better at inferring intent, understanding your domain (product language, user flows, API concepts) will stay valuable because it separates people who know what they’re building from people who are just hoping for the best.