Prototip mi, Yoksa Production'a Hazır Yazılım mı? Aradaki Farkı Görmek

Geçen gün bir girişimci arkadaş bana hafta sonu AI araçlarıyla geliştirdiği çalışan bir web uygulamasını gösterdi. Ne bilgisayar mühendisliği diploması, ne de bootcamp eğitimi vardı. Sadece net bir fikir ve iyi yazılmış bir prompt. Gerçekten etkileyiciydi. Yetmiş iki saatten kısa sürede giriş sistemi, bir kontrol paneli ve veri saklama özelliği hazırdı.

Sonra uygulamayı gerçek kullanıcılara sunmamı istedi.

İşte işler o zaman ilginçleşmeye başladı.

Prototip çalışıyordu çünkü tek kullanıcı vardı. İkinci bir kişiyi eklemeye çalıştığımız anda eşzamanlılık hataları baş gösterdi. Veritabanında şema taşıma sistemi olmadığı için geri alma işlemi veri kaybına yol açabilirdi. Test yoktu, bu yüzden herhangi bir yeniden düzenleme işlemi gözü bağlı bomba imha etmek gibi hissettiriyordu. Deployment ise manuel bir süreçti ve dokümantasyon sıfırdı.

Hafta sonu projesi harika bir konsept kanıtıydı. Ama production'a hazır bir yazılım değildi.

"Vibe coding" tartışmalarının sürekli gözden kaçırdığı şey tam olarak bu boşluk. Araçlar gerçek, hız gerçek ve yazılım oluşturmanın demokratikleşmesi gerçekten heyecan verici. Ancak kod üretmek ile yazılım mühendisliği yapmak arasında bir fark var. Ve bu fark, çoğu insanın 3'te gece bir incident'le karşılaşana kadar farkına varmadığından çok daha önemli.

Asıl Ölçülmesi Gereken Şey

AI tarafından üretilen kodu gördüğümde hep şu soruyu soruyorum: Bu, paylaşılan bir codebase'e güvenle birleştirilebilir mi?

"Çalışıyor mu?" değil. "Demo işe yaradı mı?" değil. Güvenle birleştirilebilir mi? O "güvenli" kelimesi çok ağır bir yük taşıyor. Kod, onu yazmayan biri tarafından incelenebilir olmalı. Testler davranışı doğrulamalı, sadece çökmediğini değil. Geri alma veri kaybı olmadan mümkün olmalı. Değişiklik anlaşılacak ve açıklanabilecek kadar dar olmalı.

Bir vibe coder başarıyı ölçerken genellikle ilk çalışan versiyona ulaşma süresini ölçüyor. Bu, keşif ve prototipleme için kullanışlı bir metrik. Ama yazılım paylaşılan bir ortama girdiğinde bu metrik işe yaramaz hale geliyor. Artık ölçtüğünüz şey güvenli birleştirme süresi ve bu, inceleme maliyetini, test kalitesini, deployment riskini, koordinasyon yükünü ve gelecekteki bakım yükünü de içeriyor.

Bir yazılım mühendisi tüm bu döngüyü en başından düşünür. Bir vibe coder ise bu kaygıları genellikle daha pahalıya mal olduğu zaman keşfeder.

Kod Üretimi ile Kod Sahiplenmesi Arasındaki Fark

AI kodunuzu oluşturduğunda ince ama kritik bir kayma yaşanır. Çıktı henüz sizin eseriniz değildir. Gerçekten sahiplenmeniz gereken bir başlangıç noktasıdır.

Sahiplenmek birkaç şey demektir. Değişiklikteki her anlamlı kararı açıklayabilirsiniz. Her dosyanın neden var olduğunu ve ne işe yaradığını bilirsiniz. Değişikliği tam ihtiyaç duyulan şeyle sınırlamışsınızdır, gereksiz iskelet kod veya ilgisiz temizlik yapmadan. Davranışı kontrol eden testler yazmış veya doğrulamışsınızdır, sadece kapsama metriklerini tatmin etmek için değil. Geri alma yolunu düşünmüşsünüzdür.

Bu, AI'nın sizin yerinize yapamayacağı iştir. AI üretir. Kararı siz verirsiniz. Ve "karar vermek", alternatifleri düşünmeyi, ödünleşmeleri tartmayı ve sonuçları anlamayı gerektirir.

Düzgün sahiplenilmemiş AI tarafından üretilmiş kodlara baktığınızda genellikle aynı sorunları görürsünüz. Değişiklikler gereğinden büyüktür çünkü model ihtiyaç olandan fazlasını üretmiştir. Paketler net bir gerekçe olmadan eklenmiştir. Testler gerçek hataları yakalamak için değil, bir kapsama aracını tatmin etmek için yazılmış gibi görünür. Model iskelet koda ve basitlik yerine yapıya öncelik verdiği için gereksiz kod kalabalığı vardır.

Bunların hiçbiri AI'nın suçu değil. Çıktıyı ilerleme olarak değil de ham malzeme olarak değerlendirmeyen bir yazarın sonucudur.

Kimsenin Konuşmadığı İnceleme Problemi

Beni uykusuz bırakan bir şey var: AI tarafından üretilen kod inceleme dengesini değiştiriyor.

Bir insan mühendisi kod yazdığında, genellikle bir karar izi vardır. Seçimleriyle anlaşmayabilirsiniz ama en azından seçimler vardır. Neden o soyutlamayı kullandığını, neden doğrulamanın orada olduğunu, neden o kütüphaneyi seçtiklerini sorabilirsiniz. Cevaplar "düşünmedim" veya "o anda mantıklı görünüyordu" olabilir ama en azından sorulacak bir insan vardır.

AI tarafından üretilen kodla, bu "kararların" bir kısmı aslında karar değildir. Tamamlamalardır. Model bir kalıbı istatistiksel olarak olası olduğu için seçti, sizin probleminize gerçekten uyduğu için değil. Ve yazar bu tamamlamayı sahiplenilmiş bir işe dönüştürmemişse, inceleme çok daha zor bir problem haline gelir.

Modele neden o yaklaşımı seçtiğini soramazsınız. Yazar gerçekten bilmiyorsa ona neden o kararı aldığını soramazsınız. Ya inceleme acı deneme yanılma yoluyla sorunları ortaya çıkarır, ya da hiç olmaz.

Bu yüzden AI destekli geliştirme çağında en önemli becerinin prompt yazmak olmadığına inanıyorum. En önemli beceri, üretilen çıktıyı; derinlemesine anlayabileceğiniz, açıklayabileceğiniz ve bakımını yapabileceğiniz koda dönüştürme yeteneğidir.

Bu Durum Ekibiniz İçin Ne Anlama Geliyor?

Bir fikri test etmek için prototip oluşturuyorsanız, vibe coding meşru bir yaklaşımdır. Hala varsayımlarınızı doğruluyorsanız, öğrenme hızı önemlidir. Araçları kullanın, hızlı gidin ve insanlara gösterecek bir şeyler inşa edin.

Ama bu prototip gerçek bir ürün olacaksa, üretilen kodun bir noktada mühendis gibi düşünen birinin filtresinden geçmesi gerekir. Kapı bekçiliği yapmak için değil, işleri yavaşlatmak için değil. Sevk edilen şeyin bir ekip tarafından anlaşılabilecek, bakımı yapılabilecek ve sorun çıktığında güvenebilecekleri kod olmasını sağlamak için.

NameOcean'da bu kalıbı çok sık görüyoruz. Fikirlerini doğrulamak için AI araçlarıyla hızlı ilerleyen girişimler, ardından ölçeklendirmeleri gerektiğinde bir duvara tosluyorlar. İyi olanlar bu noktada mühendislik desteği alıyorlar. Kötü olanlar ise kimsenin gerçekten anlamadığı bir codebase üzerine özellik eklemeye devam ediyorlar.

Amaç AI destekli geliştirmeden kaçınmak değil. Nerede işin başladığını ve bittiğini konusunda dürüst olmak. AI kod üretebilir. Yazılımı siz mühendislik yaparsınız.

Sonuç

Vibe coding harika bir başlangıç noktası. Fikirleri hızlı test etmenin, neyin mümkün olduğunu öğrenmenin ve geleneksel geliştirmeden aylarca sürecek işi hafta sonlarına sığdırmanın bir yolu.

Ama yazılım mühendisliği tam döngüyle ilgili. Gece 2'de bir şeyler ters gittiğinde ekibinizin inceleyebileceği, bakımını yapabileceği ve güveneceği kodla ilgili. İhtiyaç duyulduğunda anlaşılacak ve geri alınabilecek kadar dar değişikliklerle ilgili. Kararlar için, hatta o kararlar AI önerileriyle şekillendirilmiş olsa bile, sorumluluk almayla ilgili.

Tanıdığım en iyi geliştiriciler AI araçlarını yoğun olarak kullanıyorlar. Tek fark, gözlerini açık kullanıyorlar. Üretilen kodun ham malzeme olduğunu, bitmiş ürün olmadığını biliyorlar. Ve bir noktada, harika bir demo ile gerçekten gönderebileceğiniz yazılım arasındaki farkı yaratan mühendislik işini birinin yapması gerektiğini biliyorlar.

O yüzden vibe coding yapmaya devam edin. Hızlı inşa edin, özgürce deneyin ve elinizdeki tüm araçları kullanın. Sadece vibe modundan mühendislik moduna geçme zamanının ne zaman geldiğini bilin. Gelecekteki benliğiniz ve gelecekteki ekibiniz size teşekkür edecektir.