Most people think programming starts with learning a language: Python, Java, and all the syntax and rules that come with them. For a long time, that was basically true. If you could not speak the language of software, you could not really build software.
I think that barrier is starting to shift.
I have been experimenting with Claude Code skills, and what keeps striking me is that they feel a lot like programming, just expressed in a medium more people can use. Not because the work got easier. Not because rigor stopped mattering. But because more of the logic can now be written in natural language instead of hidden behind syntax.
That distinction matters.
When people hear “prompting,” they often imagine tossing a vague instruction at a model and hoping for a decent result. That is not what I mean here. A skill is closer to a behavioral program. You define what the system should do, in what order, with what inputs, under what constraints, and what kind of output counts as success. That is programming logic, even if it is written in English.
One of the clearest examples for me was building a startup idea evaluator. Someone drops in a rough idea. Usually it is incomplete, ambiguous, and messy, which is exactly what real inputs look like.
The system does not just generate one answer from one prompt. It runs a sequence. One skill turns the rough idea into structured input. Another researches the market, competition, and key risks. Another scores the idea against a set of factors. A final skill writes a decision memo with a recommendation.
What mattered was not any single sentence inside the workflow. What mattered was the design of the system: what information gets normalized first, what research happens before scoring, what criteria the memo should reflect, and what assumptions should be preserved from step to step.
That is why this feels so important to me. The logic of the system was written in language a domain expert could actually read, understand, and change. If the evaluation felt too harsh, the criteria could be adjusted. If the research step was too shallow, the instructions could be sharpened. If the final memo was missing nuance, the output requirements could be rewritten.
The hard part did not disappear. It moved.
You still need precision. You still need to think carefully about ambiguity, edge cases, failure modes, and quality standards. Vague instructions still produce vague results. Bad sequencing still creates bad outcomes. A weak rubric still gives you weak judgment.
But those are not syntax problems. They are specification problems. And that changes who gets to participate.
A lot of smart people outside engineering already know how to do this kind of work in their own domain. They know how to break a messy process into steps. They know where judgment matters and where consistency matters. They know what a strong output looks like. They know the difference between a useful recommendation and a shallow one.
Until recently, turning that kind of domain expertise into software usually required a translation layer. The marketer had to explain it to the engineer. The investor had to explain it to the product team. The operator had to explain it to someone who could turn process into code.
That translation layer is not gone, and I do not think it should disappear entirely. There is still a big role for engineers. There is still real value in formal systems, robust tooling, typed interfaces, observability, and all the things traditional software gives us.
But the line has moved.
We now have a growing class of systems where the behavior can be authored, refined, and maintained in plain language by people who understand the work itself. That is new, or at least newly practical. And I think it expands the idea of who a builder can be.
I do not think this means everyone becomes an engineer. I do think it means more people can become system designers. More people can encode judgment. More people can turn a repeatable process into something executable. More people can build without first climbing the full wall of traditional programming syntax.
To me, that is the real shift.
Programming used to be gated mostly by whether you could write valid code. Now, in at least some important cases, it is increasingly about whether you can describe a system clearly enough for a machine to carry it out.
That is still programming. It is just programming in a form that is becoming accessible to many more people.
And if that keeps improving, I think we are going to see a lot more software-like systems created by people whose real strength is not syntax, but deep domain clarity. That feels like a meaningful change in who gets to build.