Watching tasks being handed to AI, and programs taking shape from descriptions of what they should do, raises a question for me. If making things keeps getting easier, what will set people apart?
Being able to build something yourself is still a valuable skill. But if implementation takes less time and effort, knowing how to use the technology may not be enough to explain what makes someone’s work valuable.
That does not mean a good idea is all you need now. As the range of things we can make grows, deciding what to make may become harder.
What we can do is not always what is worth doing
When building a service takes a substantial amount of time and money, there is a reason to think carefully before starting. Who needs it? Does something similar already exist? How will it be run once it is finished?
If a simple description can produce something tangible, getting started becomes easier. There is real appeal in being able to test an idea quickly.
But if ease of creation becomes the reason to start, we may only ask whether something is needed after we have built it. The features might work, yet nobody wants to use them. Or we might struggle to explain how the result improves on what already exists.
That is why I think “Is there a reason to solve this problem?” may become as important as “Can I build this?” A lower barrier to execution does not automatically give us better criteria for choosing.
Getting a result is not the same as understanding it
Vibe coding brings both excitement and questions. Once the feature I asked for has been built, how can I tell whether it works properly?
For some programs, displaying a screen and responding to a button press may be enough. A service that stores personal information or handles payments calls for different checks. We also need to understand how far a failure could spread, and whether a change has broken another feature.
Rebuilding everything AI produces would defeat the purpose of automation. But trusting all of it without understanding it creates a different problem.
This is where I think learning remains necessary. We do not learn only so we can carry out every step ourselves. We also learn so we can decide what to ask for and which results to accept.
The faster we can get an answer, the more important it seems to know what to check in that answer.
If we save time, will we actually work less?
Part of automation’s appeal is the prospect of having more room in our lives. Handing off repetitive tasks could leave time to focus on something else, or simply to rest.
But the opposite is possible too. If a task that once took a day can be completed much faster, we might fill the time saved with more work instead of taking a break. An organization might expect more output from the same number of people. Individuals might keep raising their own targets.
In that situation, automation becomes a way to increase output rather than reduce work.
Technology alone will not decide which direction we take. There are also choices to make about who gets to use the time saved, and what counts as enough.
Personally, I think we need to distinguish between being able to work faster and being expected to do more. Just because the work speeds up does not mean life has to become busier too.
What we can build alone, and what we can take responsibility for
I find the prospect of being able to attempt more on our own encouraging. It could give us a chance to turn an idea into something concrete before assembling a team of specialists or committing a large budget.
Still, an easier start is not the same as easier upkeep. After a service is released, there are bugs to fix, users’ questions to answer, and changes to make as its environment evolves.
Someone ultimately has to take responsibility for what automation produces. So I think an important measure may be not just how much we have built, but what we can continue to look after.
I do not want to be pessimistic about a future in which making things is easier. It could open opportunities for people who previously lacked the resources or background to try.
But I do not want to measure those opportunities only by the number of things produced. I want to consider the whole process: understanding what is needed, judging whether it has been made properly, and remaining responsible after it is released.
As the range of things we can make grows, the question I need to ask may become simpler.
Not just whether I can build it, but why I am building it—and what I am prepared to take responsibility for.
COMMENTS