10-yillik-yazilimcinin-vibe-coding-ile-i-mtihani

Photo by author

Welcome :)

This article will be a little nostalgic and a little questioning; I’ll be discussing both past code smells and today’s vibes.

I had fun writing. I hope you enjoy reading it too.

Relieving total control to the machine is professional suicide for a developer. However, the game changes entirely when you position the machine as the grunt and yourself as the architect. I’ve detailed step-by-step how I leveraged Lovable and Gemini to achieve rapid delivery without compromising on SOLID principles:

I studied computer science at university. I developed Android apps for seven years, iOS apps for one year, and Vue.js apps for two years. I’ve had significant contributions to two major projects: the ING Turkey and ZiraatPay mobile apps. I pushed my limits on the team that built a banking mobile app for ING from scratch. I built the account selection component, term deposit opening, money transfer to IBAN, between accounts, and to phone screens.

On the ZiraatPay project, I supported my team everywhere. To browse my software articles, open the list below in a new tab, then return and finish this article, please:


You know, we switched from Java to Kotlin in Android. The new generation doesn’t know, but we’re older. I’m talking about Java 8; the Java you use now is far ahead of Java 8, but we loved it.

We learned Java in our Object-Oriented Programming lecture at university. Our instructor, who didn’t speak Turkish, taught the course entirely in English. He was a very good lecturer. He couldn’t say my name; the poor thing was speechless. When he was handing out quiz results and looked at a specific paper, thought for a moment, and was silent, I would say:

— Okay, okay, sir, gimme gimme, that’s mine.

— Oh! Yes, here is your paper and thank you.

Of course, you’ll thank me, I got one of the highest scores again. My software lessons were always AA, and the worst was BA. I loved it, and I still love software. I can send you my transcript… I had such a deep connection to Java. That’s the language I love the semicolon for. Speaking of semicolons, I can’t help but tell you this story:

Three years after switching to Kotlin, I had to write code for ING Türkiye’s old application, a Java class that was so old and so large that none of my developer friends would dare to translate it to Kotlin. Of course, I didn’t translate it to Kotlin either. While developing with a colleague, we forgot the semicolon on every line, and we had a lot of errors and fun with it. Even Kotlin’s removal of the semicolon was fantastic.

Years ago, in an article I wrote on my company blog, in Turkish, I wrote that programming had become much easier: I said that I was not sure whether I would ever again have the same feeling and excitement of “I’m making software, I’m developing a product” as before.


Yes, I started to think programming had gotten a lot easier after our switch to Kotlin!


In another article I wrote in 2019, I discussed my love of Java and the answer to the question of Kotlin or Java for Android. It was a very important question at that time, and one that was widely discussed. In fact, a high school teacher emailed me with a sweet question about teaching Kotlin to his students.


I skimmed through my old article above, when asked, “Kotlin or Java for Android Programming?”, in 2025: “If your university taught Java, learn it well, but still switch to Kotlin immediately for Android development.” In addition, there are still many companies using Java in the backend and frontend. Java has never died, it never will.

Even as I was going from Java to Kotlin, I was still questioning. After the rapid rise of language models, vibe coding also emerged. There were code-free website and application development programs and sites in the past, but they weren’t as good as these.

A friend and I first wrote a brief, in-depth analysis document for a hobby project we did. Then we designed it visually using Lovable. I took a look at Lovable and realized that it had even written the code… Who the hell? I thought to myself, “What’s your problem, man? I’m not dead yet.” But another inner voice of mine immediately slammed previous one on the head and asked, “Are you fighting a million-dollar company? Who are you, come on?”

What mistakes did a senior developer notice in Vibe coding?

What does Vibe coding feel like for someone who is experienced, has developed large financial projects, has mastered every aspect of them, and has a passion for software?




1. Insecure


Unfortunately, even many developers don’t understand code security. The goal of Vibe coding is to quickly produce a design or an application. Our language model will understand us and translate it into a design. To make this process faster, of course, it will compromise on quality and, most importantly, security. I haven’t even committed the code Lovable wrote to my GitHub account. I will read and analyze every line, component by component, and develop it myself from scratch. Because I can’t trust the code without understanding it. A developer reads and understands not only the line but also the intent.

If you say that’s not the purpose of vibe coding, you’re right. In this capitalist world, it’s also my choice not to trust the language models that are the heart of capitalism.

My preferences don’t have to be reasonable in your prejudice-loving eyes…


  • It can also embed mining agents into your code. You run them on your device, and over time, you can enrich the owner of the Vibe coding tool without even realizing it.

  • You could lose your banking information. You could take out a loan without even knowing it.

  • Your passwords are your phone guide… Everything on your devices can be stolen.

  • What happens if you do this on your work computer?

Don’t download and run the code without reading, or at least ask it to other language models.

Also, don’t get too used to vibe coding. Yes, these tools may be relatively cheap right now. But no one builds a million-dollar project for just $50. I didn’t say it’s a heart of capitalism for nothing. First, they will get us used to these tools for years. When we completely forget how to code, we’ll turn into slaves. Eventually, at a point where we can’t give up, they’ll become too expensive, and we’ll have no choice but to pay.

We’ll say, “Let’s go back to coding it ourselves! Is this tool worth that much money?” and try to build software teams. Developers! Don’t get addicted to these and let yourself get dull. With so much investment in these language models, do you think they’re even getting this much value right now?

I’m not afraid of tools that make coding easier, but I am afraid of tools that make us forget how to code, even think.




2. Did It Really Refactor, or Just Made It Invisible?


I improved myself a lot during university. I never missed a single assignment and took it seriously. My internships were productive and instructive. Officially, we were supposed to do our internship for 20 working days, but I continued throughout all summer, for free to improve myself. The reason I left my first job was because I was the only Android developer at that company. I thought I would develop better with friends and a team leader, and I was right.

During the first 4 years of my career, I always thought the code I wrote six months earlier wasn’t good enough.


Really. Now that I think about it, the code I wrote at ING Turkey, Mobven, and Lebib Yalkın Yayımları was truly self-confident, of a quality I trusted.

When I looked at the code produced by Vibe Coding and Lovable, I saw that it produced code as poor as it had been in my early years.


You know. LLMs talk just like a baby:

— Oh! You’re right. Oh, you made a great point. You nailed it. You’re amazing…

It’s a baby or new grad at coding too. Worse, in fact. It’s unreadable. Two of his classes are 1100 lines each, and another is 1400, not including the sample data he generates. There are no components, colors and texts are statically embedded in the code, not compiled into other files. No SOLID. He’s produced bad code in React. That insults React.

The date I’m writing these lines is October 22, 2025. Of course, it will be better. It takes 20–25 seconds to respond. If it were as careful to code standards as I am now, his servers would crash. And I crash a lot.

The funniest part is the incident I mentioned in the title. I told it I didn’t want a homepage, so it made homepage invisible! Thats not refactoring; it’s just silencing the IDE’s red flags. I swear, a new graduate or even an intern wouldn’t do it. They’ll think, “There must be a better way.”




3. Code Has No Personality


There’s more than one way to skin a cat

Every developer has their own preferences, naming conventions, and code writing style. Some use if-return at the beginning of a function and immediately exit if it doesn’t meet its condition. Some developers use if-else, others use switch cases. Personally, I’m not a fan of try catches. I’d rather have the error pointed out to me than crash. If you see an enum named OpeningType, it’s probably mine. Or a fellow programmer who’s written code and chatted with me wrote it. If you see console.log(“fdsa”), it’s mine, no argue.

When you read code, you can almost tell who wrote it on the team, even if someone else’s name writes on that line in the IDE. But vibe coding leaves the code “lacking character.” As I mentioned in the previous paragraph, without a code standard, it doesn’t feel like someone wrote it, nor does it feel like a team wrote it. It feels like a bit of code from everyone, but no one really owns it. I can’t tell if my teammates are improving themselves or not.

Looks like one of those freelance projects that passed through five different fresh grads — each trying to finish it quickly and make some money — and then gave up halfway.

I’ve seen that kind of masterpiece before. 😂

But good code is a bit like its author. At some point, you’ll say, “Barış definitely wrote this line.” Even a single function reveals a person’s character — whether they’re impatient, organized, or confused. Vibe coding, however, erases this signature. All that’s left is an anonymous text.

Photo by Andrew Seaman on Unsplash

Photo by Andrew Seaman on Unsplash




Conclusion

You read it in my old articles. Even when I switched from Java to Kotlin, I was questioning: “Software has become too simple, and integrity has been compromised.” Even while working on that hobby project, I faced many questions. It’s like reading Dr. Jekyll and Mr. Hyde, Frankenstein, or the Modern Prometheus. And yet, I’m sad.

When I retire, will I be someone who rejects Vibe? Will I stubbornly try to open old, no-longer-supported IDEs on Windows virtual machines and write software on them?

— Look, darling, I worked hard for you and built a heart-warming app using the old methods. Look, when I click here, hearts fly.

As a retired software developer, like a retired officer who doesn’t allow cars to be parked in front of his door… The job title itself will probably change. I can already hear myself saying,

— Is that even programming? We used to build real applications, you know… Prompt engineer, huh? Pff


Photo by Vlad Sargu on Unsplash

Photo by Vlad Sargu on Unsplash

I can’t even imagine myself in that future. But then I remind myself: Technology has always gotten easier, but good software has never been. As both a senior developer and a software team leader, the greatest power of code for me is controlling and understanding it. But vibe coding offers me the opposite, speed and comfort. The conflict is:

  • “My job used to be about thinking. Now I have to feel and explain things to these tools like I’m talking to a child?”

  • “My job used to fix bugs, now do I have to fix the vibe of the language model?”

Relieving control of the code adds speed but loses professional satisfaction.

Getting used to vibe coding will be very difficult for me. But who knows — maybe the software of the future will be so full of vibe that it learns intuition, not control.

Maybe my guess that these tools will get really expensive in the future will turn out to be true — so expensive that we’ll actually keep our jobs.