AI ile Yapılmış Bir Uygulamada Geliştiriciyle Nasıl Çalışılır

AI ile yaptığınız bir uygulamada geliştiriciyle verimli çalışmak için ona kodu bir Git deposunda verin, uygulamanın ne yaptığını ve neden var olduğunu anlatan bir sayfalık özet hazırlayın ve bitiş tanımıyla birlikte net kapsamlandırılmış bir iş verin. AI'ın ve sizin onların işinin üzerine yazmamanız için kimin hangi parçaları değiştireceğini kararlaştırın, depo ve barındırma hesaplarını kendi adınıza tutun ve gizli bilgileri mesajla değil, uygun ayarlar üzerinden paylaşın.

Birçok kişi uygulamanın ilk sürümünü AI ile yapıp sonra bir geliştirici getiriyor: ödeme eklemek, AI'ın sürekli yanlış yaptığı bir şeyi düzeltmek, güvenlik incelemesi yaptırmak ya da uygulama büyüdükçe işi devralmak için. Hâlâ birini işe alıp almayacağınıza karar vermediyseniz, bir geliştirici tutmak ya da AI ile yapmak yazısına bakın. Bu rehber, kararınızı verdiğinizi ve iş birliğinin sorunsuz ilerlemesini istediğinizi varsayar.

Geliştirici ne zaman değerli olur

Birini dahil etmenin yaygın nedenleri şunlardır:

• AI'ın birkaç net denemeden ve geri almadan sonra çözemediği bir sorun.
• Riskli alanlar: ödemeler, izinler, hassas veriler, veritabanı geçişleri.
• Lansmandan önce ya da daha büyük müşterilere geçmeden önce güvenlik veya kod incelemesi.
• Gerçek trafik geldiğinde performans.
• Büyüme: uygulama bir işe dönüştü ve kodun sahibi olacak birine ihtiyaç var.

Bunlardan hangisinin geçerli olduğunu netleştirmek, aşağıdaki her şeyi belirler.

Adım 1: Kodu paylaşılabilir bir yere alın

Geliştiriciler Git depolarıyla çalışır. Kimseyle iletişime geçmeden önce:

1. Projeyi özel bir GitHub (ya da benzeri) deposuna bağlayın veya dışa aktarın.
2. Kodda ya da geçmişinde gizli bilgi olmadığından emin olun. Bkz. API anahtarlarınızı nasıl güvende tutarsınız.
3. Projenin temiz bir kopyadan çalıştığını kontrol edin: kurulum adımlarını AI'a yazdırın.

Bu projeye katılacak bir geliştirici için README yaz: uygulamanın ne yaptığı, kullanılan teknoloji yığını, yerelde nasıl kurulup çalıştırılacağı, gereken ortam değişkenleri (sadece isimleri), klasör yapısı ve kırılgan ya da alışılmadık olan her şey.

Git size yeniyse, AI ile yapılmış bir uygulamada Git nasıl kullanılır yazısı temelleri anlatır.

Adım 2: Bir sayfalık özet yazın

Geliştirici sohbet geçmişinizi okumadı. Bağlamı tek sayfada verin:

• Uygulamanın ne yaptığı, kimin için olduğu ve kaç kişinin kullandığı.
• En çok neyin önemli olduğu: asla bozulmaması gereken akışlar.
• Bilinen sorunlar ve bunlar için zaten denediğiniz şeyler.
• İş ve bittiğini nasıl anlayacağınız.
• Kısıtlar: bütçe, teslim tarihi, dokunmamaları gereken şeyler.

İyi bir "bitiş tanımı" test edilebilir olmalıdır: "Giriş yapmış bir kullanıcı Stripe Checkout ile aylık bir plan için ödeme yapabilir, plan hesap sayfasında görünür ve müşteri portalında iptal ettiğinde dönem sonunda plan düşürülür." "Ödemeleri halledin" gibi bir ifade yeterli değildir.

Adım 3: Erişimi güvenli biçimde verin

• Kod: Depoya ortak katkıda bulunan olarak ekleyin. İş başladıktan sonra ZIP dosyaları gönderip durmayın.
• Oluşturucu: AI uygulama oluşturucunuz ekip üyelerini destekliyorsa, yalnızca bu projenin bulunduğu bir çalışma alanına davet edin.
• Gizli bilgiler: Bunları barındırma servisinizin ayarlarına ekleyin ya da bir şifre yöneticisi üzerinden paylaşın. Anahtarları asla e-postaya ya da sohbete yapıştırmayın.
• Test hesapları: Kendi giriş bilgilerinizi paylaşmak yerine test verisiyle test hesapları oluşturun.
• Canlı veriler: Yalnızca gerçekten ihtiyaç varsa ve yalnızca ihtiyaç duyulan kadarını.

Depoyu, alan adını ve barındırma hesaplarını kendi adınızda tutun. İnsanları ekleyin; hesapları devretmeyin.

Adım 4: Kimin neyi değiştireceğini kararlaştırın

Sürtünmenin en büyük kaynağı, aynı kodu aynı anda değiştiren iki taraftır: siz AI ile, bir de geliştirici. Bir kural seçin:

Hangisini seçerseniz seçin: her AI istek oturumundan önce en son kodu çekin ve büyük değişiklikleri, diğer kişinin inceleyebileceği dallarda yapın.

Adım 5: Yazılı iletişim kurun

• Sorunları adımlarla, beklenen ve gerçekleşen sonuçla bildirin. Bkz. iyi bir hata raporu nasıl yazılır.
• Kararları tek bir yerde tutun: bir sorun takip aracı, ortak bir belge ya da çekme isteği yorumları.
• Her çekme isteğinde değişiklikleri sade bir dille açıklamalarını isteyin.
• Ne sıklıkta bir araya geleceğinizi kararlaştırın.

Adım 6: İşlerini inceleyin

İşi incelemek için kod okumanız gerekmez. Şunlara bakın:

• Brief'te yazanı yapıyor mu? Önizleme ya da test kopyasında kontrol edin.
• Başka bir şey bozuldu mu? Kritik akışlarınızı çalıştırın.
• Yaptıklarını ve nedenini açıkladılar mı?
• Kodda gizli bilgi kaldı mı?

Daha yakından bakmak için AI ile üretilmiş kod nasıl incelenir yazısında, insan yazımı kod için de işe yarayan bir kontrol listesi var. AI oluşturucunuzdan geliştiricinin çekme isteğini sizin için sade bir dille açıklamasını da isteyebilirsiniz.

Adım 7: Sahipliği net tutun

• Depo, barındırma, alan adı ve üçüncü taraf hesapları size ait kalır.
• Yazdıkları kodun sahipliğini işe başlamadan önce yazılı hâle getirin. Sözleşmeyle ilgili sorular için yerel kurallara ya da bir danışmana bakın.
• İş bittiğinde erişimlerini kaldırın ve gördükleri tüm anahtarları yenileyin.

Örnek istekler

Bir geliştirici son çekme isteğinde ödeme kodunu değiştirdi. Neyi değiştirdiğini ve uygulamanın başka hangi kısımlarının buna bağlı olduğunu sade bir dille açıkla.

Bu uygulamanın en karmaşık ya da riskli kısımlarını listele; böylece bir geliştiriciye incelemesi gereken yeri söyleyebileceğim.

Ödemeleri bir geliştiriciye devrediyorum. Bundan sonra src/payments altındaki ya da /api/billing rotalarındaki hiçbir dosyaya dokunma. Bir değişiklik bunlara ihtiyaç duyarsa, bunun yerine bana söyle.

Sık yapılan hatalar

• Brief yok. Geliştirici, ne istediğinizi tersine mühendislikle çözmek için ücretli saatlerini harcar.
• "Hataları düzeltin" ya da "production'a hazır hale getirin" gibi belirsiz kapsam.
• Önce çekmeden ikisinin birden düzenleme yapması, sonra çakışmalarda işi kaybetmek.
• Kendi giriş bilgilerinizi paylaşmak ya da anahtarları sohbete yapıştırmak.
• Hesapların geliştiricinin adına açılması, bu da ayrılmayı zorlaştırır.
• İş bittikten sonra erişimi kaldırmayı ve anahtarları yenilemeyi unutmak.

Kontrol listesi

• Kod, benim adıma açılmış özel bir depoda, içinde gizli bilgi olmadan duruyor.
• Kurulumu anlatan bir README ve uygulamayı ve işi anlatan bir sayfalık özet var.
• İşin test edilebilir bir bitiş tanımı var.
• Erişim ortak katkıda bulunan davetiyle, gizli bilgiler ayarlar ya da bir şifre yöneticisi üzerinden veriliyor.
• Kimin neyi değiştireceğini kararlaştırdık ve AI istemeden önce çekiyorum.
• İş, özet ve kritik akışlara göre incelenip onaylanıyor.
• Sahiplik yazılı; iş bittiğinde erişim kaldırılıyor ve anahtarlar yenileniyor.

Mythex'te geliştiriciyle çalışmak

• Geliştiriciyi bir çalışma alanına davet edin. Sahipler, koltuk başına ücret olmadan sınırsız ortak katkıda bulunan davet edebilir; üyeler çalışma alanının projelerinde çalışır. Yalnızca bu projeyi görmesi için ayrı bir çalışma alanı kullanın. Yayımlanmış uygulamalar için kredi, çalışma alanının sahibine yansır. Bkz. Davetler.
• GitHub senkronizasyonu ve dışa aktarma (Pro). Bir depoyu bağlayıp gönderebilir ve çekebilir ya da projeyi gizli bilgiler dışarıda bırakılarak dışa aktarabilirsiniz. Bkz. GitHub, dışa aktarma ve içe aktarma.
• Bir önizleme bağlantısı paylaşın. Mythex hesabı olmayan birine devam eden işi göstermek için kullanın; işiniz bittiğinde silin.
• Soru modu kodu değiştirmeden kod hakkındaki soruları yanıtlar; geliştiricinin değişikliklerini anlamak için kullanışlıdır.

Geliştirici uygulamayı başka bir yerde çalıştıracaksa, AI ile yapılmış bir uygulama nasıl dışa aktarılır ve kendi sunucunuzda nasıl barındırılır yazısına bakın.

Sorular