2025 başında Andrej Karpathy bir tweet attı ve yazılım geliştirme dünyasında tartışma başladı: "Vibe coding'i benimsiyorum. Kodun her detayını anlama çabası olmadan, tamamen vibe'a bırakarak." Eleştirmenler hemen devreye girdi: bu sorumsuzluk, bu sığlık, bu mühendisliğin inkarı. Savunucular ise karşı çıktı: bu özgürlük, bu hız, bu yeni bir üretim biçimi.

Her iki taraf da haklıydı, ama ikisi de tam resmi göremiyordu.

Vibe coding ne değildir

Vibe coding, kodu anlamadan yazmak değildir. Karpathy'nin kastettiği şey daha ince: her satırı kontrol etme sorumluluğunu modele devretmek. Geliştirici ne yapmak istediğini bilir, ne üretmek istediğini ifade eder; model üretir, geliştirici yönlendirir, sonucu değerlendirir.

Bu akışta geliştirici hâlâ merkezdedir. Ama merkezde olduğu alan farklılaşmıştır: satır yazma değil, yön belirleme. Sözdizimi değil, amaç.

"Vibe coding, düşünmeden kod yazmak değildir. Düşünmenin önüne geçen şeyleri modele bırakmaktır."

Geleneksel mühendislikle gerilim

Yazılım mühendisliği onlarca yıldır disiplin üzerine kuruludur. Kodu anlamak, her satırı savunabilmek, sistemin nasıl çalıştığını kafanda canlandırabilmek, bunlar yetkinliğin tanımıydı.

Vibe coding bu tanımı sarsıyor. Ve sarsması gerekiyor, çünkü bu tanım araçla özdeşleşmişti: kod yazmak, yazılım üretmekle eşanlamlıydı. Oysa yazılım üretmek her zaman bir problem çözmek demekti. Araç değişti, problemin kendisi değişmedi.

Yetkin bir mühendis, modelin ürettiği kodu anlayamıyorsa bu gerçekten bir sorundur. Ama her satırı manuel yazabilmek için modelin ürettiği çıktıdan yararlanmayı reddetmek, atla yolculuk edebilmek için uçağı reddetmek gibidir.

Spec-driven ile buluşma noktası

Vibe coding'in zayıf noktası belirgindir: tutarsızlık. Model her seferinde aynı kararları almaz, bağlam kaybolabilir, çıktılar arasında yönelim farklılaşabilir. Bu, özellikle büyük sistemlerde ve ekip çalışmalarında ciddi bir sorun haline gelir.

Spec-driven metodoloji tam burada vibe coding'i tamamlar. Geliştirici önce spec yazar: ne yapılacağı, ne yapılmayacağı, başarı kriterleri. Bu spec hem modele verilen prompt'un temelidir hem de üretilen çıktının değerlendirildiği referanstır.

Spec yazmak, vibe'ı öldürmez. Vibe'a zemin verir.

Pratikte nasıl birleşiyor?

  • Geliştirici özelliğin spec'ini yazar (ne yapacak, nasıl davranacak, ne yapmayacak).
  • Spec ile birlikte modele vibe coding oturumu açar; yön geliştiricide, üretim modelde.
  • Üretilen çıktı spec'e göre değerlendirilir. Spec karşılanmıyorsa yönlendirilir.
  • Sonuç: hızlı üretim, ama çerçeveli. Özgür, ama disiplinli.

Qhira'da nasıl uyguluyoruz?

Qhira'da geliştirme süreçlerimiz spec-driven vibe coding üzerine kurulu. Q/NORMA platformumuz tam da bu entegrasyonu desteklemek için geliştirildi: geliştirici spec üretir, Q/NORMA bunu hem insan ekiple hem de agent'larla paylaşacak standart bir formata dönüştürür.

Hedeflediğimiz sonuç: geliştirme hızlanırken üretilen çıktıların tutarlılığı ve kalitesi de korunur. Çünkü hız ve kalite artık çatışmıyor; spec ikisini aynı anda mümkün kılıyor.

Vibe coding bir felsefedir. Spec-driven bir disiplindir. İkisi birlikte, geliştiricinin rolünü satır yazmaktan yön vermeye taşır.

In early 2025, Andrej Karpathy posted a tweet that sparked debate across the software development world: "I'm embracing vibe coding. Without trying to understand every detail of the code, fully letting go into the vibe." Critics immediately stepped in: this is irresponsibility, this is shallowness, this is the denial of engineering. Proponents pushed back: this is freedom, this is speed, this is a new mode of production.

Both sides were right, but neither could see the full picture.

What vibe coding is not

Vibe coding is not writing code without understanding it. What Karpathy meant is more subtle: delegating the responsibility of controlling every line to the model. The developer knows what they want to do, expresses what they want to produce; the model produces, the developer steers, evaluates the result.

In this flow the developer is still at the center. But the area in which they are central has changed: not writing lines, but setting direction. Not syntax, but intent.

"Vibe coding is not writing code without thinking. It is leaving to the model the things that get in the way of thinking."

The tension with traditional engineering

Software engineering has been built on discipline for decades. Understanding the code, being able to defend every line, being able to visualize in your head how the system works, these were the definition of competence.

Vibe coding shakes this definition. And it should, because this definition had become conflated with the tool: writing code was synonymous with producing software. But producing software has always meant solving a problem. The tool changed, the problem itself did not.

If a competent engineer can't understand the code a model produces, that is a real problem. But refusing to leverage model-produced output in order to be able to write every line manually is like refusing to fly because you can ride a horse.

The meeting point with spec-driven

Vibe coding's weak point is clear: inconsistency. The model doesn't make the same decisions every time, context can be lost, orientation can vary between outputs. This becomes a serious problem especially in large systems and team work.

Spec-driven methodology is precisely where it completes vibe coding. The developer writes the spec first: what will be done, what won't, success criteria. This spec is both the foundation of the prompt given to the model and the reference against which the produced output is evaluated.

Writing a spec doesn't kill the vibe. It gives the vibe ground to stand on.

How do they combine in practice?

  • The developer writes the feature's spec (what it will do, how it will behave, what it won't do).
  • Opens a vibe coding session with the model using the spec; direction stays with the developer, production with the model.
  • The produced output is evaluated against the spec. If the spec isn't met, the developer redirects.
  • Result: fast production, but framed. Free, but disciplined.

How do we apply it at Qhira?

At Qhira, our development processes are built on spec-driven vibe coding. Our Q/NORMA platform was developed precisely to support this integration: the developer produces the spec, and Q/NORMA converts it into a standard format that can be shared with both the human team and agents.

The outcome we aim for: development speeds up while the consistency and quality of outputs are preserved. Because speed and quality are no longer in conflict; the spec makes both possible simultaneously.

Vibe coding is a philosophy. Spec-driven is a discipline. Together, they move the developer's role from writing lines to setting direction.