01 Eyl 2025·8 dk
Bir AI Destekli İş Akışıyla Fikirden Canlı Uygulamaya
Bir AI destekli tek iş akışı kullanarak bir uygulama fikrinden konuşlandırılmış ürüne nasıl geçileceğini gösteren uygulamalı, uçtan uca anlatı — adımlar, istemler ve kontroller.
Bir AI destekli tek iş akışı kullanarak bir uygulama fikrinden konuşlandırılmış ürüne nasıl geçileceğini gösteren uygulamalı, uçtan uca anlatı — adımlar, istemler ve kontroller.
Küçük ve kullanışlı bir uygulama fikri hayal edin: kafede çalışan bir görevlinin bir düğmeye dokunarak müşteriyi bekleme listesine ekleyebildiği ve masa hazır olduğunda otomatik SMS gönderildiği bir “Queue Buddy”. Başarı ölçütü basit ve ölçülebilir: iki hafta içinde ortalama bekleme süresiyle ilgili kafa karıştırıcı aramaları %50 azaltmak, aynı zamanda personel eğitiminin 10 dakikanın altında kalması.
Bu makalenin ruhu budur: net, sınırlı bir fikir seçin, “iyi”nin ne demek olduğunu tanımlayın ve ardından araçlar, dökümanlar ve zihinsel modeller arasında sürekli geçiş yapmadan fikirden canlı dağıtıma ilerleyin.
Tek iş akışı, fikirin ilk cümlesinden ilk üretim sürümüne kadar bir sürekli ipliktir:
Yine de birden çok araç (editör, repo, CI, hosting) kullanırsınız; ama proje her aşamada “yeniden başlamaz”. Aynı anlatı ve kısıtlar devam eder.
AI en değerli olduğunda:
Ama ürün kararlarına sahip olan sizsiniz. İş akışı, her zaman doğrulama yapmanızı sağlayacak şekilde tasarlandı: Bu değişiklik metriği ilerletiyor mu? Yayına almak güvenli mi?
Aşağıdaki bölümlerde adım adım ilerleyeceksiniz:
Sonunda, “fikir”den “canlı uygulama”ya geçmek için kapsamı, kaliteyi ve öğrenmeyi sıkı tutan tekrarlanabilir bir yolunuz olmalı.
AI'dan ekranlar, API'lar veya veritabanı tabloları taslağı istemeden önce keskin bir hedefe ihtiyacınız var. Buraya harcanan biraz netlik, sonraki saatlerin “neredeyse doğru” çıktılarından sizi kurtarır.
Bir uygulama inşa ediyorsunuz çünkü belirli bir grup insan aynı sürtüşmeyi sürekli yaşıyor: önemli bir görevi hızlı, güvenilir veya emin olarak tamamlayamıyorlar. V1 hedefi, o iş akışındaki tek acı verici adımı ortadan kaldırmaktır—her şeyi otomatikleştirmeye çalışmadan—böylece kullanıcılar “X yapmam lazım”dan “X tamam”a dakikalar içinde, ne olduğu kaydıyla ulaşır.
Birincil kullanıcıyı seçin. İkincil kullanıcılar bekleyebilir.
Varsayımlar, iyi fikirlerin sessizce başarısız olduğu yerdir—onları görünür kılın.
Versiyon 1 küçük ama gönderilebilir bir zafer olmalı.
Hafif bir gereksinim dokümanı (tek sayfa düşünün) “havalı fikir” ile “inşa edilebilir plan” arasındaki köprüdür. Odağınızı korur, AI asistanınıza doğru bağlamı verir ve ilk sürümün aylar sürecek bir projeye dönüşmesini önler.
Kısa ve gözden geçirilebilir tutun. Basit şablon:
En fazla 5–10 özellik yazın, çıktılar olarak ifade edin. Sonra sıralayın:
Bu sıralama, AI ile üretilen planları ve kodu yönlendirmenin de yoludur: “Önce sadece must-have'leri uygula.”
İlk 3–5 özellik için her birine 2–4 kabul kriteri ekleyin. Düz dil ve test edilebilir ifadeler kullanın.
Örnek:
Kısa bir “Açık Sorular” listesiyle bitirin—bunları bir sohbet, bir müşteri görüşmesi ya da hızlı bir aramayla cevaplayabilirsiniz.
Örnekler: “Kullanıcılar Google ile girişe ihtiyaç duyar mı?” “Saklanması gereken minimum veri nedir?” “Yönetici onayı gerekli mi?”
Bu doküman evrak işi değil; inşa ilerledikçe güncelleyeceğiniz ortak bir gerçek kaynağıdır.
AI'dan ekran veya kod üretmeden önce ürünün hikayesini netleştirin. Hızlı bir yolculuk taslağı herkesin aynı sayfada kalmasını sağlar: kullanıcı ne yapmaya çalışıyor, başarı nasıl görünüyor ve nerede işler ters gidebilir.
Mutlu yolla başlayın: ana değeri sağlayan en basit sıra.
Örnek akış (genel):
Sonra olası ve maliyetli birkaç kenar durumu ekleyin:
Büyük bir diyagrama gerek yok. Numaralı bir liste ve notlar, prototipleme ve kod üretimini yönlendirmek için yeterlidir.
Her ekran için kısa bir “yapılacak iş” yazın. Görünüm odaklı değil, çıktı odaklı tutun.
AI ile çalışıyorsanız, bu liste harika bir prompt materyali olur: “Dashboard üret: X, Y, Z'yi desteklesin ve boş/yüklenme/hata durumlarını içersin.”
Bunu “peçete şeması” seviyesinde tutun—ekranları ve akışları destekleyecek kadar.
İlişkileri (User → Projects → Tasks) ve izinleri etkileyen herhangi bir şeyi not edin.
Hataların güveni zedelediği noktaları işaretleyin:
Bu, aşırı mühendislik hakkında değil—çalışan bir demo'yu destek gerektiren bir lansmana dönüştürecek sürprizleri önlemekle ilgili.
Versiyon 1 mimarisi tek bir şeyi iyi yapmalı: en küçük kullanılabilir ürünü göndermenize izin vermek ve kendinizi köşeye sıkıştırmamak. İyi bir kural: “bir repo, bir dağıtılabilir backend, bir dağıtılabilir frontend, bir veritabanı”—ve açık bir gereksinim zorlamadıkça fazlasını eklemeyin.
Tipik bir web uygulaması için akla yatkın bir varsayılan:
Hizmet sayısını düşük tutun. v1 için iyi yapılandırılmış bir “modüler monolit”, microservice'lerden genelde daha kolaydır.
Eğer mimari, görevler ve üretilen kod arasında sıkı bağlantı kuran AI-odaklı bir ortam tercih ediyorsanız, Koder.ai gibi platformlar iyi olabilir: v1 kapsamını sohbetle tanımlayın, “planlama modu”nda yineleyin ve React frontend ile Go + PostgreSQL backend üretebilirsiniz—inceleme ve kontrol sizde kalır.
Kod üretmeden önce küçük bir API tablosu yazın ki AI ile hedef ortak olsun. Örnek şekil:
GET /api/projects → { items: Project[] }POST /api/projects → { project: Project }GET /api/projects/:id → { project: Project, tasks: Task[] }POST /api/projects/:id/tasks → { task: Task }Durum kodları, hata formatı (ör. { error: { code, message } }) ve varsa sayfalandırma notlarını ekleyin.
Eğer v1 gizli değilse veya tek kullanıcılıysa, auth atlayıp daha hızlı gönderin. Hesap gerekiyorsa, yönetilen sağlayıcı kullanın (e-posta sihirli linki veya OAuth) ve izinleri basit tutun: “kullanıcı kendi kayıtlarına sahiptir.” Karmaşık roller gerçek kullanım gerektirmedikçe beklesin.
Birkaç pratik kısıt belgeleyin:
Bu notlar, AI destekli kod üretimini sadece çalışır değil, konuşlandırılabilir hale getirmeye yönlendirir.
Hızınızı kesmenin en hızlı yolu bir hafta araç tartışmak ve hâlâ çalıştırılabilir kodun olmamasıdır. Buradaki hedef: yerel olarak başlayan, görünür bir ekranı olan ve bir isteği kabul eden bir “hello app”e ulaşmak—ayrıca her değişiklik kolayca gözden geçirilebilecek kadar küçük kalmalı.
AI’ya sıkı bir prompt verin: çatı tercihi, temel sayfalar, bir stub API ve beklenen dosyalar. Öngörülebilir konvansiyonlar arayın, zekice çözümler değil.
İyi ilk geçiş şu yapıyı ister:
/README.md
/.env.example
/apps/web/
/apps/api/
/package.json
Tek repo kullanıyorsanız, temel rotalar (örn. / ve /settings) ve bir API uç noktası (örn. GET /health veya GET /api/status) isteyin. Bu altyapının çalıştığını kanıtlamaya yeter.
Koder.ai kullanıyorsanız, minimal “web + api + database-ready” iskeleti istemek de doğal bir başlangıçtır; yapıyı ve konvansiyonları memnun kalana kadar yineleyip sonra kaynağı dışa aktarabilirsiniz.
UI'yi kasıtlı olarak sıkıcı tutun: bir sayfa, bir düğme, bir çağrı.
Örnek davranış:
Bu, anında geri bildirim döngüsü sağlar: UI yükleniyor ama çağrı başarısız oluyorsa, nerede arama yapacağınızı bilirsiniz (CORS, port, yönlendirme, ağ hataları). Burada auth, veritabanı veya karmaşık state eklemeyin—iskelet stabil olduktan sonra bunlar eklenir.
İlk günden .env.example oluşturun. Bu “benim makinemde çalışıyor” sorunlarını önler ve onboarding'i kolaylaştırır.
Örnek:
WEB_PORT=3000
API_PORT=4000
API_URL=http://localhost:4000
README'yi bir dakikadan kısa sürede çalışacak şekilde yazın:
.env.example → .env kopyalaBu aşamayı temiz bir temel çizgisi gibi ele alın. Her küçük başarıdan sonra commitleyin: “init repo,” “web kabuğu eklendi,” “api health endpoint eklendi,” “web api ile bağlandı.” Küçük commitler AI destekli yinelemeyi güvenli kılar: üretilen bir değişiklik ters giderse, bir günü kaybetmeden geri alabilirsiniz.
İskelet uçtan uca çalıştıktan sonra “her şeyi bitirme” dürtüsüne direnin. Bunun yerine veritabanı, API ve UI'yi (varsa) kapsayan dar dikey bir dilim yapın, sonra tekrarlayın. İnce dilimler ince inceleme, küçük hatalar ve AI yardımıyla doğrulamayı kolaylaştırır.
Uygulamanızın çalışması için vazgeçilmez bir modeli seçin—çoğunlukla kullanıcıların oluşturduğu “şey”. Bunu açıkça tanımlayın (alanlar, zorunlu/isteğe bağlı, varsayılanlar), sonra ilişkisel veritabanı kullanıyorsanız migration ekleyin. İlk versiyonu sade tutun: erken normalizasyon ve esneklikten kaçının.
AI model taslağı oluşturuyorsa, her alan ve varsayılan için bir cümleyle gerekçe istemesini söyleyin. Açıklayamadığı bir şey v1'e girmemeli.
İlk kullanıcı yolculuğu için gereken create/read ve minimal update endpoint'lerini oluşturun. Doğrulamayı sınırda tutun (request DTO/schema) ve kuralları açık yapın:
Doğrulama bir süsleme değil—dağınık veri girişini önleyen bir parçadır.
Hata mesajlarını hata ayıklama ve destek için bir UX olarak ele alın. İstemcilere neyin yanlış olduğunu ve nasıl düzelteceklerini açıkça söyleyin, ama hassas detayları sızdırmayın. Sunucu tarafında istek ID ile teknik bağlamı loglayın ki olayları tahmin etmeden izleyebilin.
AI'dan artımlı, PR boyutunda değişiklikler isteyin: bir migration + bir endpoint + bir test gibi. Bir iş arkadaşınızın kodunu inceler gibi diff'leri inceleyin: adlandırma, kenar durumları, güvenlik varsayımları ve değişikliğin gerçekten kullanıcının “küçük zafer”ine hizmet edip etmediğini kontrol edin. Fazladan özellik ekliyorsa, kesin ve ilerleyin.
V1 için kurumsal seviyede güvenliğe ihtiyaç yok—ama tahmin edilebilir hatalardan kaçınacak kadar güvenli olması gerekiyor. Hedef: “yeterince güvenli”: kötü girişi önle, varsayılan olarak reddet ve bir sorun olduğunda iz bırak.
Her sınırı güvensiz kabul edin: form alanları, API yükleri, sorgu parametreleri ve hatta dahili webhook'lar. Tip, uzunluk ve izin verilen değerleri doğrulayın; veriyi normalize edin (string trim, durum dönüştürme) ve öyle saklayın.
Pratik varsayılanlar:
AI ile handler üretirken, doğrulama kurallarını açıkça belirtmesini isteyin (ör. “max 140 chars” veya “bunlardan biri olmalı: …”)—genel “girişi doğrula” demek yerine.
Basit bir izin modeli genelde v1 için yeterlidir:
Sahiplik kontrollerini merkezi ve yeniden kullanılabilir yapın (middleware/policy fonksiyonları), böylece kod tabanına “if userId == …” karışmaz.
İyi loglar şunu cevaplar: ne oldu, kime oldu ve nerede oldu? İçerik:
update_project, project_id)Olayları loglayın, sırları değil: şifreler, tokenlar veya ödeme detaylarını tam yazmayın.
Uygulamayı “yeterince güvenli” ilan etmeden önce kontrol edin:
Testler mükemmel skor için değil—kullanıcıları inciten, güveni bozan veya pahalı acil durumlara yol açan hataları önlemek içindir. AI destekli iş akışında testler ayrıca üretilen kodu niyetinizle hizalayan bir “sözleşme” işlevi görür.
İlk çok kapsam eklemeden önce hatanın maliyetli olacağı yerleri belirleyin. Tipik yüksek risk alanları: para/puanlar, izinler, veri dönüşümleri ve kenar durum doğrulama. Önce bu parçalar için birim testleri yazın. Testler küçük ve spesifik olmalı: girdi X verildiğinde çıktı Y beklenir (veya hata).
Bir fonksiyonun dallanması çoksa ve temiz test yazamıyorsanız, fonksiyonu sadeleştirin.
Birim testleri mantık hatalarını yakalar; entegrasyon testleri “kablolama” hatalarını yakalar—rotalar, DB çağrıları, auth kontrolleri ve varsa UI akışının birlikte çalışması.
Ana yol için otomatik bir uçtan uca test seçin:
Birkaç sağlam entegrasyon testi, onlarca küçük testten daha fazla olayı önleyebilir.
AI test iskeleti üretmede ve gözden kaçırabileceğiniz kenar durumları listelemede iyidir. İsteyebilecekleriniz:
Sonra üretilen her iddiayı gözden geçirin. Testler davranışı doğrulamalı, implementasyon detayını değil. Bir test bir bug olsa bile geçiyorsa, işe yaramıyordur.
Makul bir hedef seçin (ör. temel modüllerde %60–70) ve bunu kılavuz olarak kullanın, hedef olarak değil. Hızlı, tekrarlanabilir testler yazın; CI'da çabuk çalışmalı. Kararsız testler güveni yıpratır—bir kez güven kayboldu mu, test takımı korumayı bırakır.
Otomasyon, AI destekli iş akışının “benim makinemde çalışan proje” olmaktan çıkıp güvenle gönderebileceğiniz bir sürece dönüşmesidir. Amaç gösterişli araçlar değil—tekrar edilebilirliktir.
Yerelde ve CI'de aynı sonucu üreten bir komut seçin. Node için npm run build; Python için make build; mobilde belirli Gradle/Xcode adımı olabilir.
Geliştirme ve üretim yapılandırmalarını erken ayırın. Basit kural: dev konfigürleri rahat, prod konfigürleri güvenlidir.
{
"scripts": {
"lint": "eslint .",
"format": "prettier -w .",
"test": "vitest run",
"build": "vite build"
}
}
Linter riskli desenleri yakalar (kullanılmayan değişkenler, güvensiz async çağrılar). Formatter tartışmaları önler. Kurallar v1 için mütevazı olsun, ama tutarlı uygulansın.
Pratik kapı sırası:
İlk CI iş akışınız küçük olabilir: bağımlılıkları kur, kapıları çalıştır, hızlıca başarısız ol. Bu, kırık kodun sessizce ana dala karışmasını önler.
name: ci
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
- run: npm ci
- run: npm run format -- --check
- run: npm run lint
- run: npm test
- run: npm run build
Gizli bilgilerin nerede saklanacağına karar verin: CI gizli deposu, parola yöneticisi veya dağıtım platformunun ortam ayarları. Git'e asla commit etmeyin—.env'yi .gitignore'a ekleyin ve güvenli yer tutucular içeren bir .env.example ekleyin.
Yeşil CI'ı dağıtım sürecine bağlarsanız, “yeşil CI” üretime giden tek yol olur—temiz bir sonraki adımdır.
Göndermek tek tık değildir—tekrarlanabilir bir rutindir. v1 hedefi basit: yığınıza uygun bir dağıtım hedefi seçin, küçük artışlarla dağıtın ve her zaman geriye dönebilecek bir yol bırakın.
Platformu uygulamanın çalışma şekline göre seçin:
“Kolay yeniden dağıtma”ya odaklanmak genelde bu aşamada “maksimum kontrol”e odaklanmaktan iyidir.
Eğer araç geçişlerini minimuma indirmek istiyorsanız, build + hosting + rollback araçlarını bir arada sunan platformları düşünün. Örneğin Koder.ai dağıtım ve barındırma ile birlikte snapshots ve rollback desteği sunar—böylece sürümleri tek yönlü kapılar yerine geri alınabilir adımlar olarak ele alabilirsiniz.
Kontrol listesini bir kez yazın ve her yayın için tekrar kullanın. Kısa tutun ki insanlar gerçekten uygulasın:
Bunu repoda (ör. /docs/deploy.md) tutarsanız kodla yakın kalır.
Uygulamanın "ayakta mı ve bağımlılıklarına erişebiliyor mu" sorusuna cevap veren hafif bir uç nokta oluşturun. Yaygın örnekler:
GET /health (load balancer ve uptime monitörleri için)GET /status (uygulama sürümü + bağımlılık kontrolleri dönebilir)Yanıtlar hızlı, cache'siz ve güvenli olsun (gizli ya da iç detaylar yok).
Bir geri alma planı açık olmalı:
Dağıtım geri alınabilir olduğunda, sürüm çıkarmak rutin haline gelir ve daha sık, daha az stresle yayın yapabilirsiniz.
Lansman, gerçek kullanıcıların ne yaptığı, uygulamanın nerede kırıldığı ve hangi küçük değişikliklerin başarı metriğini hareket ettirdiğini öğrenmenin başladığı en faydalı aşamadır. Amaç, inşa etmek için kullandığınız AI destekli iş akışını aynı şekilde kanıta yönlendirmektir.
Üç soruya cevap veren bir minimum izleme setiyle başlayın: Ayakta mı? Hata mı veriyor? Yavaş mı?
Uptime kontrolleri basit olabilir (periyodik sağlık uç noktasına istek). Hata takibi yığın izi ve istek bağlamını yakalamalı (hassas veri toplamadan). Performans takibi ana endpoint'ler ve ön uç sayfa yükleme metrikleri ile başlayabilir.
AI'dan yardım isteyin:
Her şeyi takip etmeyin—uygulamanın işe yaradığını kanıtlayan şeyi takip edin. Birincil başarı metriğini tanımlayın (ör. “tamamlanan ödeme”, “ilk proje oluşturma” veya “takımı davet etme”). Sonra küçük bir funnel enstrümentasyonu kurun: giriş → ana eylem → başarı.
AI'dan olay adları ve özellikler önermesini isteyin, sonra gizlilik ve açıklık açısından gözden geçirin. Olay adlarını sabit tutun; her hafta isim değiştirirseniz trendler anlamsızlaşır.
Basit bir alım oluşturun: uygulama içi kısa bir geri bildirim düğmesi, kısa bir e-posta adresi ve hafif bir bug şablonu. Haftalık triage: geri bildirimleri temalara ayırın, analizlerle ilişkilendirin ve bir sonraki 1–2 iyileştirmeyi belirleyin.
İzleme alarmlarını, analiz düşüşlerini ve geri bildirim temalarını yeni “gereksinimler” gibi ele alın. Aynı sürece besleyin: dokümanı güncelleyin, küçük bir değişiklik önerisi oluşturun, ince dilimlerde uygulayın, hedefe yönelik test ekleyin ve aynı geri alınabilir sürüm sürecinden dağıtın. Ekipler için paylaşılan bir “Öğrenme Günlüğü” sayfası (repo veya iç dokümanlarla bağlantılı) kararları görünür ve tekrarlanabilir kılar.
Bir “tek iş akışı”, fikirden üretime kadar devam eden tek bir sürekli zincirdir ve şunları sağlar:
Hâlâ birden çok araç kullanabilirsiniz, ama proje her aşamada “yeniden başlamaz.”
AI'ı seçenekler ve taslaklar üretmesi için kullanın, sonra siz seçip doğrulayın:
Karar kuralını açık tutun: Bu değişiklik metriği ilerletiyor mu ve yayına almak güvenli mi?
Ölçülebilir bir başarı metriği ve sıkı bir v1 “tamamlama tanımı” belirleyin. Örnek:
Bir özellik bu sonuçları desteklemiyorsa, v1 için hedef dışıdır.
Tek sayfalık, hızlı okunabilir bir PRD hazırlayın. İçermeli:
Sonra 5–10 adet çekirdek özellik yazın ve Must/Should/Nice olarak sıralayın. Bu sıralama, AI tarafından oluşturulan planları ve kodu sınırlamak için kullanılır.
En önemli 3–5 özellik için her birine 2–4 test edilebilir ifade ekleyin. İyi kabul kriterleri şunlardır:
Örnekler: doğrulama kuralları, beklenen yönlendirmeler, hata mesajları ve izin davranışları (ör. “yetkisiz kullanıcı net bir hata görür ve veri sızmaz”).
Numaralı bir “mutlu yol” ile başlayın, ardından yüksek olasılıklı ve yüksek maliyetli birkaç hata durumunu ekleyin:
Basit bir liste yeterlidir; amaç UI durumlarını, API yanıtlarını ve testleri yönlendirmektir.
v1 için mantıklı bir varsayılan: “modüler monolit”
Bir gereksinim zorunlu olmadıkça hizmet eklemeyin. Bu, koordinasyon yükünü azaltır ve AI destekli yinelemeyi gözden geçirmeyi kolaylaştırır.
Kod üretmeden önce küçük bir “API sözleşmesi” yazın:
{ error: { code, message } })Bu, UI ile backend arasındaki uyumsuzlukları önler ve testlere sabit hedefler verir.
Hızlıca bir “hello app” oluşturun:
/health).env.example ve bir README ile 1 dakikadan kısa sürede çalıştırma talimatıKüçük kilometre taşlarını erken commitleyin ki oluşturulan değişiklikler tersine alınabilir olsun.
AI destekli iş akışında en önemli testler:
CI'da basit bir sıra uygulayın: 1) format → 2) lint → 3) testler → 4) build. Testlerin güvenilir ve hızlı olmasına öncelik verin; kararsız testler güveni erozyona uğratır.