Yapay zekayla geliştirilen bir uygulamanın içinde gerçekte ne var: geliştirici olmayanlar için bir tur

Bir açıklama yazdın, başlat’a bastın ve yirmi dakika sonra çalışan bir uygulaman oldu. Harika. Ama şimdi “dosyaları görüntüle”ye tıkladın ve farklı bir dilde yazılmış gibi görünen bir klasör ağacına bakıyorsun. package.json nedir? node_modules içinde neden kırk şey var? “Şema” ne demek ve neden senin bir tane var?

Bu yazı rehberli bir tur. Bir öğretici değil — bir tur. Okuduktan sonra bu dosyaların hiçbirini kendin nasıl yazacağını bilmeyeceksin, ama bir dahaki sefere bir şey garip göründüğünde, uygulamanın hangi köşesini işaret edeceğini bileceksin.

Soyut parçaların tutunacak somut bir şeyi olsun diye boyunca üç sürekli örnek kullanacağım:

• Maya, bir pazarlama lideri, ekibi için bir tavsiye sıralaması geliştirdi.
• Jordan, bir yoga öğretmeni, bir ders randevu sitesi geliştirdi.
• Sam, bir fırın işletiyor, “yarının kruvasanlarını ön sipariş ver” sayfası geliştirdi.

Üçü de bir yapay zeka uygulama oluşturucu kullandı. Üç uygulama da bir müşteriye tamamen farklı görünüyor. Kaputun altında ise şaşırtıcı derecede benzer şekillendirilmişler.

Frontend: müşterinin gerçekte gördüğü şey

Frontend, birinin tarayıcısında yüklenen her şeydir. Düğmeler, düzenler, yazı tipleri, animasyonlar, bir formun sen gönderdikten sonra kendini temizleme şekli. Görebiliyorsan, frontend’dir.

Maya için frontend, sıra, ad ve tavsiye sayısı olan bir sıralamadır. Jordan için bir “rezervasyon yap” düğmesi olan bir ders takvimidir. Sam için her birinin yanında küçük artı-eksi düğmeleri olan bir hamur işleri listesidir.

Projenin içinde frontend genellikle app/, pages/ ya da src/ gibi bir adı olan bir klasörde yaşar. .tsx ya da .jsx ile biten dosyalar görürsün. Her biri kabaca “bir ekran” ya da “bir ekranın bir parçası”dır. Sıralama satırı bir dosyadır. Başlık başka bir dosyadır. Hepsini birbirine bağlayan sayfa üçüncüsüdür.

Yapay zeka oluşturucuya “düğmeleri daha yuvarlak yap” ya da “sıralamayı sağa taşı” dediğinde, değişen kısım budur.

Backend: düşünen kısım

Backend, kimsenin görmediği ama herkesin bağlı olduğu kısımdır. Başka bir yerde — müşterinin tarayıcısında değil, bir sunucuda — çalışan koddur; müşterinin tarayıcısının tek başına güvenilmemesi gereken bir şeyin olması gerektiğinde.

Tarayıcı neden her şeyi yapamaz? Çünkü tarayıcı müşterinin makinesidir ve ona güvenemezsin. Maya’nın sıralaması tavsiye sayılarını tamamen tarayıcıda güncelleseydi, herkes sağ tıklayıp kendine 9.000 tavsiye ekleyebilirdi. İşte backend, kuralların yaşadığı yerdir: “bu kişi bunu yapabilir ama şunu yapamaz”, “bunu gerçekten veritabanına kaydet”, “bu e-postayı gönder”.

Backend genellikle api/, server/ ya da app/api/ adlı bir klasörde yaşar. Oradaki dosyalar genellikle kısadır. Her biri belirli bir isteği ele alır: “bir rezervasyon oluştur”, “bugünün kruvasanlarını listele”, “bir tavsiye ekle”.

Uygulamanda bir şey çalışıp da sonuç kalıcı olmadığında — gönder’e tıklarsın, bir onay görürsün ama yarın veri gitmiştir — hata neredeyse her zaman backend’dedir.

Veritabanı: uygulamanın hafızası

Uygulamanın hafızasını bir sıra dosya dolabı olarak düşün. Her dolabın önünde bir etiket var. Biri “kullanıcılar” diyor. Biri “rezervasyonlar” diyor. Biri “kruvasan_siparişleri” diyor. Her dolabın içinde her çekmece bir satırdır. Her çekmecenin aynı yuva kümesi vardır: bir ad, bir e-posta, bir created_at, bir durum.

O yapı — “hangi dolaplar var, her satırın hangi yuvaları var” — şema olarak adlandırılır. Projedeki en önemli dosyadır, gerçi muhtemelen en sıkıcı görünenidir de. schema.ts, schema.prisma adlı bir dosya ya da db/ veya migrations/ adlı bir klasörün içinde bir şey bul. Aç onu. Uygulamanın dünya hakkında gerçekte hatırladığını yansıtan bir liste görürsün.

Jordan’ın şemasında bir classes tablosu, bir bookings tablosu ve bir users tablosu var. Sam’inkinde products, orders ve order_items var. Maya’nınkinde members ve referrals var. Şemanın şekli, ürünün şeklidir; bu yüzden onu sonradan değiştirmek, düğmelerin görünümünü değiştirmekten daha zordur.

Faydalı bir numara: uygulamanın neyi hatırladığını sade kelimelerle anlatabiliyorsan, genellikle şemayı da anlatabilirsin. “Her müşterinin adını ve e-postasını hatırlıyorum. Her müşteri için verdikleri siparişleri hatırlıyorum. Her sipariş için hangi hamur işlerini ve her birinden kaç tane olduğunu hatırlıyorum.” O cümle, neredeyse kelimesi kelimesine şemadır.

Kimlik doğrulama: kapıdaki fedai

“Auth” birbirine yapıştırılmış iki kelimedir: authentication (kimlik doğrulama — sen kimsin?) ve authorization (yetkilendirme — neye iznin var?). İkisi de genellikle auth/ adlı bir klasördeki küçük bir dosya kümesi tarafından ya da adını tanıyabileceğin bir hizmet tarafından ele alınır: Clerk, Auth0, Supabase Auth, NextAuth.

İki soru farklıdır. Kimlik doğrulama şunu yanıtlar: “bu gerçekten Maya mı?” — genellikle bir parola, bir Google girişi ya da ona e-postayla gönderilen sihirli bir bağlantıyla. Yetkilendirme şunu yanıtlar: “Maya’nın başkalarının tavsiyelerini silmesine izin var mı?” — ve yapay zekayla geliştirilen çoğu uygulama için ilk haftadaki dürüst cevap “kontrol etmeyi unuttuk”tur.

Bu, en sık sessizce bozuk olan kısımdır. Giriş ekranı çalışıyor, bu yüzden güvenli hissettiriyor. Ama backend, giriş yapmış kişinin, verisini okumaya çalıştıkları kişiyle aynı kişi olup olmadığını her zaman kontrol etmiyor. Uygulamanın herhangi bir “benim verim, senin verin” kavramı varsa, yapay zeka oluşturucuya açıkça sor: “Kullanıcıların yalnızca kendi verilerini görebildiğinden ve düzenleyebildiğinden emin ol.” O tek cümlenin ne sıklıkla eksik bir kontrolü ortaya çıkardığına şaşıracaksın.

Entegrasyonlar: geliştirmediğin ama yine de kullandığın şeyler

İşte burası, çoğu geliştirici olmayanın gerçekte ne olduğunu hafife aldığı yerdir. Sam’in “kruvasanların hazır” e-postasını gönderen şey kod değil — SendGrid ya da Resend’deki bir hesap. Jordan’ın ders ödemesini işleyen şey kod değil — Stripe. Maya’nın sıralamasındaki fotoğrafları barındıran şey kod değil — S3 ya da Cloudinary gibi bir depolama hizmeti.

Her entegrasyon iki yerde görünür. Backend’de “hey Stripe, bu kartı çek” diyen küçük bir kod parçası var. Ve bir anahtar var — uzun, gizli bir dizi — güvenli bir yerde saklanır (genellikle kimsenin asla işlememesi gereken .env adlı bir dosya) ve Stripe’a isteğin bir yabancıdan değil, Sam’in fırınından geldiğini kanıtlar.

Uygulamanın neden aniden e-posta göndermeyi durdurduğunu ya da ödeme almayı durdurduğunu merak edersen, sebep neredeyse her zaman şunlardan biridir: süresi dolmuş bir anahtar, ulaşılmış bir kullanım sınırı ya da entegrasyonun politikalarındaki bir değişiklik. Kod bozulmadı. El sıkışma bozuldu.

Dağıtım: internete nasıl ulaşır

Son parça, diskindeki klasörü müşterinin bir URL’de ziyaret edebileceği bir şeye dönüştüren kısımdır. Bu genellikle birlikte çalışan üç küçük şey demektir:

• Sunucu (host): Vercel, Netlify, Fly ya da Render gibi backend’ini çalıştıran ve frontend’ini sunan bir hizmet.
• Alan adı (domain): sunucunu işaret eden mayanin-siralamasi.com gibi bir ad.
• Yapı (build): dağınık kaynak dosyalarını alıp gerçekten çalışan daha yalın, daha hızlı sürüme dönüştüren tarif.

Bir şey yerelde çalışıp da üretimde bozulduğunda, sorun genellikle buradadır. Dizüstünde ayarlı ama sunucuda olmayan bir anahtar. Geliştirmede kurulu ama üretimde olmayan bir kütüphane. Tarayıcında var olan ama canlı sitede olmayan bir veritabanı.

Kendini amorti eden beş dakikalık alışkanlık

Projendeki her dosyayı okumana gerek yok. Çoğunun ne yaptığını bilmene gerek yok. Ama haftada bir kez, yukarıdaki klasörlerin her birini açtığın ve yapay zeka oluşturucuya, sade kelimelerle, neyin değiştiğini sorduğun beş dakikalık bir tur yapmalısın.

Maya bunu her cuma öğleden sonra yapar. Şunu yazar: “Bu hafta şemada ne değişti ve neden?” Ve: “Bu uygulamada istemediğim yeni entegrasyonlar var mı?” Cevaplar neredeyse her zaman içini rahatlatır. Olmadığı birkaç sefer, sorunları hâlâ küçükken yakalar.

Parçaları anlamanın bütün amacı budur. Bir geliştirici olmak değil. Sadece daha iyi sorular sorabilmek.

Sırada nereye gidilir

Bu tur yardımcı olduysa, iki devam yazısı zamanına değer. The ‘looks fine’ bug bu parçalardan biri sessizce bozuk olduğunda ne yapılacağını anlatır ve demo’ya hazır ile üretime hazır uygulamanın ilk aşamadan ikinciye ne zaman geçtiğini nasıl anlayacağını anlatır. Aynı harita, farklı kullanımlar.