Her şirkette zamanla kritik hâle gelen en az bir Excel dosyası vardır. Adında genellikle “son”, “final” ya da “gerçek” kelimelerinden biri geçer. Teklifler, müşteri notları, stoklar veya onaylar bu dosyada tutulur. Kimse onu bir yazılım projesi olarak başlatmamıştır ama iş bir noktada onsuz yürüyemez hâle gelir.
Vibe coding, böyle bir dosyayı çalışan bir uygulamaya dönüştürmeyi geçmişe göre çok daha erişilebilir kılıyor. Yine de asıl mesele birkaç ekran üretmek değil. Dosyanın içindeki iş kurallarını anlamak, veriyi temizlemek, kullanıcı yetkilerini kurmak ve yeni sistemin eski hesaplarla aynı sonucu verdiğini kanıtlamak gerekiyor. Bu yazıda, hızlı bir prototiple güvenilir bir şirket içi uygulama arasındaki farkı adım adım ele alacağız.
Her şirketin bir “o Excel”i vardır
Bu dosya bazen teklif takibini, bazen üretim planını, bazen de saha ekibinin haftalık görevlerini taşır. Sekmeler yıllar içinde çoğalır. Birkaç kişi yeni sütunlar ekler, bir başkası görünmesin diye bazı sütunları gizler. Formülleri yazan kişi ayrıldığında ise kimse dosyanın tamamına dokunmaya cesaret edemez.
Burada Excel'i küçümsememek gerekir. Çoğu şirket içi uygulamanın ilk hâli zaten bir tablodur. Excel, iş henüz şekillenirken son derece esnek ve ekonomiktir. Sorun, dosyanın üstlendiği sorumluluğun artık bir hesap tablosunun taşıyabileceğinden fazla olmasıdır.
Vibe coding araçları kod üretme süresini ciddi biçimde kısaltabilir. Ancak verinin doğruluğu, iş kuralının yorumu, göç planı ve uygulamanın sorumluluğu hâlâ insan kararına bağlıdır. Başarılı bir dönüşüm, bu iki tarafın sınırını doğru çizer.
Excel ne zaman uygulamaya dönüşmeli?
Kararı “Excel eski görünüyor” diye vermek doğru değildir. Aşağıdaki işaretler daha anlamlıdır:
- Aynı dosyaya birden fazla kişi giriyor ve sürümler birbirine karışıyorsa,
- dosya adlarında “final”, “yeni” ve çalışan isimleri çoğalmaya başladıysa,
- bir sayı değiştiğinde bunu kimin, ne zaman değiştirdiği görülemiyorsa,
- tarih, tutar ve durum alanlarına farklı biçimlerde veri yazılıyorsa,
- süreç yalnızca bir kişinin bildiği formül veya makrolara bağlıysa,
- dosya büyüdükçe açılış ve hesaplama belirgin biçimde yavaşlıyorsa,
- ERP, muhasebe, e-ticaret ya da CRM sistemleriyle veri alışverişi gerekiyorsa,
artık uygulama seçeneğini değerlendirmek gerekir.
Buna karşılık tek kişinin yılda birkaç kez kullandığı, iş kuralları sürekli değişen veya henüz keşif aşamasındaki bir çalışma için Excel hâlâ doğru araç olabilir. İyi bir ekip her tabloyu uygulamaya çevirmeye çalışmaz. Önce dönüşümün gerçekten zaman, hata veya denetim açısından karşılığı olup olmadığına bakar.
Vibe coding burada neyi değiştiriyor?
Vibe coding, geliştiricinin ya da iş uzmanının istediği ürünü doğal dille tarif ederek yapay zekâ destekli bir geliştirme ajanıyla ilerlemesidir. “Teklif listesine tarih filtresi ekle”, “bu rol yalnızca kendi müşterilerini görsün” veya “Windows için kurulabilir paket üret” gibi talepler kod değişikliklerine dönüşebilir.
Bu yaklaşım özellikle ilk iskelette çok etkilidir. Listeleme ekranları, formlar, doğrulamalar, raporlar ve tekrar eden işlemler kısa sürede hazırlanabilir. Aynı uygulamanın web, mobil veya Windows hedefleri için ortak bir ürün mantığı kurmak da daha ulaşılabilir hâle gelir.
Fakat ajan, şirketin yazılı olmayan kuralını kendiliğinden bilemez. “500 bin liranın üzerindeki teklifleri genel müdür onaylar” bilgisi yalnızca çalışanların zihnindeyse, model bu kuralı doğru biçimde kuramaz. Boşluğu çoğu zaman makul görünen bir varsayımla doldurur. Kurumsal yazılımda tehlikeli olan da budur: yanlış sonuç her zaman hatalı görünmez.
Bu nedenle Vibe Coding Eğitimi içinde yalnızca ekran üretimini değil; kapsam çıkarma, test, güvenlik, veri yapısı ve yayın kararlarını da birlikte ele alıyoruz.
Başlamadan önce tek soruluk iş gerekçesi
Kod yazmaya başlamadan önce şu soruya cevap verin: Bu dönüşüm hangi somut sorunu çözecek?
Yanıtı üç parçaya ayırmak işe yarar:
- Süreç her ay kaç saat elle çalışma gerektiriyor?
- Hatalı veya geciken bir kaydın şirkete maliyeti nedir?
- Piyasadaki hazır bir ürün neden bu ihtiyacı karşılamıyor?
Üçüncü madde özellikle önemlidir. Standart bir müşteri takibini özel yazılımla yeniden üretmek yerine iyi bir CRM kullanmak daha doğru olabilir. Özel uygulama; şirkete özgü fiyat hesapları, sıra dışı onay akışları, sektörel kurallar veya mevcut sistemlerle özel entegrasyon gerektiğinde değer üretir.
Bu kısa iş gerekçesi, proje boyunca alınacak kararların ölçüsünü belirler. Kullanıcı yeni bir özellik istediğinde “güzel olur” demek yerine, başlangıçta tanımlanan soruna katkısını değerlendirebilirsiniz.
1. Dosyanın envanterini çıkarın
İlk gün uygulama ekranı çizmek cazip gelir. Yine de önce dosyanın ne yaptığını görmek gerekir. Her sayfanın amacı, başlık satırı, veri hacmi, formülleri, adlandırılmış alanları, doğrulama listeleri ve varsa makroları çıkarılmalıdır.
Yapay zekâ ajanına verilecek görev açık olabilir:
Bu klasördeki Excel dosyasını incele. Her sayfanın amacını, satır ve sütun
yapısını, formül desenlerini, sayfalar arası bağımlılıkları ve veri kalitesi
sorunlarını raporla. Kod yazmaya başlama; önce bulguları ve belirsiz noktaları
listele.
Buradaki amaç, ajanın tek başına karar vermesi değildir. Rapor; süreç sahibi, yazılım ekibi ve dosyayı günlük kullanan kişiler için ortak bir konuşma zemini oluşturur. Çoğu ekip bu aşamada yıllardır doldurulmayan sütunları, birbirini tekrar eden listeleri ve farklı sekmelerde farklı çalışan kuralları ilk kez birlikte görür.
2. İş kurallarını formüllerden çıkarın
Excel formülleri aslında şirketin iş kurallarının sıkıştırılmış hâlidir. İç içe geçmiş bir EĞER formülü, indirim politikasını; bir DÜŞEYARA, müşteri segmentini; koşullu biçimlendirme ise gecikme veya risk tanımını taşıyor olabilir.
Her önemli formül düz Türkçe bir cümleye dönüştürülmelidir. Örneğin:
Bayi müşterilerde belirli tutarın üzerindeki teklifler için ek indirim uygulanır. Standart müşterilerde farklı eşik ve oran kullanılır.
Bu cümle süreç sahibine gösterildiğinde gerçek ihtiyaç ortaya çıkar. Bazen formül güncel değildir, bazen iki departman aynı kuralı farklı yorumluyordur. Uygulama geliştirme çalışmasının en değerli çıktılarından biri, bu belirsizlikleri görünür hâle getirmesidir.
Onaylanan kuralları tek bir dokümanda tutun. Ajanın görevi bu kuralları uygulamak olsun; yeni kural icat etmek değil. Belirsiz bir alan gördüğünde tahmin yürütmek yerine soru sorması gerektiğini proje talimatına açıkça yazın.
3. Tabloyu doğru veri modeline dönüştürün
Excel'de müşteri adı, teklif tutarı, satış temsilcisi ve ürün aynı satırda tekrar edebilir. Uygulamada ise müşteri, teklif, teklif kalemi, kullanıcı ve onay kaydı ayrı varlıklardır. Bu ayrım yalnızca teknik düzen için yapılmaz; aynı müşterinin farklı yazımlarla çoğalmasını ve geçmiş kayıtların sessizce değişmesini önler.
Veri modelini kurarken şu kararlar erkenden verilmelidir:
- Tekrarlanan metinler kontrollü kayıtlara ve ilişkilere dönüştürülmeli.
- Para hesaplarında kayan noktalı sayı yerine kuruş veya güvenilir ondalık tip kullanılmalı.
- Teklif verildiği andaki kur, vergi oranı ve toplam değer tarihsel kayıt olarak korunmalı.
- Kayıtlar fiziksel olarak silinmek yerine pasifleştirilmeli.
- Değişikliği yapan kullanıcı ve değişiklik zamanı kaydedilmeli.
Ajan iyi bir şema taslağı önerebilir. Son kararın ise işin nasıl yürüdüğünü bilen ekip tarafından verilmesi gerekir. Yanlış veri modeli üzerine hızlı yazılmış kod, yalnızca yanlış mimariyi daha çabuk büyütür.
4. “Altın veri seti” ile doğruluğu ölçün
Yeni sistemin doğru çalıştığını güzel görünmesine bakarak anlayamazsınız. Eski Excel'in ürettiği sonuçlarla karşılaştırmanız gerekir.
Bunun için geçmişten farklı durumları içeren sınırlı ama temsil gücü yüksek bir kayıt grubu seçin. Normal teklifler, indirimli işler, iptaller, farklı vergi oranları ve sınır değerler bu grupta yer alsın. Girdilerle birlikte beklenen çıktıları da saklayın. Bu dosya projenin altın veri setidir.
Yeni uygulamadaki hesaplar otomatik testlerle bu sonuçlara karşı çalıştırılabilir:
describe("Excel ile sonuç karşılaştırması", () => {
for (const kayit of altinVeri) {
it(`${kayit.teklifNo} doğru hesaplanmalı`, () => {
const sonuc = teklifHesapla(kayit.girdi);
expect(sonuc.netTutar).toBeCloseTo(kayit.beklenen.netTutar, 2);
expect(sonuc.indirimOrani).toBe(kayit.beklenen.indirimOrani);
});
}
});
Karşılaştırmada çıkan her fark yeni uygulamanın hatası olmayabilir. Bazen Excel'deki yuvarlama veya eski bir formül yanlıştır. Farkın hangi taraftan geldiğine süreç sahibiyle birlikte karar verin ve kararın nedenini kaydedin. Böylece test yalnızca kodu değil, üzerinde uzlaşılan iş davranışını korur.
5. Uygulamayı küçük ve görülebilir parçalara bölün
“Bu Excel'i uygulamaya çevir” çok geniş bir talimattır. Daha iyi sonuç için işi sıraya koyun: veri şeması, kullanıcı girişi, liste ekranı, kayıt formu, hesaplama motoru, onay akışı, rapor ve dışa aktarım.
Her parça bittikten sonra gerçek kullanıcıya gösterin. Kullanıcının alıştığı sütun sırasını ilk sürümde korumak bile uyum sürecini kolaylaştırabilir. Görüşmeler ilerledikçe tasarım sadeleştirilebilir; fakat iş akışını daha ilk günden tamamen yabancı bir düzene çevirmek gereksiz direnç yaratır.
Hedef platformu da ihtiyaca göre seçin. Tarayıcıdan ortak kullanım için web uygulaması; saha çalışması ve cihaz özellikleri için mobil uygulama; yerel dosyalar veya şirket içi masaüstü akışı için Windows uygulaması uygun olabilir. Tek ürün mantığı korunarak farklı arayüzler geliştirmek mümkündür, ancak her platformun gerçek ihtiyacı ayrıca doğrulanmalıdır.
6. Veri göçünü ayrı bir proje gibi yönetin
Eski dosyadaki veriyi yeni sisteme aktarmak genellikle tahmin edilenden uzun sürer. Aynı müşteri adının farklı yazımları, metin olarak tutulmuş tarihler, tutar hücrelerine eklenmiş açıklamalar ve not alanlarında unutulmuş onay bilgileri göç sırasında karşınıza çıkar.
Göç aracı tekrar çalıştırılabilir olmalıdır. İkinci çalıştırmada kopya üretmemeli, her satırı “aktarıldı”, “düzeltildi” veya “reddedildi” olarak raporlamalıdır. Reddedilen satırlar süreç sahibinin inceleyebileceği ayrı bir dosyaya çıkarılabilir.
Yapay zekâ, benzer müşteri adlarını eşleştirmek veya açıklama alanlarını sınıflandırmak gibi işlerde hız kazandırır. Fakat emin olmadığı eşleşmeleri işaretlemeli; kritik birleştirme kararını insan vermelidir. Özellikle müşteri, ödeme ve sözleşme verilerinde otomatik tahminleri doğrudan kalıcı kayda çevirmek doğru değildir.
7. Yetkilendirme ve güvenliği ilk sürüme koyun
Şirket içi olması, uygulamanın kendiliğinden güvenli olduğu anlamına gelmez. Kullanıcının menüde bir bölümü görmemesi yeterli değildir; sunucu da o kaynağa erişim yetkisini kontrol etmelidir.
En azından şu kontroller ilk sürümde bulunmalıdır:
- Kullanıcı oturumu ve rol bazlı erişim,
- sunucu tarafında veri doğrulama,
- dosya yüklemelerinde tür ve boyut sınırı,
- parolaların ve servis anahtarlarının kaynak koddan ayrı tutulması,
- önemli değişiklikler için denetim kaydı,
- hata mesajlarında teknik ve kişisel verinin açığa çıkmaması,
- yedekleme ve geri dönüş adımlarının denenmesi.
Çalışan, müşteri veya tedarikçi verisi işleniyorsa KVKK açısından veri asgari düzeyde toplanmalı, erişim sınırlandırılmalı ve saklama süresi tanımlanmalıdır. BT ve yazılım ekiplerine özel yapay zekâ eğitimi bu noktada geliştirme ekibinin yalnızca araç kullanımına değil, güvenli uygulama pratiğine de odaklanmasına yardımcı olur.
8. Excel'i bir gecede kapatmayın
Yeni uygulama kullanıma açıldığında eski dosyayı hemen devreden çıkarmak risklidir. Kritik süreçlerde iki sistemi kısa bir süre paralel çalıştırmak daha güvenli olur. Haftalık toplamlar, kayıt sayıları ve önemli hesaplar karşılaştırılır.
Paralel dönemin ne zaman biteceğini baştan tanımlayın. Örneğin, iki hafta boyunca kritik hesaplarda fark çıkmaması ve temel kullanıcı akışlarının onaylanması bir bitiş ölçütü olabilir. Ölçüt belirlenmezse eski sistem ya çok erken kapatılır ya da aylarca gölge sistem olarak yaşamaya devam eder.
Bu dönemde kullanıcı geri bildirimlerini “özellik isteği” ve “işi durduran sorun” olarak ayırmak da önemlidir. Önce veri doğruluğu ve temel akışlar güvence altına alınır; konfor özellikleri sonraki sürümlere planlanır.
9. Kodun kurumsal bir sahibi olmalı
Vibe coding ile uygulama hızlı çıkabilir. Fakat uygulamanın altı ay sonra kim tarafından güncelleneceği belli değilse proje tamamlanmış sayılmaz.
Devir paketinde şu parçalar bulunmalıdır:
- Kurulum ve yayınlama talimatı,
- güncel iş kuralları dokümanı,
- kullanıcı rolleri ve yetki matrisi,
- otomatik testlerin çalıştırılma biçimi,
- yedekleme ve geri dönüş prosedürü,
- hata bildirim ve önceliklendirme kanalı,
- teknik sorumlunun adı veya sorumlu ekibin tanımı.
Bu belgeler uygulamayı belirli bir kişiye ya da yapay zekâ aracına bağımlı olmaktan çıkarır. Şirket içi yazılımın değeri, yalnızca bugün çalışmasında değil; yarın güvenle değiştirilebilmesindedir.
Hangi teknoloji seviyesi yeterli?
Her proje büyük bir mimari gerektirmez. İhtiyacı üç seviyede düşünmek işleri sadeleştirir.
Küçük ve tek kullanıcılı süreç: Excel'de kalmak, veri doğrulama kuralları ve Power Query gibi araçlarla dosyayı iyileştirmek yeterli olabilir.
Birkaç ekibin kullandığı KOBİ süreci: Veritabanı, kullanıcı girişi, rol yönetimi ve raporlama içeren sade bir web uygulaması genellikle yeterlidir. Vibe coding en fazla hız kazancını çoğu zaman bu ölçekte sağlar.
Entegrasyon ve denetim gerektiren kurumsal süreç: Geliştirme, test ve canlı ortamlarının ayrılması; merkezi kimlik, ayrıntılı denetim kayıtları, izleme, yedekleme ve felaket kurtarma planı gerekir. Yapay zekâ yine üretimi hızlandırır ama mimari ve güvenlik kararları deneyimli ekip tarafından sahiplenilmelidir.
Teknoloji seçiminde iyi bir ölçü vardır: Ekip, üretilen sistemi anlayabiliyor ve bakımını sürdürebiliyor mu? En yeni araç her zaman en doğru araç değildir.
Temsilî bir dönüşüm örneği
Dört kişinin kullandığı, teklifleri ve indirim hesaplarını yöneten altı sayfalık bir dosya düşünelim. PDF teklifler elle hazırlanıyor, müşteri isimleri farklı yazılıyor ve ay sonunda rakamları uzlaştırmak birkaç gün sürüyor.
İlk aşamada formül desenleri ve yazılı olmayan onay kuralları çıkarılır. Sonra geçmiş kayıtlardan bir karşılaştırma seti hazırlanır. Veri şeması ve temel ekranlar kurulduktan sonra hesaplama motoru bu setle test edilir. Göç birkaç deneme turunda temizlenir; kullanıcılar yeni uygulama ile Excel'i kısa süre birlikte kullanır.
Bu senaryo temsilîdir; süre ve sonuç her şirketin verisine göre değişir. Ancak doğru ilerleme sırası değişmez: önce iş kuralı, sonra test, sonra kod, ardından veri göçü ve kontrollü geçiş.
Vibe coding projelerinde en sık görülen beş hata
İlk prototipi bitmiş ürün sanmak: İlk ekranların hızlı çıkması, veri göçü ve kenar durumların da hızlı biteceği anlamına gelmez.
Testsiz değişiklik yapmak: Ajan kodu yeniden düzenlediğinde eski bir hesap sessizce bozulabilir. Altın veri seti ve otomatik testler bu riski azaltır.
Belirsiz iş kuralını modele bırakmak: Model boşluğu doldurur; fakat kurumsal gerçekliği tahmin ederek bulamaz.
Güvenliği sonraya ertelemek: Yetki modeli sonradan eklendiğinde ekran ve veri yapısının önemli kısmı yeniden ele alınabilir.
Sahipsiz uygulama üretmek: Bakım sorumlusu, dokümantasyon ve geri dönüş planı olmayan uygulama zamanla yeni bir “dokunulmaz Excel”e dönüşür.
Sonuç: hızlı koddan önce açık kurallar
Excel'den uygulamaya geçiş, yalnızca bir teknoloji yenilemesi değildir. Yıllardır dağınık biçimde yaşayan kuralları görünür kılma, veriyi güvenilir hâle getirme ve kurumsal hafızayı koruma çalışmasıdır.
Vibe coding bu süreçte güçlü bir hızlandırıcıdır. En iyi sonucu ise doğru sırayla kullanıldığında verir: dosyayı inceleyin, iş kurallarını yazın, doğrulama setini kurun, uygulamayı küçük parçalarda geliştirin, veriyi kontrollü taşıyın, bir süre paralel çalışın ve sistemi açık bir sorumlulukla devredin.
New Academy'de bu yaklaşımı web, mobil ve Windows uygulamalarını kapsayan Vibe Coding Eğitimi içinde uygulamalı olarak çalışıyoruz. Kurumunuza özgü bir sürecin önce analiz edilmesi gerekiyorsa yapay zekâ danışmanlığı ve PoC ile uygulama danışmanlığı seçeneklerinden de ilerleyebilirsiniz.