No, we are not the last generation of programmers. But we may be the last generation that writes code the way we do today.
AI is not eliminating engineering. It is changing where engineering effort is applied. The mechanical act of typing syntax will matter less. Judgment, architecture, and constraint design may be the only skills that define a “programmer.” That shift is uncomfortable, especially for those of us who built our careers on handwritten code. But discomfort does not mean decline. It usually signals abstraction moving forward.
Recently, I came across an article about Markus Persson (https://tech.yahoo.com/ai/chatgpt/articles/billionaire-founder-minecraft-slams-anyone-170651191.html), the creator of Minecraft, where he said that people who use AI for coding are “incompetent or evil.” That is a strong statement. It also comes from someone who built something generational. Very few solo developers create something that shapes an entire era. That deserves respect. His opinion carries weight.
But he is not alone. The industry right now feels split.
One group has fully embraced AI. They believe it is the current state of software development. Some companies, such as Anthropic, Robinhood, Meta, OpenAI, and many others, are publicly saying a large portion, if not all, of their code is written with AI assistance. You see demos of people cloning apps in a weekend. You see bold claims about replacing engineers.
The other group rejects it entirely. In that camp, using AI means you are not a serious programmer. Real engineers write everything by hand. AI has no place in professional development.
I believe both positions miss something important.
I have been writing code since I was 18. I am 47 now, as of 2026. That is 29 years. I have written code before modern frameworks. I have seen abstraction layers rise and fall. I have lived through the shift from manual everything to layered systems built on libraries, services, and managed infrastructure.
This is not a theory for me. I can still write code by hand. I choose when to use AI tools.
And I am not defending blind prompting.
I Agree With the Purist More Than You Think
Let me say this clearly. Handwriting code builds skill.
Typing everything by hand sharpens memory.
Debugging without assistance builds depth.
Memorizing APIs, functions, and syntax builds fluency.
Struggling through a hard bug builds intuition.
There is no question that mechanical repetition strengthens you.
If someone built something like Minecraft largely by hand, of course, they value that mastery. That is earned. That kind of craft matters. But to be fair, Markus Persson built Minecraft on existing libraries. Libraries written by hand, but still libraries that he didn’t write.
I am not arguing against craftsmanship. The question is not whether the friction of handwritten code builds strength. The question is whether that friction should remain the bottleneck.
Vibe Coding Is Not Engineering
Let me be clear about something else.
I do not believe vibe coding, at least right now, is viable for large-scale production systems. It may work for small projects. It may work for experiments. It may even work for isolated tools. But enterprise systems and production-level platforms are a different category entirely.
I have seen countless YouTube videos and blog posts where someone says, “I recreated this popular app in one afternoon.” That sounds impressive. But that is not what production-grade means.
A real application, especially one with significant users, has far more under the surface than what you see in the UI. There are compliance requirements. PCI if payments are involved. SOC 2 if you are handling enterprise customers. Data protection standards. Audit logging. Access controls. Region-based data policies.
There is infrastructure. CDN layers. Multi-region deployment. Replication. Failover strategies. Rate limiting. Queue systems. Background processing. Database caching. Observability and monitoring. Incident response. There are integration concerns. External APIs. Internal services. Authentication providers. Data consistency across distributed systems.
There is performance at scale. Load. Concurrency. Latency across regions.
As someone who has spent most of his career working primarily on the backend, I can tell you that most of the real engineering effort is invisible to the user.
Building the front end is not the same as duplicating the system. That is my issue with vibe coding at scale. It can replicate a surface. But it does not replicate the system.
And that distinction matters.
The Part Most Purists Avoid Talking About
AI types faster than any human can. That is not hype. That is mechanical reality.
I ran a real case study for myself. I built a complete game using the Slim framework with almost no external dependencies. I built the entire system. Backend logic. Routing. APIs. Database schema. Architecture. Refactoring passes. Email integration. Graphics. Planning documents. Testing routines. Iterations. Everything.
The full AI-assisted system took 200 hours. Now, let’s compare that honestly. If I had written that same final system by hand, even if I had the perfect finished result in front of me and was copying it line by line, it would have taken me roughly 400 hours just to type and structure the code alone.
Those 400 hours do not include planning, artwork, iteration, refactoring, schema changes, testing, or security hardening. If I had built the entire thing manually from scratch, including all the artwork, thinking, iteration, debugging, and course correction, the realistic timeline would have been closer to six to nine months.
That is the difference.
Most people misunderstand what engineers actually do. We do not sit there typing perfect code in one pass. We plan. We rethink. We refactor. We break things. We adjust. We test. We improve.
AI does not one-shot software. Humans do not one-shot software. What AI removes is the mechanical bottleneck. When the cost of generating and restructuring code drops, we can allocate more time to high-value thinking.
That is not hype. That is math. Speed has always mattered in software economics, and it has always been a defining skill of strong programmers. Does anyone remember LAN parties and competitive programming contests on Friday after work?
Technical Debt and Market Debt
Purists talk constantly about technical debt. AI can introduce technical debt. Humans can too. Overengineering happens. Cleanup happens. Refactors happen. That is part of building software. But there is another kind of debt.
Market debt.
If your competitor ships six months before you, they gather feedback first. They build momentum first. They gain users first. They move first. Being late has a cost.
Being early does not mean you shipped something perfect. No one ships perfect software. The real goal is to get to market with the best product you can deliver at that moment.
If you can get to market faster than your competitor with a better product, marketing aside, you generally win. That is just reality.
And this is where AI changes the equation. When properly governed, AI dramatically reduces the speed constraint.
Not Everything Is Art
Some software is art. Some systems require deep engineering. Some problems demand an artisan. But a large percentage of software is business software.
Internal dashboards. Booking systems. Email integration. Automation tools. E-commerce. These systems compete on iteration speed and cost.
Not every project needs artisanal perfection. Look at construction.
Not every carpenter hired to build a house today hand-carves or hand mills the wood. Yes, there are craftsmen who do. And their work is beautiful. But most carpenters go to Home Depot and buy CNC-manufactured door frames, floorboards, trim, and components made in a factory. That does not make them incompetent builders. It means tools advanced.
There is something beautiful about a handwritten manuscript. You can feel the person in it. But almost every legal document, contract, and novel we read today is typed. There was a time when people argued that typewriters would weaken our ability to write.
There was a time when people said calculators would destroy our ability to do math.
And yet society advanced dramatically because of those tools.
If we had rejected the typewriter, we would not have computers. If we had rejected abstraction, we would still be feeding punch cards into old IBM machines.
Let’s be honest. We do not want to go back to punch cards. We do not want to manually compute everything by hand.
We accept abstraction when it proves useful.
The question has never been whether tools remove skill. The question is: how will tools shift skills?
Junior Developers and the Fear of Skill Loss
One of the biggest fears in this debate is junior developers. People ask, “If AI writes more of the code, how will juniors learn?” That question assumes the skill stays the same. The reality is that the skills will shift.
Junior engineers may spend less time memorizing syntax, functions, and languages. They may focus more on how to frame a problem correctly. Instead of obsessing over syntax, they may spend more time understanding user intent, identifying edge cases, defining constraints, thinking through architecture, reasoning about safety and failure modes, and evaluating tradeoffs. The mechanical act of typing code may largely disappear for many engineers. The skills do not vanish. They shift upward. What senior engineers focus on today may become the starting point for many new engineers.
We may also need to recognize something uncomfortable. There may simply be fewer of us in the future. AI agents are already capable of generating usable task-specific systems on demand. It is not unrealistic to imagine a world where someone picks up their phone, talks for fifteen minutes about what they need, and highly capable software is assembled for them in seconds. They may not need specialized applications in the same way they do today. Software could become disposable, contextual, and generated as needed.
https://dailyaiworld.com/post/disposable-software-vibe-coding-2026-the-end-of-saas-the-rise-of-software-on-demand
Maybe only a smaller percentage of engineers remain to focus on highly specialized systems. Maybe not. Only time will tell. But pretending some level of a major shift is not happening, or dismissing it out of principle, is not serious thinking. Abstraction has always moved forward. This time is not different. That has been the pattern for centuries. Software is not exempt from that pattern.
The Line That Actually Matters
Here is where I stand.
If you reduce judgment and increase speed, AI is dangerous.
If you increase judgment and increase speed, AI is powerful.
The tool is neutral. Irresponsible use creates risk. Responsible use creates leverage. True across all industries.
I respect the purist. I understand why craft matters. I understand why someone who built something generational would defend that path. But refusing leverage in a competitive environment has consequences too.
This is not about laziness. It is not about replacing engineers. It is about reallocating human effort toward higher-value thinking while allowing tools to handle mechanical repetition.
The debate should not be whether AI belongs in software development. The debate should be whether we are disciplined enough to use it responsibly.