Everything in this blog is written by me and then grammatically improved using AI. It took me a few hours spread across about 1.5 weeks to collect my thoughts, discuss ideas with other great engineers, and to finally write the whole thing.
There is one question almost every engineer is quietly asking right now: how much AI should I actually use? The more we let AI write our code, the less we write ourselves, and that changes how much we actually learn. It matters most for the young engineers starting out right now, because how they use AI affects their judgment and their learning of engineering fundamentals, and what kind of engineer they turn into.
I have been writing code since 10th standard, roughly 8 years now, and I have watched the Stack Overflow era, then ChatGPT, then full agentic coding. Today I work as a Frontend Lead at Devfolio. I will try to answer this question in this blog, because the honest answer is not that "AI writes garbage, don't use it" or that "just vibe-code everything, coding is dead." The real story is that AI has gotten genuinely good at building software, and it still breaks things, but it breaks them in specific, predictable places. Knowing exactly where it breaks is the entire job now. So this post is about that line: where AI is brilliant, where it falls apart, how messed up the inside really gets, and how much of it you should actually be leaning on and when.
First, Accept the Reality
AI is doing really well at creating websites. It builds functional games, polished landing pages, and even fairly complex apps. It writes good data models and APIs, and handles CRUD and API integrations with very few mistakes, and it is only getting better. Pretending otherwise to protect your ego as a programmer is a waste of time. If your entire value was copy pasting code from Stack Overflow, building simple CRUD apps, and doing some API integrations, then that value is gone, and it is not coming back.
Now, a few months back I had to build a small game called "Shoot the Dev Team" for a scheduled maintenance page, where users pull a slingshot and fire balls at the gliding dev team. I do not have much experience with game logic. Without AI I would have had to learn how slingshot pull math works, how collision detection works, and how to animate a slingshot with a believable spring. That alone is a one to two week project, easy.
But none of those skills show up in my normal day to day work. Even if I learned them properly, I would forget eighty percent of the details and keep maybe twenty percent of the high level concepts. So I made a deliberate choice: I vibe-coded the whole thing. The first working version took less than half a day. Polishing it into the final piece took some hours across another day or two. I chose to vibe-code it precisely because it is a small project I will never need to scale or extend.
One clarification, just to be on the same page. When I say vibe-coding, I mean building something without looking at the code at all. You iterate on the output, you look at the result, and you keep telling the AI to fix this and tweak that until it matches what is in your head. So are engineers not needed anymore, if everyone is just going to vibe-code their way to building products? No. While vibe-coding is a completely valid way of building something, it matters a lot when to use it and when not to.
Why Can't production software be just vibe-coded?
When you start a new project, the context is literally nothing. These agents do their best work precisely because there is so little to keep track of. They write code based on their general coding skills, and that code is genuinely good. The trouble starts as they write more and more of it. Every AI model is limited by its context window, and no matter how many memory files they create, they still have to take a call on which memory or context file is relevant to load right now and which is not.
Now as the codebase gets bigger and more complex, that project context starts fighting for room with the ten code files that actually need to be loaded for the current task. The agent tries to read the most relevant memories, but it has to drop a lot of important stuff to fit. And that is where the real problem shows up: your agent prioritizes building the feature to satisfy the requirement over doing it the right way for your codebase, simply because it literally cannot see a lot of the existing code.
So you start with a clean codebase, and as it grows the code turns into a mess. The same function gets implemented three times across different files instead of being reused. Business logic where an exception was carved out for a special case in process X never gets wired up correctly for a related new process Y, because the AI never even considered that X and Y might be connected. This is how code debt quietly accumulates.
Honestly, none of this creates much impact for a small MVP or a temporary application built for an event. But the moment you want to run a business on top of such an application, you need an engineer in the loop, to guide the AI on when and where to look, and to maintain the right agent docs so the agent can grab the correct context quickly. So: for new applications it is not a mess, for small apps that never scale it does not matter, and for software that needs to scale, an engineer in the loop is required.
Now, with every new release of a model the context window keeps getting bigger and the memory indexing keeps improving, so this will genuinely get better over time. Does that mean the engineer's job will be over in future? It will shrink, sure. But a good engineer brings more to the table than just understanding the codebase, and people often do not notice it. These skills are specially what make an engineer much more valuable than AI, and they are a very, very long way off for AI to mimic.
1. Engineering vision
The worst kind of engineer is the one who blindly builds whatever requirement is thrown at them. Do you know someone like that? Yes, every current AI agent. Non engineering folks come up with ideas constantly, and it is your job to contribute to those product discussions and question any requirement that feels unjustified. Either the discussion forces a rethink of the feature, or it surfaces the real reasons behind the idea. Both outcomes leave you with a sharper product vision as an engineer. A good engineer also anticipates how requirements will change.
Say a product manager asks for a support chat where users can send messages and images. The lazy model satisfies the requirement exactly:
class Message {
timestamp
message
image: Image URL
}A more thoughtful engineer predicts a support chat will possibly evolve to allow video or text files as well, so they model a file instead of an image, and leave room to grow:
class Message {
timestamp
message
file: File URL
fileType: 'image' | 'video' | 'txt' | 'other'
}The second model costs nothing extra today and saves you a painful migration later. Now I am not saying a model could never think of this exact case, plenty will. The point is that on more product specific decisions, an engineer makes more product aware and product influenced calls than a model does. AI tends to satisfy the prompt in front of it and reach for the easier option, which is exactly how the internals quietly rot.
Now in a small project, none of this actually matters. In fact AI refactors so fast that a non-thoughtful decision can be ripped out and redone before it ever costs you anything. These decisions only start to hurt when you scale a project, when it grows into a mature product with real users, real data, and real history, where a quick refactor cannot be easily done. This is what I call engineering vision. Just as product people carry a product vision, an engineer carries their own technical vision for the project, and it requires a feel for how the product works, how users actually use it, how it will evolve, and an understanding of the codebase and product architecture. A model with none of that lived experience cannot make these calls like a human can.
2. Taste
Two people with identical skills can produce wildly different work. One looks high quality, the other looks mid. That gap is taste, and it depends heavily on trends and on the uniqueness of the final output. Even genuinely good design starts looking cheap the moment AI overuses the same trend everywhere. It reads as low effort at a glance, and users start associating the product with low quality before they have even used it.
This is also why a vibe-coder still needs taste: to drag something from v0 to v1 so it does not look like AI slop. And taste keeps moving. The instant a model catches up to a design trend, everyone has it, everyone overuses it, and it stops being good taste. Then something new becomes the standard. Taste is not a skill you learn in a day. It keeps evolving over a long period of time, and while looking for people with the right taste is not a new idea, it is going to be a big factor in how people get chosen in this AI era.
3. Sometimes it just fails
Models are intelligent and getting better with every release, but sometimes it can simply fail to complete the task. There can be many reasons why that happens: not enough context, the model is not quite sharp enough for this particular problem, the codebase is poorly documented, or the foundational assumptions of the project were defined badly by humans in the first place.
On a small website you rarely hit any of this. On a serious product you cannot give up on the task. When the AI fails, for whatever reason, someone has to read through the full context and do it by hand. That someone is the engineer.
4. Accountability
Only a human can truly feel the weight of a task that failed. We connect outcomes to our own experience. When something we built breaks, we feel the depth of it, we take responsibility, and we often do far more than was asked to recover from it or carry the lesson into the next goal. AI has no real version of this. Negative reinforcement nudges a model a little, but it is nowhere near how a person owns a failure. And the purely human part, being answerable to other people and dealing with them face to face, is something we are not going to move on from any time soon. So accountability is going to stick with us for a long while.
5. Mental disorders
This may sound funny at first, but a lot of humans carry some level of mental disorder. It could be ADHD, OCD, anxiety, depression, bipolar tendencies, or just an obsessive streak that refuses to switch off. These traits, combined with our daily work, shape the final output of a human in ways that are hard to put in words. The intensity of these disorders is not binary, it is a spectrum. You can be a little autistic and not even know it.
There is nothing normal about sitting in a dark room at 3am obsessing over building one feature, without eating, without moving for eight hours straight. All of this happens because the brain is not functioning in the usual, orderly way. And yet, some of the greatest creations in history were built by exactly these kinds of people. Until we find a way to simulate mental disorders in LLMs, we are safe.
How I actually use it
All of this makes me very deliberate about how much AI to use per project. On throwaway work, I lean on it hard. On serious projects, I intentionally reduce how much code AI writes unsupervised, and I increase my code review time significantly.
A real example. For one of our main production apps in devfolio.co , I recently gave AI a refactoring task that touched roughly 300 files. I took my time reviewing all 300, and found about 60 of them had made decisions I was not happy with. I told the AI what to change, and it fixed them in the next pass. Doing those 300 file changes by hand would have taken days. AI plus careful human review got it done in far less time, without breaking production. That is the shape of the work now: less typing code, more reviewing it.
This is not just my private habit, it is roughly how things are shaping up inside serious software companies. Anthropic published an internal study of how their own engineers and researchers use Claude . Their people use Claude in around 59 percent of their work and report a roughly 50 percent productivity boost, yet over half of them say they can fully delegate only 0 to 20 percent of their tasks. The tasks they hand off most are debugging and understanding code. The tasks they guard most carefully are high level design and planning, which is precisely the engineering vision I described above. One engineer put it well: it is amazing for everything where the effort to validate the output is small compared to the effort to create it. The model framing they keep returning to is augmentation, not automation. A collaborator that needs active oversight, not a replacement.
The same report names the risk too. Engineers worry their skills will atrophy as they delegate more, and that the incidental learning that used to happen while solving a problem by hand quietly disappears. That worry is the bridge to the most important part of this post.
This is for the Young Engineers
The senior level job is increasingly about review. You can only review AI generated code well if you already know, in your gut, what bad code looks like. And the only way to build that instinct is to have written a lot of bad code yourself, felt the pain of it, and learned why it was bad.
So the advice splits by where you are. If you are senior, lean into AI, review aggressively, and spend the time you save on harder problems. If you are junior, do the opposite of what is tempting. Force yourself to write more code by hand, not less. Let yourself struggle through the slingshot math and the collision detection and the migration you modelled wrong the first time. These mistakes are what you carry around as experience, and it is the only way you build the understanding needed to review code well.
So as a beginner, use AI less for writing code and more for reading and understanding the codebase. This holds for experienced devs landing in a new codebase too. Used this way, AI actually speeds the learning process up.
The danger for a beginner is not that AI writes bad code. It is that AI writes plausible code, you ship it without the judgment to know it is plausibly wrong, and you never develop that judgment because the AI kept doing the reps for you.
Summing up
So, how good is AI at building websites and apps? Genuinely good, and improving fast. Does it create a mess internally? It can, and it does, which is exactly why you need an engineer in the loop for serious projects, someone who can make the right judgment, guide the AI to write the best code, who knows when and how much AI to use, and has a mental disorder 😁.
I use AI a lot. I am on the Claude Code Max plan and it lets me finish my work far faster than before. But none of that is the point. The point is that finishing the easy work faster frees me to spend my time on the harder, more interesting problems that the model cannot touch yet. Use AI as much as the project allows and as little as your growth requires. For a throwaway maintenance game, that is almost all the way. For the product you actually care about, and for the engineer you are trying to become, it is a dial you should be turning with your own hands.
