02 Ara 2025·7 dk
Mitchell Hashimoto döneminde altyapı soyutlaması
Altyapı soyutlaması modern araç seçimlerini şekillendirir. Dağıtımı hızlandıran ama operasyonel görünürlüğü kaybettirmeyen, görüşlü katmanları nasıl seçeceğinizi öğrenin.
Altyapı soyutlaması modern araç seçimlerini şekillendirir. Dağıtımı hızlandıran ama operasyonel görünürlüğü kaybettirmeyen, görüşlü katmanları nasıl seçeceğinizi öğrenin.
Çoğu ekip yavaşlamaz çünkü kod yazamazlar. Yavaşlar çünkü her ürün ekibi aynı altyapı kararlarını yeniden verir: nasıl dağıtılacağı, konfigürasyonun nerede durduğu, sırların nasıl yönetildiği ve loglama, yedekleme ve geri alma için "tamam" ne demek.
İlk başta bu temelleri yeniden kurmak güvenli hissettirir. Her düğmeyi siz çevirdiğiniz için her şeyi anlarsınız. Birkaç sürüm sonra maliyet beklemeye dönüşür: şablon değişiklikleri için inceleme beklemek, "Terraform bilen" birini beklemek, gevşek bir deploy'u debug edebilen o tek kişiyi beklemek.
Bu tanıdık takas ortaya çıkar: bir soyutlama ile daha hızlı mı ilerleyeceksiniz, yoksa tam kontrolü koruyup her şeyi el ile yapmanın vergisini ödemeye devam mı edeceksiniz. Korku mantıksız değil. Bir araç çok fazla şeyi saklayabilir. Saat 02:00'de bir şey kırıldığında "platform hallediyor" demek bir plan değildir.
Bu gerilim en çok inşa edip çalıştırdığınız şeyin hem geliştiricisi hem operatörü olan ekipler için önemlidir. Eğer nöbetteyseniz hız lazım, ama sistemin nasıl çalıştığına dair bir zihinsel modele de ihtiyacınız var. Ürünü işletmiyorsanız gizlenen detaylar başkasının sorunu gibi gelir. Modern çoğu geliştirici ekibi için yine de bu sizin sorununuzdur.
Yararlı bir hedef basittir: emeği azaltın, sorumluluğu azaltmayın. Daha az tekrar eden karar istiyorsunuz, ama gizem de istemiyorsunuz.
Ekipler aynı baskılar yüzünden köşeye sıkışır: sürüm döngüleri hızlanırken operasyonel beklentiler yüksek kalır; ekipler büyür ve "kabile bilgisi" ölçeklenmeyi durdurur; uyumluluk ve veri kuralları atlanamayacak adımlar ekler; olaylar kullanıcıların kesintisiz hizmet beklediği için daha acı verir.
Mitchell Hashimoto, altyapıyı sıradan ekipler için programlanabilir hissettiren araçlarıyla en çok tanınır. Faydalı ders kim kimin neyi inşa ettiğinden çok, bu tarz araçların neyi değiştirdiğidir: ekipleri istedikleri sonucu tarif etmeye teşvik etti ve tekrarlayan işleri yazılımın halletmesine izin verdi.
Basitçe söylemek gerekirse, bu soyutlama çağıdır. Teslimatın daha büyük kısmı varsayılanları ve en iyi uygulamaları kodlayan araçlar üzerinden gerçekleşir; tek seferlik konsol tıklamaları veya rastgele komutlar daha az olur. Araç, karmaşık bir adımlar dizisini tekrarlanabilir bir yola dönüştürdüğü için daha hızlı ilerlersiniz.
Bulut platformları herkese güçlü yapı taşları verdi: ağlar, yük dengeleyiciler, veritabanları, kimlik. Bu işleri basitleştirmeliydi. Pratikte karmaşıklık genellikle katman yukarı taşındı. Ekipler daha fazla hizmet bağlamak, daha fazla izin yönetmek, daha çok ortamı tutarlı kılmak ve küçük farklılıkların kesintiye dönüşmesine daha çok yol veren durumlarla karşılaştı.
Kuralcı araçlar, altyapı ve teslimat için "standart bir şekil" tanımlayarak yanıt verdi. İşte altyapı soyutlamasının önemi burada başlıyor. Birçok kazara işi ortadan kaldırır, ama aynı zamanda günlük düşünmenize gerek olmayanları da belirler.
Bunu değerlendirmek için pratik bir yol: aracın hangi şeyi sıkıcı hale getirmeye çalıştığını sorun. İyi cevaplar genellikle; geliştirme, staging ve prod arasında öngörülebilir kurulum; kabile bilgisine ve el yazısı çalıştırma kitapçıklarına daha az bağımlılık; ve geri almaların/yeniden kurulumların kahramanca değil rutinsel hissettirmesi olur. İyi yapıldığında, incelemeler de "doğru şeyi tıkladın mı?" yerine "bu doğru değişiklik mi?" sorusuna kayar.
Hedef gerçeği saklamak değil. Tekrarlanabilir parçaları paketleyip insanların ürün işine odaklanmasını sağlamak, aynı zamanda çağrı geldiğinde ne olacağını anlamayı kolaylaştırmalıdır.
Bir altyapı soyutlaması, birçok küçük adımı tek daha basit eyleme çeviren bir kestirmedir. Bir imaj nasıl oluşturulur, nasıl push edilir, veri tabanı migration'ı nasıl çalıştırılır, servisi nasıl güncellersiniz ve sağlığı nasıl kontrol edersiniz diye hatırlamak yerine bir komut çalıştırırsınız veya bir düğmeye basarsınız ve araç bu diziyi yapar.
Basit bir örnek, "deploy"ün tek eylem haline gelmesidir. Altında hala çok şey olur: paketleme, konfigürasyon, ağ kuralları, veritabanı erişimi, izleme ve geri alma planları. Soyutlama size çekilecek tek bir kol verir.
Çoğu modern soyutlama aynı zamanda kuralcıdır. Bu, varsayılanlarla ve tercih edilen bir çalışma şekliyle gelir demektir. Araç uygulamanızın nasıl yapılandırılacağına, ortamların nasıl adlandırılacağına, sırların nerede saklanacağına, bir "servis"in ne olduğuna ve "güvenli deploy"un nasıl göründüğüne karar verebilir. Hız alırsınız çünkü her seferinde düzinelerce küçük seçim yapmaktan vazgeçersiniz.
Bu hızın gizli bir maliyeti vardır: varsayılan dünya gerçek dünyanızla eşleşmediğinde sorun çıkar. Belki şirketiniz belirli bir ülkede veri yerleşimi gerektiriyor, daha sıkı denetim logları, alışılmadık trafik desenleri veya yaygın olmayan bir veritabanı kurulumu gerekiyor. Kuralcı araçlar harika hissedebilir ta ki çizgilerin dışına çıkmanız gereken gün gelene kadar.
İyi bir altyapı soyutlaması kararları azaltmalı, sonuçları azaltmamalıdır. Sizi meşguliyetten kurtarmalı, önemli gerçekleri ise görmek ve doğrulamak için kolay hale getirmelidir. Pratikte "iyi" genellikle şunu ifade eder: mutlu yol hızlıdır, ama kaçış yolları vardır; değişeceği önceden görebilirsiniz (planlar, diff'ler, önizlemeler); hatalar okunabilir kalır (açık loglar, net hatalar, kolay geri alma); ve sahiplik belirgindir (kim deploy edebilir, kim onaylar, kim nöbette).
Bunun gerçek takımlarda görünüşüne bir örnek: Koder.ai gibi üst düzey bir platform kullanıp sohbet aracılığıyla bir uygulama oluşturup dağıtmak; barındırma, anlık görüntüler ve geri alma sunulur. Bu birkaç günlük kurulumu kaldırabilir. Ama ekip yine de uygulamanın nerede çalıştığını, logların ve metriklerin nerede olduğunu, bir migration sırasında ne olduğunu ve bir deploy yanlış giderse nasıl kurtarılacağını bilmelidir. Soyutlama bu cevapları bulmayı zorlaştırmak yerine erişimi kolaylaştırmalıdır.
Çoğu ekip daha az insanla daha fazla şey göndermeye çalışıyor. Daha fazla ortamı (dev, staging, prod ve bazen branch önizlemeleri), daha fazla servisi ve daha fazla entegrasyonu destekliyorlar. Aynı zamanda sürüm döngüleri kısalıyor. Kuralcı araçlar, uzun bir karar listesini küçük bir varsayılan kümesine çevirdiği için rahatlama gibi hissettirir.
Onboarding büyük bir çekimdir. İş akışları tutarlı olduğunda yeni bir işe başlayan kişi bir hizmet oluşturma, sır ayarlama, migration çalıştırma ve deploy etme için beş farklı yolu öğrenmek zorunda kalmaz. Herkesin izlediği aynı yolu takip edip daha erken katkı sağlar. Bu tutarlılık ayrıca "kabile bilgisi" sorununu azaltır; sadece bir kişinin nasıl build veya deploy edildiğini hatırladığı durumları azaltır.
Standartlaşma diğer bariz kazançtır. Aynı şeyi yapmanın daha az yolu olduğunda, daha az tek seferlik betik, daha az özel durum ve daha az önlenebilir hata olur. Ekipler sıklıkla soyutlamaları bu yüzden benimser: gerçeği saklamak için değil, sıkıcı parçaları tekrarlanabilir desenlere paketlemek için.
Tekrarlanabilirlik ayrıca uyumluluk ve güvenilirlikle de yardımcı olur. Her hizmet aynı temel (loglama, yedekler, asgari ayrıcalık erişimi, uyarılar) ile oluşturulmuşsa, iç incelemeler kolaylaşır ve olay yanıtı daha hızlı olur. "Ne değişti ve ne zaman?" sorusuna da daha kolay cevap verirsiniz çünkü değişiklikler aynı yoldan akar.
Pratik bir örnek: küçük bir ekip, standart bir React ön yüzü ve Go arka ucu ile PostgreSQL kuran, ortam değişkeni konvansiyonlarını zorunlu kılan ve anlık görüntüler ile geri almayı sunan bir araç seçebilir. Bu operasyonel işi kaldırmaz, ama tahmin gereksinimini azaltır ve "doğru yol"u varsayılan yapar.
Soyutlamalar harikadır ta ki saat 02:00'de bir şey bozulana kadar. O zaman önemli olan tek şey nöbetteki kişinin sistemin ne yaptığını görüp doğru düğmeyi güvenli şekilde çevirebilmesidir. Bir soyutlama teslimatı hızlandırır ama teşhisi engelliyorsa, hız karşılığında tekrar eden kesintilere razı olursunuz.
Bir kaç şey görünür kalmak zorunda, kuralcı varsayılanlarla bile:
Görünürlük ayrıca temel soruları hızlıca cevaplayabilmenizi sağlar: hangi sürüm çalışıyor, hangi konfigürasyon geçerli, dünden beri ne değişti ve iş yükü nerede çalışıyor. Eğer soyutlama bu detayları bir UI'nin arkasına gizliyorsa ve denetim izi yoksa, nöbetçilik tahmine dayanır.
Diğer zorunlu unsur kaçış yoludur. Kuralcı araçların varsayılanları, gerçeklik mutlu yola uymadığında geçerli güvenli bir şekilde varsayılanları aşma yöntemi olmalıdır. Bu; zaman aşımlarını ayarlamak, kaynak limitlerini değiştirmek, bir sürümü sabitlemek, tek seferlik migration işi çalıştırmak veya başka bir takımı beklemeden geri alma gibi şeyleri içerebilir. Kaçış yolları belgelenmiş, izinlendirilmiş ve geri alınabilir olmalı; tek kişinin bildiği gizli komutlar olmamalıdır.
Sahiplik son savunmadır. Bir soyutlamayı benimsediğinizde, baştan kimin sonucu sahiplenip sahiplenmeyeceğine karar verin, sadece kullanımı değil. Kim servisin başarısında nöbet taşır, kim soyutlama ayarlarını değiştirebilir ve değişiklikler nasıl incelenir, kim istisnaları onaylar, kim şablonları ve varsayılanları korur ve kim olayları araştırıp düzeltilmiş çözümlerle kapatır—bunları cevaplayabiliyorsanız acı belirsizlikten kurtulursunuz.
Eğer Koder.ai gibi üst düzey bir platform kullanıyorsanız, onu aynı standartlara göre değerlendirin: dışa aktarılabilir kod ve konfigürasyon, net çalışma zamanı bilgisi ve gatekeeper beklemeden üretim debug edilebilecek kadar gözlemlenebilirlik. İşte soyutlamaların kara kutuya dönüşmemesi bu şekilde sağlanır.
Bir soyutlama katmanı seçmek modern görünüme bakmaktan çok, hangi acıyı kaldırmak istediğinizle ilgilidir. Eğer acıyı bir cümleyle tanımlayamıyorsanız, muhtemelen başka bir araçla uğraşmaya başlarsınız.
Önce düz bir şekilde çözmek istediğiniz darboğazı yazın. Spesifik ve ölçülebilir olsun: sürümler üç gün sürüyor çünkü ortamlar elle; olaylar artıyor çünkü konfigürasyon sürükleniyor; bulut harcaması öngörülemez. Bu, demolar parlak görünmeye başladığında konuşmayı somut tutar.
Sonra vazgeçilemezlerinizi (non-negotiables) kilitleyin. Bunlar genelde verinin nerede tutulabileceği, denetimler için nelerin loglanması gerektiği, çalışma süresi beklentileri ve ekibin gece 2'de gerçekçi olarak neyi işletip yönetebileceğidir. Soyutlamalar gerçek kısıtlarla eşleştiğinde en iyi şekilde çalışır, ideallerle değil.
Ardından soyutlamayı bir vaat değil sözleşme olarak değerlendirin. Ona ne verdiğinizi (girdiler), ne aldığınızı (çıktılar) ve işler ters gittiğinde ne olduğunu sorun. İyi bir sözleşme, başarısızlığı sıradanlaştırır.
Bunu yapmak için basit bir yol:
Somut bir örnek: küçük bir web uygulaması inşa eden ekip, React ön yüz ve Go arka uç ile PostgreSQL üreten kuralcı bir yol seçebilir, ama loglara, migrationlara ve dağıtım geçmişine açık erişim şart koşar. Eğer soyutlama şema değişikliklerini gizliyorsa veya geri almaları karmaşık hale getiriyorsa, hızlı yayınlasa bile risklidir.
Sahiplik konusunda da katı olun. Soyutlama tekrarlayan işi azaltmalı, sadece tek bir kişinin anladığı yeni bir kara kutu yaratmamalıdır. Eğer nöbetteki mühendisin "Ne değişti?" ve "Nasıl geri alırız?" sorularına birkaç dakika içinde cevap veremiyorsa, katman çok opaktır.
Beş kişilik bir ekip müşteri portalı ihtiyaç duyuyor: React web UI, küçük bir API ve PostgreSQL veritabanı. Amaç basit: haftalar içinde gönder, aylar değil; ve nöbet yükünü makul tut.
İki yol düşünüyorlar.
Bulut ağı, konteyner çalıştırma ortamı, CI/CD, sır yönetimi, loglama ve yedeklemeleri kuruyorlar. Bu yolda yanlış bir şey yok, ama ilk ay kararlar ve birleştirme işleriyle geçiyor. Her ortam biraz farklı oluyor çünkü biri "sadece staging'in çalışması için biraz değiştirmişti."
Kod incelemesi olduğunda, tartışmanın yarısı dağıtım YAML'ları ve izinler üzerine oluyor, portalın kendisi üzerine değil. İlk prod deploy çalışsa da, ekip artık her değişiklik için uzun bir kontrol listesine sahip oluyor.
Bunun yerine, platformun uygulamayı inşa, dağıt ve çalıştırmak için standart bir yol sağladığı kuralcı bir iş akışı seçiyorlar. Örneğin, sohbetten uygulamayı üreten, dağıtım ve barındırma özelliklerine, özel alan adı, anlık görüntü ve geri almaya güvenen Koder.ai kullanıyorlar.
İyi gidenler hızlı olur:
Birkaç hafta sonra takaslar ortaya çıkar. Maliyetler açık değildir çünkü ekip faturayı satır satır tasarlamamıştır. Ayrıca sınırlarla karşılaşırlar: arka plan işi özel ince ayar gerektirir ve platform varsayılanları onların iş yükü için mükemmel olmayabilir.
Bir olay sırasında portal yavaşlar. Ekip bir şeylerin yanlış olduğunu söyleyebiliyor ama nedenini söyleyemiyor. Veritabanı mı, API mi yoksa upstream servis mi? Soyutlama onları yayınlamaya yardımcı oldu, ama nöbette ihtiyaç duydukları detayları bulanıklaştırdı.
Platformu terk etmeden bunu düzeltirler. İstek oranı, hatalar, gecikme ve veritabanı sağlığı için küçük bir gösterge paneli eklerler. Değiştirebilecekleri onaylı birkaç ayarı yazarlar (zaman aşımı, örnek boyutu, bağlantı havuzu limitleri). Ayrıca açık sahiplik belirlerler: ürün ekibi uygulama davranışından sorumlu, bir kişi platform ayarlarından sorumlu ve herkes olay notlarının nerede olduğunu bilir.
Sonuç sağlıklı bir orta yol olur: daha hızlı teslimat ve işler bozulduğunda sakin kalmak için yeterli operasyonel görünürlük.
Kuralcı araçlar rahatlama gibi gelebilir: daha az karar, daha az hareketli parça, daha hızlı başlangıç. Sorun şu ki, aynı koruyucu çitler sizi hızlandırırken araç dünyanın sizin hakkınızda ne varsaydığını kontrol etmezseniz kör noktalar yaratabilir.
Tekrarlayan tuzaklar şunlardır:
Popülerlik özellikle yanıltıcıdır. Bir araç adanmış bir platform ekibi olan bir şirket için mükemmel olabilir, ama küçük bir ekip için tahmin edilebilir dağıtımlar ve net loglar istiyorsa acı verici olabilir. Desteklemeniz gerekeni sorun, başkalarının konuştuğunu değil.
Çalıştırma kitapçıklarını atlamak başka bir yaygın hata modudur. Platform derlemeleri ve dağıtımları otomatikleştirse bile birisi yine çağrılır. Temel bilgileri yazın: sağlığı nerede kontrol edeceğiniz, dağıtımlar takıldığında ne yapacağınız, sırları nasıl döndüreceğiniz ve kim üretim değişikliğini onaylayabilir.
Geri alma ekstra dikkat gerektirir. Ekipler genelde geri almanın "bir sürümü geri almak" olduğunu varsayar. Gerçekte geri almalar, veritabanı şeması değiştiğinde veya arka plan işler yeni veriyi yazmaya devam ettiğinde başarısız olur. Basit bir senaryo: web uygulaması bir sütunu düşüren bir migration içeriyordur. Deploy bozulur, kodu geri alırsınız ama eski kod eksik kolonu bekler. Veri onarılana kadar hizmet kesintide kalırsınız.
Bulanık sahipliği önlemek için sınırları erkenden kararlaştırın. Her alan için genelde bir sahibi atamak yeterlidir:
Veri ve uyumluluğu sona bırakmayın. İş yüklerini belirli ülkelerde çalıştırmanız veya veri transfer kurallarını karşılamanız gerekiyorsa, aracın bölge seçimlerini, denetim izlerini ve erişim kontrollerini baştan destekleyip desteklemediğini kontrol edin. Koder.ai gibi araçlar ekiplerin uygulamanın nerede çalışacağını seçmelerine izin vererek bunu öne çıkarır, ama yine de müşterilerinizin ve sözleşmelerinizin gereksinimleriyle eşleştiğinden emin olun.
Bir soyutlamaya ekibi yatırmadan önce hızlı bir "commit testi" yapın. Amaç aracın mükemmel olduğunu kanıtlamak değil. Amaç, soyutlamanın bir şey bozulduğunda rutin operasyonları bir gizeme dönüştürmeyeceğinden emin olmaktır.
Değerlendirmeyi yapan ekipte olmayan birisinin cevapları yürütmesini sağlayın. Eğer o kişi cevapları yürütemiyorsa, bugün hız alıp yarın kafa karışıklığı satın alıyor olabilirsiniz.
Barındırılan bir platform kullanıyorsanız, bu soruları somut yeteneklere eşleyin. Örneğin, kaynak kodu dışa aktarma, anlık görüntüler ve geri alma, açık dağıtım ve barındırma kontrolleri, hızlı kurtarmayı ve ihtiyaç değiştiğinde vendor lock-in'i azaltmayı kolaylaştırır.
Bir altyapı soyutlamasını benimsemek en iyi küçük bir yükseltme gibi hissettirdiğinde işe yarar, tam bir yeniden yazma değil. Dar bir iş dilimi seçin, aracın neleri gizlediğini öğrenin, sonra ekip aracı gerçek baskı altında gördükten sonra genişletin.
Düzgün ve hafif bir benimseme planı sizi dürüst tutar:
Başarıyı ölçülebilir kılın. Birkaç sayı takip edin: yeni bir ekip üyesinin ilk deploy süresi, kırık bir sürümden toparlanma süresi ve rutin bir değişiklik için gereken manuel adım sayısı. Araç teslimatı hızlandırıyor ama kurtarmayı yavaşlatıyorsa, bu takası açıkça ortaya koyun.
Koda yakın basit bir "abstraction README" oluşturun ve koda yakın tutun. Bir sayfa yeterli. Ne yaptığını, neleri sakladığını ve bir şey bozulduğunda nerelere bakılacağını söylemeli (loglar nerede, üretilen konfigürasyonu nasıl görürsünüz, sırlar nasıl enjekte edilir, deploy'u lokal olarak nasıl yeniden üretirsiniz). Amaç her detayı öğretmek değil; saat 02:00'de debug yapmayı öngörülebilir kılmaktır.
Hızlı ilerlemek ama sahipliği kaybetmemek istiyorsanız, gerçek projeler üreten ve çalıştıran araçlar pratik bir köprü olabilir. Örneğin, Koder.ai (koder.ai) ekiplerin sohbet yoluyla prototip ve uygulama göndermesini sağlar; planlama modu, dağıtımlar, anlık görüntüler ve geri alma ile kaynak kodu dışa aktarma imkânı vererek kontrolü korumanızı ve isterseniz daha sonra taşınmanızı sağlar.
Pratik bir sonraki adım: bu ay standartlaştırılacak bir iş akışı seçin (web uygulaması deploy'u, migration çalıştırma veya önizleme ortamı oluşturma), onun için bir abstraction README yazın ve 30 gün içinde inceleyeceğiniz iki metrikte anlaşın.
Bir altyapı soyutlaması, birçok operasyonal adımı (derleme, dağıtım, konfigürasyon, izinler, sağlık kontrolleri) daha az sayıda eyleme ve mantıklı varsayılanlara dönüştüren bir kestir.
Kazanç, tekrarlayan karar sayısının azalmasıdır. Risk ise gerçekten neyin değiştiğini ve bir şey bozulduğunda nasıl kurtarılacağını görmekteki kayıptır.
Çünkü kurulum işleri tekrarlanır: ortamlar, sırr yönetimi, dağıtım boru hatları, loglama, yedekler ve geri alma süreçleri.
Hızlı kod yazabilseniz bile, her sürüm aynı operasyonel bulmacaları yeniden çözmeyi veya "o özel" betiği bilen tek kişiyi beklemeyi gerektirdiğinde teslimat yavaşlar.
Temel avantaj, standartlaştırma yoluyla hız sağlamaktır: daha az seçim, daha az tek seferlik betik ve daha tekrarlanabilir dağıtımlar.
Ayrıca işe alıştırmayı iyileştirir; yeni mühendisler her hizmet için farklı bir süreç öğrenmek yerine tek bir tutarlı iş akışını takip eder.
Popülerliğe göre seçmeyin. Bir cümleyle başlayın: Hangi acıyı gideriyoruz?
Sonra doğrulayın:
Nöbetçiyseniz, hızlıca cevap verebilmelisiniz:
Bu cevapları bulmayı zorlaştıran bir araç, prod için çok opaktır.
Aşağıdaki temel unsurlara bakın:
"Uygulama mı, veritabanı mı, yoksa dağıtım mı?" sorusunu birkaç dakika içinde cevaplayamıyorsanız, ölçeklemeden önce görünürlüğü ekleyin.
Geri alma düğmesi yardımcıdır ama sihir değildir. Geri almalar genelde şu yüzden başarısız olur:
Standart uygulama: göçleri geri alınabilir (veya iki adımlı) tasarlayın ve gerçekçi bir "kötü deploy" senaryosunda geri almayı test edin.
Bir kaçış yolu, varsayılanları bozmadan geçiş yapmanın dokümante edilmiş, izinlendirilmiş bir yoludur.
Yaygın örnekler:
Eğer geçişler "gizli komutlar"sa, kabile bilgisini tekrar üretiyorsunuz demektir.
Küçük başlatın:
Ancak ekip gerçek baskı altında aracı gördükten sonra genişletin.
Koder.ai, ekiplerin gerçek uygulamaları sohbet yoluyla prototiplemesine ve göndermesine yardımcı olabilir; genelde ön yüzde React, arka uçta Go ve PostgreSQL ve mobilde Flutter ile. Dağıtım, barındırma, anlık görüntüler ve geri alma özellikleriyle gelir.
Kontrolü korumak için ekiplerin ısrar etmesi gerekir: açık çalışma zamanı bilgisi, erişilebilir log/metric ve kaynak kodu dışa aktarma imkânı, böylece sistem kara kutu olmaz.