What AI Left Me to Learn

Every few weeks, I come across the same conversation online.

AI is making developers lazy.

Nobody knows how to code anymore.

People are building projects without understanding what they're doing.

Software engineering is dying.

The funny thing is that I understand where these concerns come from. I've seen people generate entire projects from prompts. I've seen codebases held together by AI suggestions and optimism. I've also been that person staring at a file wondering who wrote it, only to remember that technically, I did.

But over the last year, my experience led me to a completely different conclusion.

Not because I think AI is magical. Not because I think everyone should vibe code. But because I accidentally spent a year learning software engineering while arguing with people about whether AI was replacing it.

And the irony is that I didn't even realize it was happening.

CareerIQ and the Illusion of Knowing What You're Doing

CareerIQ started around August as a semester mini-project.

It was a group project. Which already tells half the story.

We wanted to build a career prediction platform. The idea seemed straightforward. We had a vision. We knew what we wanted it to do. What we didn't have was a plan.

At the time, I thought I understood what full-stack development was. I knew frontend existed. I knew backend existed. I knew there was some pipeline connecting everything together. I also thought frontend was the harder half.

People who'd worked with backend used to tell me it was easier.

I refused to believe them.

p.s. Looking back, I owe those people an apology.

Backend turned out to be easier.

Not because it's simple, but because once I understood the flow of data, most of the complexity felt visible.

Frontend still finds new and creative ways to humble me.

Then reality arrived. And reality had authentication.

To this day, I think auth was the first thing that truly humbled me. I didn't understand the logic. I didn't understand how the pieces connected. I was using AI heavily for parts of the backend, but I wasn't providing enough context because I barely understood the system myself.

The result was exactly what you'd expect.

Every fix created three new problems. Every feature broke something else. Frontend logic and backend logic seemed determined to avoid speaking to each other.

And then the group project problem appeared.

Nobody cared as much as I did.

Which isn't a criticism. It's just the reality of group projects. Most people wanted a grade. I wanted the project to actually become something. Those are not always the same goal. As deadlines closed in, I found myself doing most of the work simply because there wasn't enough time left to bring everyone else up to speed. I remember twelve-hour days trying to make everything hold together.

Group projects show you pretty fast whether everyone actually wants the same thing. You can work around someone who doesn't know a framework. You can't easily work around a team that's trying to build different things.

At the time, I thought I was struggling with code. Looking back, I wasn't.

The hardest problems weren't coding problems. They were planning problems. Architecture problems. Communication problems. Scope problems. The code was simply where those problems became visible.

I just didn't know it yet.

The Thing That Started Before Software

What's funny is that when I look back, the habits that eventually helped me build software didn't come from software at all.

They came from writing. Actually, they came from even before that.

Ever since I was a kid, whenever I wanted to build something, I'd sketch it first. Break it into parts. Figure out how the pieces connected. Think about constraints, about assembly, about what depended on what. Then I'd start building.

At some point I started doing the same thing with writing.

People often talk about writing as a way to communicate ideas. For me, writing was always thinking before it was communicating. Thoughts are much easier to work with once they're outside your head. You can look at them. Move them around. Question them. Argue with them. Journaling was basically externalized cognition. Not recording thoughts, but having them.

By the time I started building projects, I'd spent years doing this without a name for it.

The medium changed. The process didn't.

Writing also taught me something I didn't expect: you can't write well about something you don't understand. The murkiness shows up in the sentences. Vague thinking produces vague prose, and the prose makes the gaps visible in a way that just thinking in your head never does. Software turned out to work the same way. Fuzzy requirements produce fuzzy code, and the code eventually forces the question you avoided at the beginning.

Once I saw that parallel, I couldn't unsee it.

First drafts are prototypes. Editing is refinement. Publishing is deployment. Reader feedback is user testing. Every article is basically a software release with fewer bugs and more typos.

BTechBrain and the Questions That Come Before Code

If CareerIQ taught me that building software was harder than I thought, BTechBrain taught me why.

The development of my website started around September 2025 and, honestly, only feels finished now. And I put finished in quotes because every developer knows that finished is mostly a myth.

What mattered wasn't the website itself. What mattered was what it forced me to do first.

For the first time, I wasn't building something because it had been assigned to me. I had complete creative freedom. Which meant I had to answer uncomfortable questions.

Why does this need to exist? Why not use Medium? Why not use Substack? What annoys me about existing blogging platforms? What do I actually want readers to experience?

The more I sat with those questions, the more the answers took shape. I wanted a place where people could discover my writing directly. I wanted something more interconnected than a list of posts sorted by date. I wanted articles to lead into other articles. Recommendations, themes, connections. I wanted the thing to feel like a mind, not a feed.

And I wanted to prove, mostly to myself, that someone could be both a writer and a developer. What I didn't realize was that this wasn't going to be a weekend project.

The site started in September 2025 and kept evolving all the way into 2026.

Features appeared because new questions appeared.

Recommendations.

Better organization.

User history.

Likes.

Things I hadn't even considered when I first opened the project.

Looking back, the website feels less like something I built and more like something I slowly discovered.

Here's what I didn't expect: code was the last thing I did. Not the first. The first thing was thinking. Questioning. Understanding what I actually wanted to build before touching a single file.

That's also when AI became dramatically more useful. I noticed something I haven't stopped thinking about since.

When I didn't know what I was building, AI made the confusion faster. When I did, it made the building faster.

Feed it something specific and it moves fast in the right direction. Feed it ambiguity and it moves just as fast in the wrong one.

On Originality

Working on BTechBrain raised a question I'd been quietly avoiding.

What does it mean for something to be original?

The common assumption floating around most AI conversations is that originality lives in implementation. In writing every line yourself. In the artifact of individual authorship. That assumption started feeling increasingly wrong the more I built.

Because when I looked at BTechBrain, what felt most mine was never a function I'd written. It was a decision I'd made. The specific picture of what the site should feel like. The constraints I chose to impose and the ones I chose to ignore. The tradeoffs between simplicity and expressiveness, between what was technically interesting and what actually served the reader. Hundreds of small calls that added up to something that couldn't have come from anyone else.

An AI can write the code. It can't want what you want. It can't care about the specific problem you're trying to solve or hold the particular picture you've been carrying around. That part was always mine.

How Tutorials Actually Worked (And Didn't)

Tutorials worked for DSA. You watch someone implement a binary search, you implement a binary search, you understand binary search. The concept is the thing. The code is just the concept made visible.

Software development was completely different, and I didn't realize it for an embarrassingly long time.

I'd follow a tutorial, get the same output as the video, feel like I'd learned something, and close the tab. But I hadn't built anything. I'd just executed instructions someone else wrote, in an environment someone else set up, toward a goal someone else defined. The moment I sat down with an actual project, nothing transferred. Because the tutorial had done all the thinking and I'd just done the typing.

The fake sense of achievement was the real problem. It looked like progress. It registered as progress. It was just busy work dressed up as learning.

What actually taught me software development was building things where I had to make decisions nobody had already made for me. Somewhere along the way, tutorials stopped being instructions and started becoming references.

I wasn't trying to recreate somebody else's project anymore.

I was stealing concepts and applying them to my own. Where I couldn't pause and rewind. Where getting stuck meant figuring it out, not scrubbing back thirty seconds.

That's also what makes AI dangerous in the same way. If you're using it as a tutorial you can talk to — feeding it a goal and following its output step by step without understanding why — you end up in the same place. Something that runs, built by someone else's thinking, that you can't explain or extend or debug when it breaks. The tool rewards the thinking you do before you open it.

The Day Software Engineering Escaped the Classroom

Around the same time, we started studying software engineering properly as a subject.

UML diagrams. Activity diagrams. Use cases. The usual collection of things engineering students memorize for exams.

At first, I treated it exactly like that. Exam material.

Then I looked at my notebook and had a deeply uncomfortable realization.

I was already doing half of it. Just badly.

Activity diagrams? I was already mapping flows. Use cases? Obviously. The whole point of a product is that somebody uses it. User flows? I'd been sketching these by hand since before I knew they had a name, usually on whatever paper was nearby, usually before touching any code.

The diagrams didn't teach me a new process. They gave names to a process I was already using.

There's a difference between learning a concept and recognizing one. One happens in your head. The other happens in your chest. When I encountered those diagrams, I wasn't learning something new. I was recognizing something I'd been doing for years. The diagrams weren't instruction. They were confirmation.

Which turned the expected relationship between class and project inside out. I'd assumed the flow was: learn concept in class, apply it to project. What actually kept happening was: do something in a project, then recognize it later in a lecture.

I Accidentally Became the Spiral Model

This was probably my favorite realization of the year.

Semester 6 introduced us to development models. Waterfall. Spiral. Prototype. And while studying them, I suddenly understood why some projects had felt miserable and others had felt exciting.

CareerIQ was accidental Waterfall.

We locked in a destination. Built a fixed plan. Worked in parallel tracks that were supposed to converge at the end. Integration happened late, when all the pieces were theoretically done. The pain was enormous. Problems that would have been cheap to fix in week two were catastrophically expensive in week eight. Deadline pressure didn't just reveal bugs. It revealed architectural assumptions that had seemed fine in isolation and collapsed under the weight of the actual system.

BTechBrain was accidental Spiral.

Build something. Put it in front of your own eyes. Notice what's broken, what's missing, what's confusing. Improve it. Repeat. The architecture didn't arrive fully formed. It evolved because the requirements evolved because my understanding evolved. Early decisions that turned out to be wrong could be corrected before they became load-bearing walls.

I didn't discover the Spiral model from a textbook. I discovered it from suffering through its opposite.

Waterfall's failure taught me what iteration was for before I knew iteration had a name. Then the textbook showed up and named what I'd stumbled into through pain. That's a different kind of knowing than reading something and then trying it. You know it differently when it costs you first.

AI Made Me Read More Than I Expected

One thing nobody told me about AI-assisted development is how much reading it creates.

People talk about writing code. Nobody talks about reading it.

Reading documentation. Reading generated code. Reading logs. Reading stack traces. Reading your own code from two weeks ago and wondering what version of yourself made those decisions.

The more AI entered my workflow, the more important understanding became. Generating code isn't the same thing as evaluating it. Writing got cheaper. Knowing whether the output was actually right became harder to shortcut.

Debugging changed in a related way. Early on, a bug felt like an accusation. Proof that I didn't know enough, that a more competent person wouldn't have made this mistake. That made debugging feel like punishment, a tax on not knowing rather than a normal part of the process.

Somewhere during BTechBrain, that flipped.

Bugs became clues. A bug was information about what the system was actually doing versus what I thought it was doing. The gap between expected behavior and actual behavior was where the interesting questions lived. I started to like debugging. It had turned into something closer to detective work.

DeepSpace and the Missing Piece

Much later, I built DeepSpace, a virtual focus-room project for an assessment.

From the outside, it looked like one of those classic AI success stories. CareerIQ took months. DeepSpace took days. People love stories like that. They make the tool look magical.

The truth is much less exciting.

DeepSpace wasn't faster because AI got smarter. I had changed.

This time, I knew the minimum version I wanted. I had already sketched the pages. I knew what each screen was supposed to do. I understood backend development. It had stopped being scary because I'd built enough of them to understand the shape of the problem before writing the first line. I deployed as I built instead of waiting until everything was theoretically done. The roadmap existed before the code.

That was the difference. Not AI. The roadmap.

The confidence was different too, and this one is harder to articulate without sounding like I'm just describing maturity.

CareerIQ me thought: I don't know what I'm doing.

DeepSpace me thought: I don't know what I'm doing yet, but I know how to figure it out.

Those sentences look similar. They don't go the same places.

The Thing I Got Wrong

For the longest time, I thought software engineering was coding.

Then I thought it was app development. Then I thought it was web development. Then I did web development extensively and still had the same feeling of missing something, of the label not quite attaching to the activity.

So I stopped trying to define it.

Then Semester 6 happened.

Suddenly the formal vocabulary was landing on things I'd been doing for a year without names. Requirements gathering: the questions I spent weeks on before writing the first line of BTechBrain. System design: the sketching. Iteration: what made DeepSpace feel different from CareerIQ. Architecture: the early decisions I later couldn't undo. Deployment: the thing I deferred until it became a crisis and then learned not to defer.

All of it counted. The writing, the sketching, the planning, the drafting, the testing, the reviews, the iterations, the deployments, even the conversations.

Even CareerIQ counted. It was messy software engineering. But it was software engineering. I just happened to apply a terrible version of Waterfall when what I actually needed was Spiral.

The definition didn't arrive as a revelation. It arrived as an expansion. The territory I'd already been exploring acquired a name large enough to contain it.

So when people ask whether vibe coding is making developers stop learning, I don't think the answer is yes or no.

My experience is that AI didn't remove learning. It moved it.

Implementation got cheaper, which forced attention toward the things that couldn't be automated. Planning. Architecture. Requirements. System design. Deciding what to build and whether the build was going in the right direction. These were always the hard parts, just hidden behind implementation, which was expensive enough to consume most of the available time. Make implementation cheap and the hard parts are suddenly exposed. No longer deferrable.

I spent a year hearing that AI was replacing software engineering.

Meanwhile, somewhere between notebooks and diagrams and debugging sessions and architecture decisions and deployment failures and far too many conversations with an AI that was only useful when I already knew what I wanted, I was accidentally learning software engineering the entire time.

I just couldn't see it. I was looking at the code instead of at everything that makes code worth writing.