Inspired by Theo’s discussion on VoidFnC about the realities of being a software engineer in 2026.
The software industry is changing rapidly. AI tools are becoming more capable, code can be generated faster than ever, and building an application is increasingly accessible to people who previously had little or no programming experience.
At first glance, this sounds like progress. And in many ways, it is.
But there is another side to this transformation: the expectations placed on software engineers are changing, too.
Recently, I watched a video by Theo, a software engineer and creator behind the YouTube channel VoidFnC, who discusses his experience in the industry spanning more than eight years. His video, “I Hate Being a Programmer in 2026” or "gue benci jadi programmer (di tahun 2026)" in Indonesian Speech, raised several concerns about the direction of software engineering.
I found his observations worth thinking about, particularly when considering my own direction as a developer.
This article is not an attempt to present Theo’s opinions as universally proven facts. It is my interpretation of the issues he raised, combined with my own perspective on software development, independent work, and the small and medium-sized enterprises (SMEs) I want to support.
1. AI Is Changing More Than the Way We Write Code
One of Theo’s central arguments is that AI hype is no longer confined to developers discussing frameworks, programming languages, or development tools.
It has spread to product managers, designers, business owners, executives, and other people who influence software projects.
Previously, unrealistic expectations about a new framework or programming language might have remained mostly within engineering teams. Today, AI-generated demonstrations and claims about rapid application development can influence business decisions directly.
Someone sees an AI tool produce a working prototype in minutes and concludes that a production-ready application should take only a fraction of the time it used to.
The problem is that a prototype and a production application are not the same thing.
A prototype may demonstrate that an idea is possible. A production system must also deal with authentication, authorisation, data integrity, security, error handling, deployment, monitoring, maintenance, and unexpected user behaviour.
The code that appears in a demonstration is only one part of the complete system.
When decision-makers underestimate these differences, the resulting expectations can become unrealistic before the engineering team even begins working.
The issue is not that non-technical people should stay away from software. It is that decisions about engineering work should be informed by the actual complexity and risks involved.
AI can help us build faster. It does not automatically make every deadline reasonable.
2. More Code Does Not Automatically Mean More Productivity
Another important point in Theo’s discussion is the difference between producing more code and delivering more value.
AI can generate functions, tests, components, database queries, and entire features. It can also produce a large pull request in a relatively short amount of time.
However, someone still needs to determine whether that code solves the right problem, fits the existing architecture, handles edge cases, and behaves correctly under real conditions.
Writing code has never been the only difficult part of software engineering.
Understanding requirements, making architectural decisions, reviewing changes, testing behaviour, maintaining existing systems, and diagnosing production failures can consume considerable time.
AI may reduce the time needed for implementation while increasing the amount of code that needs to be understood and reviewed.
If a developer produces changes faster than a team can reasonably review them, the apparent productivity improvement may create a different bottleneck.
The situation becomes more concerning when expectations increase because AI is available, but the time allocated for testing, review, and maintenance remains unchanged.
And when something breaks in production, the responsibility does not necessarily disappear just because AI generated the code.
The engineer is still expected to understand the system, investigate the failure, and help restore it.
This is why I believe AI-assisted development should be evaluated by the quality and usefulness of the resulting software, not simply by how quickly code appears on the screen.
3. The Modern Engineer Is Expected to Do More Than Engineering
Theo also discusses how the expectations placed on engineers continue to expand.
In addition to writing software, engineers may be expected to understand product strategy, user experience, business requirements, infrastructure, security, compliance, and operational concerns.
There is nothing inherently wrong with understanding these areas. In fact, a broader understanding can make an engineer considerably more effective.
The difficulty arises when the expected range of responsibilities grows while the time available to learn, practise, and develop expertise becomes shorter.
Engineers are increasingly encouraged to take ownership of an entire product or system rather than focusing on implementation alone.
That can be valuable, especially in small teams. However, there is a difference between encouraging people to develop broader skills and expecting one person to compensate for every missing role in an organisation.
AI can help individuals work across unfamiliar areas, but assistance does not automatically replace expertise, sound judgement, or accountability.
The challenge is finding a sustainable balance between versatility and unrealistic expectations.
4. What Happens When the Junior-Level Learning Path Disappears?
Perhaps the most concerning part of Theo’s discussion is the potential impact of AI on junior developers.
Traditionally, junior engineers gain experience through relatively small tasks: fixing bugs, improving existing features, writing tests, handling simple requirements, and learning how an established codebase works.
These tasks are not merely inexpensive work for a company. They are also opportunities to develop professional judgement.
Over time, developers learn how to investigate unfamiliar systems, recognise fragile code, communicate technical trade-offs, and understand the consequences of their decisions.
AI creates a potential disruption to this process.
If a senior engineer with AI assistance can complete tasks that previously went to junior developers, a company may decide that hiring additional juniors is less attractive.
From an individual company’s short-term perspective, that decision might appear economically reasonable.
Across the industry, however, the consequences could be more complicated.
If fewer juniors are hired and fewer people receive opportunities to learn through real engineering work, where will the next generation of experienced engineers come from?
Senior engineers do not appear fully formed. They become senior by accumulating experience, making mistakes, receiving feedback, and gradually taking on greater responsibility.
AI might accelerate some parts of that journey, but it cannot guarantee that the industry will continue providing enough opportunities for people to develop the judgement required to maintain complex systems.
This is a structural concern rather than an argument that AI should not be used.
5. Two Different Directions: Product Engineering and Systems Engineering
Theo also describes two broad patterns of engineering work that may become increasingly relevant.
These are useful conceptual categories, not necessarily formal job titles.
Product-oriented engineering focuses on identifying problems, validating ideas, building minimum viable products, and iterating quickly based on user feedback.
The goal is to discover whether a solution is useful before investing heavily in it.
Systems-oriented engineering focuses on improving systems that have already demonstrated value. This may involve reliability, performance, scalability, architecture, operational efficiency, and the careful management of complexity.
The distinction matters because building the first version of a product and operating a successful product at scale are different challenges.
A small business validating a new service may not need the same architecture as a platform serving millions of users. Conversely, a system with demanding reliability requirements cannot be treated like a disposable prototype.
AI may be useful in both areas, but the engineering decisions remain different.
For me, this distinction is a reminder that there is no single development workflow or architectural approach that makes sense for every business.
The right solution depends on the problem, the risks, the available resources, and the stage of the product.
6. Theo Is Not Simply Saying That Nobody Should Become a Programmer
It is important not to misinterpret the message.
Theo acknowledges that he uses AI himself and recognises that he is part of the broader ecosystem influencing how people think about software development.
His criticism is not simply that AI is bad or that developers should return to writing everything manually.
The deeper concern is the way the industry responds to AI.
When demonstrations of rapid development become promises of dramatically increased productivity, organisations may raise expectations without adequately accounting for testing, review, maintenance, and the complexity of real systems.
The benefits of AI may be real, while the expectations built around those benefits can still become unreasonable.
Theo’s conclusion is not a straightforward instruction to avoid programming. It is closer to recognising that the profession is changing and that engineers must decide how they want to adapt to that change.
I agree that this is a difficult question, particularly for people who are still trying to establish themselves in the industry.
But I also think there is another question worth asking:
Do we all need to pursue the same version of a software engineering career?
7. My Perspective: I Would Rather Help SMEs Solve Real Problems
After considering these points, I find myself increasingly interested in building software and digital solutions for small and medium-sized enterprises rather than making a corporate engineering career my primary goal.
This does not mean that I believe all large companies are bad places to work. Nor does it mean that independent work is automatically better.
There are excellent engineering teams in large organisations, with healthy collaboration, realistic expectations, good mentoring, and strong technical practices. There are also poorly managed companies where hierarchy, office politics, and excessive workloads make otherwise interesting work difficult.
Independent work has its own problems, including unpredictable income, difficult clients, unclear requirements, and the need to manage sales and operations in addition to development.
Neither path is free of trade-offs.
What matters to me is the environment in which I can do useful work, make decisions responsibly, and maintain a reasonable degree of control over how that work is delivered.
Working with SMEs offers a different kind of relationship
Small businesses often have practical problems that do not require unnecessarily complicated solutions.
A WooCommerce store may have a slow checkout process. A business may be spending money on advertising without understanding which campaigns produce actual customers. A team may be managing repetitive administrative tasks manually because nobody has built a suitable internal tool.
These are not necessarily glamorous engineering challenges. They can nevertheless have a direct effect on a business.
My interest is in identifying these problems and building solutions that are appropriate for the business's actual needs and resources.
Sometimes that might mean improving an existing WordPress installation rather than replacing it.
Sometimes it might mean simplifying a checkout flow, fixing analytics, automating a repetitive task, or building a small application.
And sometimes the best technical decision might be not to build anything new at all.
For an SME, spending money on a sophisticated architecture that solves no meaningful business problem is not a sign of engineering excellence.
Good engineering should be measured partly by whether it solves the right problem at a cost the business can sustain.
The difference is not that SMEs are always easier
I do not want to romanticise independent work or suggest that every small business owner is easy to work with.
SMEs can have unrealistic expectations, unclear priorities, limited budgets, and clients who constantly change their requirements.
The difference I am looking for is the possibility of having a more direct relationship between the person who needs a solution and the person who builds it.
In an ideal client relationship, the business explains its problem, we discuss the available options, agree on a scope and budget, and decide whether working together makes sense.
If the expectations are realistic and the collaboration is healthy, we proceed.
If the expectations are unreasonable, the scope cannot be agreed upon, or the working relationship is clearly incompatible, I can decline the project.
My informal rule is simple: if the collaboration makes sense, let's build something useful. If it does not, there is no need to force it.
Of course, this freedom is not absolute. Independent developers still need income, and turning down work can have financial consequences. Finding good clients is itself a skill that requires time to develop.
Nevertheless, I value having more control over which problems I accept and which working relationships I pursue.
Corporate hierarchy is a different constraint
In a company, engineers operate within an organisational structure.
Managers determine priorities, leadership allocates resources, and organisational hierarchies influence which decisions can be challenged or changed.
A healthy company can use this structure effectively. Experienced leaders can provide direction, remove obstacles, support junior employees, and help teams make better decisions.
The problem arises when authority becomes a substitute for sound reasoning.
A deadline may be unrealistic, but challenging it could be interpreted as a lack of commitment. A technical concern may be dismissed because it comes from someone with less seniority. A team may be expected to deliver more without receiving the time or resources needed to do so.
In such an environment, the engineer's ability to make technically responsible decisions can be limited by organisational dynamics.
This is the aspect that makes me cautious about pursuing a corporate engineering career as my primary objective.
I do not want to spend my working life trying to satisfy expectations that are disconnected from the actual work, particularly when those expectations are reinforced by hierarchy rather than constructive collaboration.
That does not mean every company operates this way. It means that the quality of the working environment matters just as much as the job title.
If I ever join a company, I would want to evaluate how it treats engineers, handles disagreements, sets deadlines, and responds when things go wrong—not simply its reputation or size.
8. AI Should Help Us Deliver Better Solutions, Not Just More Work
My position on AI is practical.
I use AI to help build software, explore approaches, understand unfamiliar concepts, and accelerate implementation. I do not believe using AI makes the work illegitimate.
However, generating code is not the same as taking responsibility for a finished application.
A developer still needs to understand the requirements, evaluate the proposed implementation, test the result, recognise uncertainty, and be honest about what they can support.
For an independent developer serving SMEs, AI can be particularly useful because time and resources are limited.
It may help one person accomplish work that would otherwise require considerably more manual effort. That can make certain solutions more accessible to businesses with modest budgets.
But the objective should not be to accept an unlimited amount of work simply because AI makes implementation faster.
If AI saves two hours on a task, those hours can be used for testing, better communication, documentation, learning, or simply keeping the project within a sustainable schedule.
The benefit should not automatically become an excuse to double the workload.
I also have concerns about exaggerated AI marketing that suggests anyone can become an experienced engineer almost overnight or that an AI-generated demonstration proves a person is ready to manage complex production systems.
AI can lower barriers to building software. It does not eliminate the need to learn, exercise judgement, or understand the consequences of technical decisions.
We should be able to acknowledge both its genuine benefits and its limitations.
9. This Is a Career Preference, Not a Declaration That Corporate Engineering Is Dead
I want to make one thing clear: I am not claiming that becoming an engineer at a large company is a bad decision.
For many developers, a well-managed engineering organisation can provide excellent mentorship, exposure to complex systems, collaboration with experienced colleagues, stable income, and opportunities that would be difficult to obtain independently.
Those benefits matter.
My preference is simply to prioritise a different path for now.
Rather than making a corporate engineering title the ultimate measure of success, I want to focus on using software to solve real problems for businesses that need help with digitalisation.
I can still learn from open-source projects, study system design, improve my testing practices, build applications, and collaborate with other developers.
I can also continue developing my own projects while learning what it takes to turn software into something useful and sustainable.
None of those activities requires me to pretend that I have experience I do not possess. Equally, not having worked at a large technology company does not mean that the skills I have developed through building software are worthless.
The important thing is to be honest about my experience, recognise my limitations, and continue improving through real work.
Perhaps I will eventually find a company whose engineering culture suits me. If that opportunity appears, I can evaluate it on its merits.
For now, I would rather build a career around the problems I want to solve than spend too much energy trying to prove that I belong to a particular category of engineer.
Final Thoughts
Theo's discussion made me think more carefully about the relationship between AI, engineering expectations, and the future of the profession.
The most important lesson I took from it is not that programming is no longer worth pursuing.
It is that the environment in which we build software matters.
AI can make implementation faster, but faster implementation does not automatically create better products, healthier teams, or more sustainable working conditions.
Companies still need realistic expectations. Engineers still need opportunities to learn. Software still needs to be tested, maintained, and operated responsibly.
And developers do not all have to pursue the same career path.
For me, building solutions for SMEs is an appealing direction because it brings software development closer to practical business problems and gives me the opportunity to choose projects and working relationships more deliberately.
There will still be difficult clients, financial uncertainty, and plenty of technical challenges. I am not expecting an easy path.
I simply want to build useful things, help businesses make better use of technology, and develop a sustainable way to keep doing work that I genuinely enjoy.
Perhaps the goal is not to become the kind of engineer the industry happens to reward at a particular moment. Perhaps it is to become a developer who can consistently turn real problems into useful, maintainable solutions.
And if AI can help me do that more effectively, I intend to use it—without forgetting that the responsibility for the work remains mine.
This article is a personal reflection inspired by Theo's discussion on VoidFnC. The observations attributed to him are my interpretation of the video's themes, not a claim that every point represents a universally established industry fact. My own conclusions about working with SMEs reflect my preferences and priorities, rather than a claim that independent work is inherently better than employment.
Top comments (0)