Disclaimer: These are my personal thoughts and opinions, and not representative of any institution or people. It’s been a while since I have written a personal essay here.
There are two main angles that I want to cover when it comes to AI:
- The potential changes that LLMs have already bought upon in the developer landscape, and how this continues to form and change as we get more capable models. From distilled models that can run fully on device without relying on any datacenters, to highly capable ones that have the ability to one-shot entire apps.
- How the kids using them will probably be alright. At least the curious ones, who live to solve problems and understand systems inside out.
Some Introduction
For the entirety of this article, the terms Artificial Intelligence (AI) and Machine Learning (ML) have been used interchangably, and both of these terms really refer to the concept of a Large Language Model (LLM). The most famous models are the GPT family, often packaged in products such as Claude, ChatGPT, and others you already have probably heard about.
I have written numerous times about how the programming landscape has been changing. As I have gone deeper into researching, participating, and experiencing this landscape, a lot of other publications have also touched upon the same. Some places believe that the growing landscape is the end of programming, while others have provided peer reviewed deep dives into how AI has not really been the promised disruptor.
Media tends to often be black and white. Real world, does not. And even before we begin to understand why LLMs have the potential to be a positive (put down your pitchforks), I believe it is crucial to first explain how we got to the public perception with regards to AI that we have currently.
Utility and Disruption
There is a famous Q&A with Steve Jobs at WWDC 1997’s fireside chat about OpenDoc. Here’s a link. For everyone else, here’s a little transcript:
Audience member: I would like, for example, for you to express in clear terms how Java, in any of its incarnations, addresses the ideas embodied in OpenDoc. And when you’re finished with that, perhaps you could tell us what you personally have been doing for the last 7 years.
Steve Jobs: One of the hardest things, when you’re trying to effect change, is that people like this gentleman are right in some areas. I’m sure that there are some things OpenDoc does, probably even more than I’m familiar with, that nothing else out there does. And I’m sure that you could make some demos, maybe a small commercial app, that demonstrates those things.
The hardest thing is: how does that fit in to a cohesive, larger vision, that’s going to allow you to sell 8 billion dollars, 10 billion dollars of product a year? You’ve got to start with the customer experience and work backward to the technology. You can’t start with the technology and try to figure out where you’re going to try to sell it.
A solution in search of a problem is always a distraction. The same can be said about most AI in the general consumer section.
The other side of this coin
On the other side, you have developers. Say, I have an amazing idea for a phone app today. To sit down and start working on it, I have to:
- Sketch the idea out, and divide it into smaller parts
- Create scaffolding, frontend, backend, design, database structures.
- Make them optimized, scalable, deployable.
- Give constant bug updates.
- Program the first version.
- Pray that the compiler is not out of date. Pray the dependencies work well. Pray that my OS does not have a quirk. Pray there are no weird restarts. Pray extra hard if I am running a rolling Linux distro.
While coding is a form of art (and I certainly do treat it that way), a lot of coding involves tedious processes that take you away from implementing the main idea of your product. This is where LLMs are genuinely, substantively useful — not as a replacement for a developer, but as a force multiplier on the parts of the job that are repetitive and boring.
Scaffolding a new project? Boilerplate. Writing a migration script you will use once? Boilerplate. Remembering the exact incantation for a CMake target that links against a static library on Windows? You get the idea.
The best analogy I have found is that an LLM is like a very enthusiastic intern. One who has read every Stack Overflow thread, every man page, and every GitHub issue ever written — but has never shipped anything to production, has no taste, and will confidently tell you the wrong answer if they do not know the right one. You would not hand an intern the keys to your codebase and walk away. But you also would not refuse to let them write the first draft of a unit test.
Which means, in the context of developers, LLMs have been a force multiplier that has enabled them to work faster and better. And this makes sense, as abstraction of difficult concepts is at the crux of what we have tried to move towards in computation. No one is punching cards today, or writing pure assembly (except the Roller Coaster Tycoon guy). People today are even averse of C, and probably soon of Python or any other high level language.
Vibe Coders
The concept of vibe coding is essentially that you describe what you want, and an LLM writes it. You are the product manager, the LLM is the engineer. Ship first, understand later…or maybe never. Andrej Karpathy coined the term in February 2025, describing it as coding where you “fully give in to the vibes” and forget the code even exists. Collins Dictionary named it Word of the Year for 2025. By the end of that year, 41% of all code written globally was AI-generated.
This has drawn a lot of mockery from the traditional programming community, and some of it is warranted. The security numbers are not flattering. A scan of 5,600 applications built with vibe coding tools found over 2,000 vulnerabilities, 400+ exposed secrets — API keys, credentials, tokens — and 175 instances of exposed personally identifiable information. AI-assisted commits expose secrets at more than twice the rate of human-only commits. These are not theoretical risks. The Moltbook breach in January 2026 exposed 1.5 million API authentication tokens plus 35,000 email addresses within 72 hours of launch. The founder had built the entire social network using only AI coding tools without writing a single line of code himself. The vulnerability was not sophisticated — any engineer doing a standard code review would have caught it. But no code review happened because the entire application emerged from conversational prompts.
There is also a subtler issue: hallucinations. AI assistants recommend packages with total confidence, including packages that do not exist. A USENIX Security 2025 study of 2.23 million code samples found that 19.7% referenced at least one hallucinated package, and 43% of those invented names reappeared on every rerun. Attackers register the names and wait — a technique now called slopsquatting.
So yes, vibe-coded products can be liabilities. But here is the thing: the moment something breaks in production - and it will - the developer has to understand why. They cannot ask the LLM to fix what they cannot describe. And to describe it, they have to learn it. Scalability, security, deployability, redundancy, backups, encryption: none of these go away just because you did not write the original code. The LLM cannot abstract the consequences.
In that sense, vibe coding is less like cheating and more like being thrown into the deep end. The curious ones will swim. They will read the error messages, chase the stack traces, and come out the other side with a mental model built by doing rather than by sitting through a lecture.
Coding (the actual act of writing syntax) has always been the most manual and most automatable layer of software engineering. The rest of the discipline: decomposing problems, reasoning about failure modes, understanding the tradeoffs between consistency and availability, knowing when your architecture is about to fall over - that is not going anywhere. The vibe coder who sticks with it long enough will find themselves doing all of that whether they planned to or not.
This requires consistency and discipline.
What Comes Next
So where does that leave us?
The entry-level job market has taken a real hit. Entry-level tech hiring dropped 73.3% from 2024 into early 2025, according to Ravio’s 2025 Tech Job Market Report. Companies are hiring engineers that can use AI from the start rather than training junior developers. The tasks that used to be a junior developer’s on-ramp — boilerplate code, simple bug fixes, unit test scaffolding, basic refactoring — are exactly what AI now does well. The short-term savings look good on a spreadsheet. The long-term consequence is that you are quietly draining the pipeline that produces senior engineers in five years. Nobody has a great answer for that yet.
Please, for the love of everything, invest in junior engineers!!
These are real costs and they deserve to be taken seriously. The people writing the checks are not bearing them.
But computation has always been about removing the ceiling on what a single curious person can do. That is the through-line from the transistor to the personal computer to the internet. Each transition was disruptive, each one was declared the end of something, and each one eventually produced more capability in more hands.
The clearest example of where LLMs are actually beneficial to humanity has nothing to do with chatbots or vibe-coded SaaS products. AlphaFold — DeepMind’s protein structure prediction model — won the Nobel Prize in Chemistry in 2024, and its associated database is now used by over 2 million researchers in 190 countries. Before AlphaFold, determining a protein’s 3D structure experimentally could take years. The model does it in minutes, and it has provided predicted structures for more than 200 million proteins, encompassing nearly the entire human proteome and almost all therapeutically relevant drug targets. That is what AI looks like when it is pointed at a problem that actually matters — not generating a stock photo or writing a mediocre cover letter, but compressing decades of scientific work into something a graduate student can run on a laptop.
The curious ones were always going to be alright. They just have better tools now. The question worth asking is what problems we point those tools at, and in the meantime, how do we revamp our current curriculums to engage more people and train them for what the workplace will actually look like tomorrow; not what it looked like yesterday.