Will Engineering Become a "Hobby"?
Hello!
Today I would like to reflect on vibe coding (that is, having AI build software for you automatically) and the future of us engineers.
For the record, I have not reached any binary conclusion about whether we should build things ourselves or leave it all to AI through vibe coding.
What follows is the meandering record of a thought process that keeps going back and forth.
The Changing Nature of "the Joy of Making"
First, about the term vibe coding.
In February 2025, Andrej Karpathy (a founding member of OpenAI) popularized the term "vibe coding."
In a post on X (formerly Twitter), he described it as
"fully giving in to the vibes and forgetting that the code even exists"
.
In other words, it refers to a new style of development in which you generate code through natural language with an LLM as your partner.
The productivity is undeniably overwhelming.In Y Combinator's Winter 2025 batch, according to the accelerator itself, roughly 25% of the participating startups had 95% of their code generated by AI (TechCrunch, March 6, 2025).
Never mind weekend prototypes—real products are being born from nothing but conversations with AI.
And yet I cannot shake the feeling that something is being lost. Where did that sense of fulfillment we used to get from writing code go?
The Self-Efficacy Paradox
The first thing you feel when you start vibe coding is
an overwhelming sense of omnipotence
.
Say "build me a Twitter clone" and a working one appears in minutes.
Ask for "an image classification app using machine learning" and TensorFlow or PyTorch code materializes like magic. Projects that used to take weeks are finished in hours. It feels like acquiring a superpower.
Behind this omnipotence, however, a quiet anxiety spreads. It is the feeling of dependence:
"without AI, I can't do anything"
.
Just as constant calculator use erodes mental arithmetic, could growing accustomed to vibe coding erode even the ability to write basic code? This worry is not unfounded.
In fact, many engineers have been stunned to notice the fact that
"lately, I haven't written any code from scratch"
now applies to them.
Self-efficacy is a concept from psychology. It refers to "the conviction that you can successfully carry out the actions a situation requires."
In traditional programming, we cultivated this self-efficacy by accumulating small successes. You started with "Hello World" and gradually became able to write more complex programs. Along the way, the conviction that "I can do this" deepened.
Self-efficacy in vibe coding has an entirely different character. On the surface there is a strong sense of "I can build anything." But that is not confidence in your own abilities; it is merely trust in a tool called AI. If the AI goes down, if you hit API limits, or if you can no longer pay the fees, that sense of efficacy vanishes in an instant.
It is like a driver who has become completely dependent on a self-driving car and can no longer drive manually. You will certainly reach your destination. But the feeling that "I am the one driving" is lost forever. And when the moment comes that you must grab the wheel yourself, you no longer remember how.
Prompt engineering is drawing attention as a new skill. It is true that extracting the output you want from AI takes technique: providing the right context, making constraints explicit, giving instructions step by step. It is a respectable skill, yet somehow ad hoc. It is an accumulation of rules of thumb—"asking it this way worked"—and I wonder if I am the only one who feels it lacks the sense of building up into systematic knowledge.
In traditional programming study, we memorized language grammar, understood algorithms, and learned design patterns. That knowledge accumulated and led to understanding more advanced concepts.
Even more serious, perhaps, is the loss of "understanding."
Why does AI-generated code work?
Cases of continuing to use it without deeply understanding the mechanism
seem to be increasing.
Karpathy himself has said that "the code grows beyond my usual comprehension." That may be efficient, but it also shakes our identity as engineers.
Engineers of the past could explain every single line of the code they wrote. What each variable represented, what role each function played, how the overall architecture was designed—they grasped all of it.
This
"complete understanding" was precisely the source of an engineer's confidence
.
In the era of vibe coding, that kind of confidence is impossible. What is required instead may be a certain resignation: "accepting what you do not understand."
Interestingly, some of the younger engineers around me see no problem at all in this situation. For them, AI is an ordinary tool that has existed from the start. Just as the calculator generation feels no need for mental arithmetic, the vibe coding generation may feel no need to "understand everything."
But the essence of self-efficacy lies in "accomplishing something through your own abilities." And the definition of "your own abilities" is being rewritten before our eyes. Using AI skillfully is certainly an ability of your own. But is that alone enough? No one yet has the answer to this question.
Craftsmanship vs. Pragmatism
"This code works, but it isn't beautiful."
Words like these used to be common in code reviews. Working was the bare minimum; beyond that, we demanded readability, maintainability, extensibility, and elegance. We agonized over a single variable name, fussed over consistent indentation, deleted unnecessary comments, and wrote the necessary ones precisely. That was the engineer's craftsmanship.
In the world of vibe coding, this value system is shaken to its foundations. Is there any meaning in demanding "beauty" from AI-generated code?
For that matter, a human may never even read that code. The next fix, and the feature after that, will all be done by AI anyway.
From a business perspective, vibe coding is overwhelmingly the correct choice. Development timelines shrink dramatically, and costs drop substantially. Build a prototype quickly, watch the market's reaction, and if it fails, throw it away and move on. Running this cycle at high speed is what modern business demands. While you are polishing beautiful code, your competitors are shipping their product.
But the hearts of many engineers cannot keep up with this rationality. It may resemble what artisans felt when their handmade products were replaced by machine manufacturing. Yes, the machine is faster, cheaper, and more consistent in quality. But the joy of making each piece by hand is gone.
The concept of "technical debt" is also being redefined by vibe coding. Traditionally, code that was "hard to understand," "hard to modify," or "built on outdated techniques" counted as debt. But in a world where AI can always generate fresh code, that definition loses its meaning—because the very concept of debt presupposes that humans understand and modify the code.
The sense of responsibility for quality is changing too. You naturally feel responsible for code you wrote yourself. A bug is your mistake; poor performance means your design was poor. But can you feel the same responsibility for code an AI generated? Isn't there, somewhere in your heart, the excuse that "the AI wrote it that way"?
Development practices like test-driven development and pair programming are also having their significance questioned. These practices aimed to raise code quality, share knowledge, and catch errors early. But in vibe coding, AI does all of this instantly. Perhaps there is no longer any point in two humans pair programming.
Even so, craftsmanship cannot be dismissed entirely. For truly difficult problems—for the core of genuinely important systems—deep human understanding and delicate judgment are still needed. AI can write "code that works," but it cannot explain "why this architecture is optimal." Design that deeply understands the business context, anticipates future extensibility, and accounts for the team's skill level is still something only humans can do.
Notably, even among engineers who actively embrace vibe coding—myself included—many hold on to the principle of
"writing the core parts myself"
.
It is akin to the chef who insists on making the dashi stock themselves, or the painter who insists on painting the crucial passages with their own hand—an artisan's insistence.
Pragmatism (the stance of valuing what actually works over theory or ideals—"if it runs, it's fine") and craftsmanship (the artisan's spirit) may not necessarily be at odds. If anything, precisely because this is the vibe coding era, the judgment that "this part should be written by a human" may itself be the new form of craftsmanship. Handcrafting everything is not artisanship; knowing when to use the machine and when to work by hand—that is the modern artisan's craft.
To be capable of that discernment, however, you must first be able to work by hand. Can a generation that has only ever known vibe coding acquire that yardstick? How will the tradition of craftsmanship be passed on?
Or perhaps it does not need to be passed on at all. Just as the arrival of photography reduced demand for realistic painting, the arrival of vibe coding reducing demand for traditional coding skills may simply be historical inevitability. The question is whether we are prepared to accept that change.
Redefining the Layers of "Understanding"
What is "understanding" in programming? Until now it was relatively clear: know the types of variables, understand how loops behave, grasp memory management, analyze algorithmic complexity. Stacking up understanding from low level to high level—that was how an engineer grew.
Vibe coding is fundamentally changing this hierarchy of understanding. Perhaps we no longer need to understand implementation details. What matters instead is understanding at a higher level of abstraction. But what, concretely, does that "higher level of abstraction" mean?
Let's lay out the layers of understanding again. At the lowest level is understanding of code grammar and syntax: how to declare variables, how to write functions, the syntax of conditionals. These are the fundamentals of the fundamentals. In vibe coding, this level of understanding is delegated to AI.
At the next level is understanding of algorithms and data structures: the differences between sorting algorithms, the properties of trees, how hash tables work. This knowledge mattered as the foundation for writing efficient programs.
Higher still is understanding of design patterns and architecture: the MVC pattern, microservice architecture, event-driven design. These have served as guideposts for building large systems. Even in the vibe coding era, this level of understanding may remain important.
After all, whether to tell the AI "build it with microservices" is a judgment a human must make.
At the highest level is the bridge between business requirements and technology: the ability to understand customer needs and translate them into technical solutions. This level has, if anything, grown more important because of vibe coding. AI cannot decide "what to build." That will forever be the human's role.
But here lies a big problem.
Can high-level judgment truly exist without low-level understanding?
Can you judge whether an architecture is good or bad without knowing the implementation details? Isn't that like an architect who doesn't know the properties of their building materials?
That said, at a certain company I knew, they were already debating "architects don't necessarily need programming experience" some fifteen years ago—I nearly fell out of my chair.
Now, traditional engineering education built understanding bottom-up: solidify the fundamentals first, then layer applications on top. This methodology cultivated deep understanding and sound judgment. The vibe-coding-native generation, however, will learn top-down: start from business requirements and partially understand the lower levels as needed.
The advantages of this approach are clear: faster learning, more practical, value produced right away. But the lack of systematic knowledge may hinder innovation.
Truly innovative software is born from deep low-level understanding. Without low-level understanding, you cannot build genuinely awesome software. Of this I am certain.
Consider database optimization as an example. In vibe coding, ask "make this query faster" and the AI will add indexes or rewrite the query. But without understanding why that makes it faster, you will never notice the fundamental design problems. You can perform surface-level optimizations, but not essential improvements.
From a security perspective, too, lack of understanding is dangerous. If AI-generated code contained a SQL injection vulnerability, would you notice it? Ask the AI to "make it secure" and it will apply countermeasures—but can you judge whether those countermeasures are sufficient?
On the other hand, trying to understand everything may no longer be realistic. The modern software stack is simply too complex. Frontend frameworks, backend services, databases, cloud infrastructure—understanding all of it deeply is close to impossible.
Vibe coding may be one answer to this "limit of understanding": give up on understanding everything and concentrate only on the parts that matter. That may not be defeat but adaptation.
The problem is who decides what the "parts that matter" are, and how. Will the market decide? Will each engineer decide for themselves? Or will AI come to decide even that?
The hierarchy of understanding is not fixed. It is constantly redefined as technology evolves. Vibe coding is merely accelerating that redefinition. What is asked of us may be to accept this change while discerning what must not be lost.
The Generation Gap and the Future
"Back in the day there were no IDEs—we wrote code in vi or emacs." Say this to young engineers and they give you a look of disbelief (more like, "what even is that?"). In the same way, "back then we wrote all our code by hand" may become a funny story in the future. Technological evolution has always produced generation gaps. Vibe coding is making that gap larger than ever.
Imagine an engineer joining the workforce as a new graduate in 2027*.
*For convenience, we will call those just starting to code "the young generation" and those who have been coding for years "veterans."
Many of them will have used vibe coding as a matter of course at university. Assignments, graduation projects—all built through dialogue with AI. To them, writing code line by line may look like some ancient technique, like carving characters into stone tablets.
Meanwhile, veteran engineers with 10 or 20 years of experience harbor complicated feelings: the fear of skills honed over many years becoming obsolete, the difficulty of adapting to a new way of working, and above all the sense that the values they cherished are being repudiated. These mix together to produce resistance to vibe coding.
However, treating this generation gap as a simple old-versus-new conflict is a mistake.
The reality is more complex. Some veteran engineers embrace vibe coding enthusiastically. Precisely because of their long experience, they can judge the quality of AI's output and put it to proper use.
Conversely, some in the younger generation feel the desire to "learn from the fundamentals."Anxiety about depending entirely on AI, a hunger for essential understanding, and the desire to become a "real engineer". These drive them toward traditional learning.
Debates are happening in training settings as well. What should programming education teach? Should it start, as before, with variables and conditionals? Should it teach vibe coding from the outset? Or should it teach both in parallel?
One instructor criticizes: "Skipping the fundamentals and starting with vibe coding is like teaching math starting from the calculator." Another counters: "What matters is the experience of building something that actually works—the means don't matter." There is no correct answer to this debate.
Because we have never properly witnessed how engineers of the vibe coding era grow, and we do not yet know what works best.
Corporate hiring criteria are wavering too.
Will coding tests still mean anything going forward? How much value remains in quizzing candidates on algorithms? The code on someone's personal GitHub account may have been written by AI.
What has come to be emphasized instead is problem-solving ability, communication skills, and the ability to use AI effectively. But there is no established method yet for evaluating these.
For example, the value of "effort" is shifting. Traditionally, wrestling with a hard bug was effort, and it was growth. For the vibe coding generation, effort means devising better prompts and steering the AI well. Neither is right or wrong, but the difference is affecting communication in the workplace.
Predicting the future is difficult, but several scenarios are conceivable. In one, vibe coding becomes fully mainstream and traditional coding survives only as a specialty practiced by a few experts. In another—a topic already discussed in some circles—the theory that AI-driven vibe coding breaks down at scale proves out, its limits become clear, and a hybrid with traditional methods takes hold. Or an entirely new third path may emerge.
Whichever scenario unfolds, passing knowledge and skills between generations matters. The veterans' deep understanding and the young generation's fresh thinking—if the two can respect and learn from each other, engineering in the vibe coding era will be all the richer. The question is how to build that bridge.
The Need for "Grip"
Even while nearly being swept away by the vibe coding wave, many engineers intuitively sense one thing: the importance of
keeping a "grip" on what the code contains
. Perhaps complete understanding is unnecessary. But understanding nothing at all is not an option either. Why does maintaining this middle ground—an adequate "grip"—matter?
Where Responsibility Lies - In the End, a Human Answers
An outage hits production. Complaints pour in from users. Your boss demands, "What is going on?" At that moment, you cannot answer, "The AI wrote the code, so I don't know."
Legally, ethically, and commercially, final responsibility rests with humans. AI is a useful tool, but it cannot take responsibility. In a lawsuit, "it was the AI's fault" will not fly. When a data breach occurs, "the AI wrote that code" settles nothing.
When one financial company adopted vibe coding, it established an interesting rule: "AI-generated code is treated as if written by the human who reviewed it." It looks strict at first glance, but it is really only natural—because the one who approved deploying that code to production was, in the end, a human.
Keeping a grip means, at minimum, grasping what the code is doing and what risks it carries.
You need not understand every line, but you do need to understand the data flows, the integrations with external services, and the security considerations.
The Wellspring of Creativity - Is Creation Without Understanding Possible?
Truly innovative solutions are born from deep understanding. Ideas that transcend existing frameworks, approaches that overturn conventional wisdom—these do not come from surface-level knowledge.
For example, Git's distributed version control was born precisely because of Linus's deep understanding of systems. The virtual DOM concept behind React and Vue could only be conceived by someone who deeply understood the browser's DOM rendering mechanism. These innovations would never have emerged from merely writing "code that works."
Vibe coding excels at combining existing patterns. But creating something genuinely new requires human creativity. And exercising that creativity requires understanding the essence of the technology—starting, as in the examples above, "from the low level."
Keeping a grip lets you push back on the AI's suggestions: "Why this way?" "Is there another approach?" This critical thinking is the starting point of innovation. Surrender everything to AI, and I believe that opportunity is lost forever.
Troubleshooting: When AI Has No Answer, Who Does?
An unexplained performance degradation is unfolding in production. Ask the AI and it only proposes "general optimization techniques." The logs yield only surface-level information. Who solves the problem then?
Real troubleshooting demands a good deal of intuition and experience.
"I've seen this pattern before." "Something smells off about this behavior." Sensations that resist being put into words—the programmer's sixth sense.
These are born from the experience of wrestling with code.
Keeping a grip is also insurance for when trouble strikes. Even without complete understanding, it is important to know where to start investigating and what to suspect—to hold on to those instincts.
But Even This May Be Transitional
So far I have argued for the importance of grip.
But honestly, this too may be a transitional phenomenon. If AI evolves further, troubleshooting, innovation, even judgments about responsibility—AI may come to handle all of it.
Indeed, given the pace of AI's evolution, the value of humans understanding code is declining by the day. A skill considered essential today may be unnecessary tomorrow. That possibility cannot be denied.
Even so, for now—and at least in the near future—keeping a grip has meaning. And not merely for practical reasons. It also touches a fundamental human desire: to understand what you are making.
An architect wants to understand a building's structure; a chef wants to know the properties of ingredients; a musician wants to learn how their instrument works. In the same way, an engineer wanting to understand code is a natural desire. It may be an expression of our humanity, beyond efficiency or productivity.
The degree of grip will vary by person, by project, by season. What matters is choosing that degree consciously—not letting understanding slip away as you drift, but discerning the level of understanding you need and making the effort to maintain it.
That effort may go unrewarded. People may laugh and call it old-fashioned. And that is fine. Because this touches on our pride as engineers and our dignity as human beings.
Will Engineering Become a "Hobby"?
Up to this point I have rambled through the changes vibe coding brings and the various ways of facing them: the dilemma of efficiency versus understanding, the generation gap, the search for new ways of working. Taking all of it together, one question surfaces.
Could it be that traditional engineering will end up becoming a "hobby"?
Something Beyond Business Rationality
From a purely business standpoint, vibe coding's superiority is obvious: development speed, cost reduction, lower barriers to entry. In the face of these advantages, saying "but I want to write it myself" may be nothing more than sentimentality devoid of economic rationality.
The "Joy of Making" Beyond Efficiency May Be Human Nature
Why do people want to make things with their own hands even when they know it is inefficient? People who grow vegetables in a home garden, build furniture on weekends, knit sweaters by hand. Economically, these activities are irrational. Yet many people find value in them.
Perhaps it is because the act of "making" is an essential human desire. As the term Homo faber ("man the maker") suggests, humans have expressed themselves by making tools, reshaping their environment, and creating. This desire does not vanish because of efficiency.
Programming, too, is one modern expression of this "joy of making." Creating something from nothing, giving shape to ideas, influencing the world—it lies on the continuum of fundamental human activity that stretches back to primitive toolmaking.
But Can We Still Call It a "Job"?
Here lies the hardest problem. Writing code as a hobby and practicing engineering as a profession are not the same. Companies demand efficiency and results. Customers demand speed and low cost.
The market mercilessly weeds out the inefficient.
Perhaps future engineers will split into two types: the "product engineer," who wields AI to produce value at high speed, and the "code artist," who possesses deep understanding and artisan skill.
The former will be valued by the market and well compensated. The latter may serve niche demand, or may work purely for personal satisfaction.
The Struggle Continues...
In the end, there is no clear answer to the relationship between vibe coding and traditional engineering. It is a complex problem entangling personal values, social demand, and the evolution of technology.
All we can do is watch this change closely, find our own footing, and adjust it flexibly. Those who embrace vibe coding wholesale, those who stubbornly refuse it, those who search for a middle path—I believe each of them is right.
Engineering may become a "hobby."
But perhaps that is not a bad thing.
A hobby is something you do purely because you love it, beyond profit and loss.
Personally, even if I were never paid a single yen, I would probably keep coding by hand—purely because I enjoy it too much to stop. As for doing it as a "job," though, I have already made the compromise of incorporating vibe coding into my work.
The struggle continues.
No answer arrives.
But I think that is fine.
Because agonizing over it is itself part of the humanity that only we humans possess.
A line close to this was delivered in my favorite TV drama, "Haken no Hinkaku" (The Pride of the Temp), by Haruko Omae (played by Ryoko Shinohara), too.
Precisely because we live in an age when AI can produce perfect answers, there may be value in humans who are imperfect, who waver, and who agonize.
Living through the era of vibe coding, we stand at a major turning point in the history of technology. It is unsettling and exhilarating at once. Longing for the past and fearing the future are both natural feelings. What matters is acknowledging those feelings, facing them, and moving forward.
The happiness of engineers is certainly wavering.
But I believe we will surely find new forms of happiness as well.
And of course, the ones who will find them are not AI, but we humans ourselves.
Conclusion
So there you have it—a rambling account of what I have been thinking and feeling about vibe coding lately.
Even those of us who work at an AI company feel no small resistance to handing code writing over to AI, while using it, while agonizing over it—that was the story.
No conclusion has been reached
—but through this transitional period in the transformation of software development, doubts and all, I intend to enjoy it to the fullest.
Whatever the means, whatever the form, we will keep creating the nicest software in the world—software that delights its users.
Thank you, as always, for reading to the end!
See you next time!
