Dahili aracınızın aslında hangi problemi çözmesi gerektiği\n\nDahili araçlar genellikle bir kısayol olarak başlar: bir komut veya bir sayfa, bir olay sırasında ekip için 20 dakikayı kurtarır. Risk şu ki, problemi ve sınırları baştan tanımlamazsanız aynı kısayol sessizce ayrıcalıklı bir arka kapıya dönüşebilir.\n\nEkipler genellikle aynı acı her gün tekrar ettiğinde bir araca başvururlar, örneğin:\n\n- Yavaş, tutarsız veya sistemlerin arasında bölünmüş log arama\n- Riskli manuel düzenleme veya doğrudan veritabanı yazımı gerektiren özellik geçişleri\n- Tek bir kişinin dizüstünden çalıştırdığı bir script'e bağımlı veri kontrolleri\n- Basit ama saat 02:00'de kolayca yanlış yapılabilecek on-call görevleri\n\nBu sorunlar küçük hissedilir hasta alet üretimi prod loglarını okuyabildiğinde, müşteri verilerini sorgulayabildiğinde veya bir bayrağı değiştirebildiğinde büyük bir sorun olur. O zaman erişim kontrolü, denetim izleri ve kazara yazımlarla uğraşırsınız. "Sadece mühendisler için" olan bir araç bile geniş bir sorgu çalıştırırsa, yanlış ortamı hedeflerse veya net bir onay adımı olmadan durumu değiştirirse bir aksaklığa yol açabilir.\n\nBaşarıyı dar, ölçülebilir terimlerle tanımlayın: izinleri genişletmeden daha hızlı operasyonlar. İyi bir dahili araç adımları kaldırır, güvenlik önlemlerini değil. Örneğin şüpheli bir faturalama sorununu kontrol etmek için herkese geniş veritabanı erişimi vermek yerine, tek bir soruyu yanıtlayan bir araç inşa edin: “Hesap X için bugünün başarısız faturalama olaylarını göster,” bunu salt-okunur, kapsamlı kimlik bilgileriyle yapın.\n\nBir arayüz seçmeden önce insanların o anda neye ihtiyacı olduğunu belirleyin. Tekrarlanabilir görevler için CLI harikadır. Sonuçların bağlama ve paylaşılan görünürlüğe ihtiyaç duyduğu durumlarda web panosu daha iyidir. Bazen ikisini de sunarsınız, ama sadece bunlar aynı korunmuş işlemler üzerine ince görünümlerse. Amaç yeni bir admin yüzeyi değil, iyi tanımlanmış tek bir yetenektir.\n\n## Tek bir acıyı seçin ve kapsamı küçük tutun\n\nBir dahili aracı kullanışlı (ve güvenli) kılmanın en hızlı yolu, tek bir net işi seçip onu iyi yapmaktır. İlk günden logları, özellik bayraklarını, veri düzeltmelerini ve kullanıcı yönetimini aynı anda halletmeye çalışırsa, gizli davranışlar geliştirecek ve insanları şaşırtacaktır.\n\nGerçek iş sırasında kullanıcının sorduğu tek bir soruyla başlayın. Örneğin: “Bir request ID verildiğinde, servislere yayılmış hatayı ve çevresindeki satırları göster.” Bu dar, test edilebilir ve açıklaması kolaydır.\n\nAracın kimler için olduğunu açıkça belirtin. Yerel olarak debug yapan bir geliştiricinin ihtiyacı, on-call olan birinden farklıdır; her ikisi de destek veya analistten farklıdır. Hedef kitleleri karıştırdığınızda, çoğu kullanıcının asla dokunmaması gereken “güçlü” komutlar eklemeye başlarsınız.\n\nGirdileri ve çıktıları küçük bir sözleşme gibi yazın.\n\nGirdiler açık olmalı: request ID, zaman aralığı, ortam. Çıktılar öngörülebilir olmalı: eşleşen satırlar, servis adı, zaman damgası, sayım. “Ayrıca cache temizler” veya “ayrıca işi yeniden dener” gibi gizli yan etkilerden kaçının. Bunlar kazalara neden olan özelliklerdir.\n\nVarsayılan olarak salt-okunur olun. Arama, diff, doğrulama ve raporlama ile araç yine de değerli olabilir. Yazma eylemlerini yalnızca gerçek bir senaryoyu adlandırabiliyorsanız ve bunları sıkı bir şekilde sınırlandırabiliyorsanız ekleyin.\n\nEkipleri dürüst tutacak basit bir kapsam beyanı:\n\n- Bir birincil görev, bir birincil ekran veya komut\n- Bir veri kaynağı (veya bir mantıksal görünüm), “her şey” değil\n- Ortam ve zaman aralığı için açık bayraklar\n- Önce salt-okunur, arka plan eylemleri yok\n- Yazma varsa, onay gerektir ve her değişikliği logla\n\n## Veri kaynaklarını ve hassas işlemleri erken eşleyin\n\nClaude Code hiçbir şey yazmadan önce aracın dokunacağı şeyleri yazın. Çoğu güvenlik ve güvenilirlik problemi burada ortaya çıkar, UI'da değil. Bu eşlemeyi bir sözleşme gibi ele alın: gözden geçirenlere nelerin kapsamda olduğunu ve nelerin yasak olduğunu söyler.\n\nSomut bir veri kaynağı ve sahipleri envanteri ile başlayın. Örneğin: loglar (app, gateway, auth) ve nerede tutuldukları; aracın sorgulayabileceği tam veritabanı tabloları veya görünümler; özellik bayrağı deposu ve adlandırma kuralları; metrikler ve trace'ler ve hangi etiketlerin güvenli filtreleme için kullanılabileceği; ayrıca ticketing ya da olay sistemlerine not yazıp yazmayacağınız.\n\nArdından aracın izinli olduğu işlemleri adlandırın. “admin” gibi bir izni kullanmaktan kaçının. Bunun yerine denetlenebilir fiiller tanımlayın. Yaygın örnekler: sınırlarla salt-okunur arama ve dışa aktarma, not ekleme (geçmişi düzenlemeden), belirli bayrakları TTL ile değiştirme, sınırlandırılmış backfill'ler (tarih aralığı ve kayıt sayısı) ve etkileri değiştirmeyen dry-run modları.\n\nHassas alanlar açık şekilde ele alınmalı. Hangi alanların maskelenmesi gerektiğine (e-posta, tokenlar, oturum ID'leri, API anahtarları, müşteri tanımlayıcıları) ve hangilerinin yalnızca kısaltılmış olarak gösterilebileceğine karar verin. Örneğin: bir ID'nin son 4 karakterini gösterin veya ham değeri görmeden olayları ilişkilendirmek için tutarlı şekilde hashleyin.\n\nSon olarak saklama ve denetim kurallarında anlaşın. Bir kullanıcı bir sorgu çalıştırır veya bir bayrağı çevirirse, kim yaptığı, ne zaman olduğu, hangi filtrelerin kullanıldığı ve sonuç sayısının kaydedildiğinden emin olun. Denetim günlüklerini uygulama loglarından daha uzun tutun. “Sorgular 30 gün, denetim kayıtları 1 yıl saklanır” gibi basit bir kural bile bir olay sırasında acı verici tartışmaları önler.\n\n## Basit kalan en az ayrıcalık erişim modeli\n\nEn az ayrıcalık sıkıcı bir model tuttuğunuzda en kolay haldedir. Aracın neler yapabileceğini listeleyerek başlayın, sonra her işlemi salt-okunur veya yazma olarak etiketleyin. Çoğu dahili araç için çoğu kişi sadece okuma erişimine ihtiyaç duyar.\n\nBir web panosu için mevcut kimlik sisteminizi (SSO, OAuth ile) kullanın. Yerel parolalardan kaçının. Bir CLI için, kısa süreli tokenları tercih edin; hızlıca süresi dolan ve kullanıcının ihtiyaç duyduğu işlemlerle sınırlı tokenlar iyi çalışır. Uzun süreli paylaşılan tokenlar genellikle ticket'lara yapıştırılır, shell geçmişine kaydedilir veya kişisel makinelerde kopyalanır.\n\nRBAC'ı küçük tutun. Eğer birkaç rolden fazlasına ihtiyacınız varsa, araç muhtemelen çok fazla iş yapıyor demektir. Birçok ekip üç rol ile iyi iş yapar:\n\n- Viewer: salt-okunur, güvenli varsayılanlar\n- Operator: okuma artı düşük riskli bir dizi eylem\n- Admin: nadiren kullanılan yüksek riskli eylemler\n\nOrtamları erken ayırın, UI aynı görünse bile. “Kazara prod yapmayı” zorlaştırın. Ortam başına farklı kimlik bilgileri, farklı konfigürasyon dosyaları ve farklı API uç noktaları kullanın. Bir kullanıcı sadece staging'i destekliyorsa, üretime kimlik doğrulaması bile yapamamalıdır.\n\nYüksek riskli eylemler onay adımı hak eder. Veri silme, özellik bayraklarını değiştirme, servisleri yeniden başlatma veya ağır sorgular çalıştırma gibi işlemler için ikinci bir kişinin kontrolünü düşünün. Pratik desenler arasında hedefi (servis adı ve ortam) içeren yazılı onaylar, kimin istediğini ve kimin onayladığını kaydetme ve en tehlikeli işlemler için kısa bir gecikme veya planlı pencere ekleme bulunur.\n\nEğer Claude Code ile aracı üretiyorsanız, her endpoint ve komutun gerekli rolünü önceden beyan etmesi kuralı olsun. Bu alışkanlık, izinlerin araç büyüdükçe incelenebilir kalmasını sağlar.\n\n## Kazaları ve kötü sorguları önleyen koruyucular\n\nDahili araçların en yaygın başarısızlık modu bir saldırgan değildir. Yorulmuş bir ekip arkadaşının yanlış girdilerle “doğru” komutu çalıştırmasıdır. Koruyucuları ürün özellikleri olarak ele alın, ciladan ziyade gereklilik olarak.\n\n### Güvenli varsayılanlar\n\nGüvenli bir duruşla başlayın: varsayılan olarak salt-okunur. Kullanıcı admin olsa bile araç verileri sadece getirme modunda açılmalı. Yazma eylemlerini isteğe bağlı ve belirgin yapın.\n\nDurumu değiştiren herhangi bir işlem (bayrak çevirme, backfill, kayıt silme) için açıkça yazılarak onay isteyin. “Emin misiniz? y/N” refleksle geçmeye çok kolaydır. Kullanıcıdan ortam adı artı hedef ID gibi belirli bir şeyi tekrar yazmasını isteyin.\n\nSıkı girdi doğrulama çoğu felaketi önler. Gerçekte desteklediğiniz şekilleri kabul edin (ID'ler, tarihler, ortamlar) ve diğerlerini erken reddedin. Aramalar için gücü kısıtlayın: sonuç limitleri koyun, makul tarih aralıkları zorunlu kılın ve log depolarınıza rastgele desenlerin gitmesine izin vermek yerine allow-list yaklaşımı kullanın.\n\nKaçan sorguları önlemek için zaman aşımı ve hız limitleri ekleyin. Güvenli bir araç hızlıca başarısız olur ve nedenini açıklar; asılı kalıp veritabanınızı vurmaz.\n\nİyi çalışan bir koruyucu seti örneği:\n\n- Varsayılan olarak salt-okunur, belirgin bir “yazma modu” anahtarıyla\n- Yazmalar için yazılı onay (env + hedefi içerecek şekilde)\n- ID, tarih, limit ve izin verilen desenler için sıkı doğrulama\n- Sorgu zaman aşımı ve kullanıcı başına hız limitleri\n- Çıktıda ve aracın kendi loglarında sır maskelenmesi\n\n### Çıktı hijyeni\n\nAracın çıktısının ticket'lara ve sohbete kopyalanacağını varsayın. Varsayılan olarak sırları maskalayın (tokenlar, çerezler, API anahtarları ve gerekirse e-postalar). Ayrıca sakladıklarınızı temizleyin: denetim logları neyin denendiğini kaydetmeli, döndürülen ham veriyi değil.\n\nBir log arama panosu için kısa bir önizleme ve bir sayaç döndürün, tam yükleri değil. Birinin gerçekten tam olayı görmesi gerekirse, bunu ayrı, açıkça kapılandırılmış bir eylem yapın ve kendi onayını gerektirsin.\n\n## Claude Code ile çalışırken kontrolü kaybetmeme yolları\n\nClaude Code'u hızlı bir genç meslektaş gibi görün: yardımcı ama zihin okuyucu değil. Sizin işiniz işi sınırlandırmak, gözden geçirilebilir kılmak ve geri alınması kolay hale getirmektir. Bu, güvenli hisseden araçlar ile sizi 02:00'de şaşırtan araçlar arasındaki farktır.\n\n### Modelin takip edebileceği bir spes ile başlayın\n\nKod istemeden önce, kullanıcı eylemini ve beklenen sonucu adlandıran küçük bir spes yazın. Davranışla ilgili olsun, framework ayrıntılarıyla değil. İyi bir spes genellikle yarım sayfaya sığar ve şunları kapsar:\n\n- Komutlar veya ekranlar (tam isimler)\n- Girdiler (bayraklar, alanlar, formatlar, limitler)\n- Çıktılar (ne görünür, ne kaydedilir)\n- Hata durumları (geçersiz girdi, zaman aşımı, boş sonuçlar)\n- İzin kontrolleri (erişim reddedildiğinde ne olur)\n\nÖrneğin, bir log arama CLI'si inşa ediyorsanız, uçtan uca bir komutu tanımlayın: , sonuçlar için katı bir üst sınır ve net bir “erişim yok” mesajı ile.\n\n### Doğrulayabileceğiniz küçük artışlar isteyin\n\nÖnce bir iskelet isteyin: CLI bağlantısı, konfigürasyon yükleme ve stub'lanmış veri çağrısı. Sonra tam olarak bir özelliği tamamlanmış olarak isteyin (doğrulama ve hatalar dahil). Küçük diff'ler incelemeyi gerçek kılar.\n\nHer değişiklikten sonra ne değiştiğini ve nedenini yalın dille açıklamasını isteyin. Açıklama diff ile uyuşmuyorsa, durun ve davranışı ile güvenlik kısıtlarını yeniden ifade edin.\n\nDaha fazla özellik eklemeden önce testleri erken oluşturun. En azından mutlu yol, geçersiz girdiler (hatalı tarihler, eksik bayraklar), izin reddi, boş sonuç ve hız limiti veya arka uç zaman aşımı durumlarını kapsayın.\n\n## CLI vs web panosu: doğru arayüzü seçmek\n\nCLI ve dahili web panosu aynı problemi çözebilir, ama farklı şekillerde başarısız olurlar. Güvenli yolu en kolay yol yapan arayüzü seçin.\n\nCLI genelde hız önemliyken ve kullanıcı ne istediğini zaten bildiğinde en iyisidir. Ayrıca okuma işi akışına iyi uyar çünkü izinleri dar tutabilir ve kazara yazma eylemlerini tetikleyen butonlardan kaçınabilirsiniz.\n\nCLI, on-call sırasında hızlı sorgular, scriptler ve otomasyon, açık denetim izleri (her komut net olarak yazılır) ve düşük dağıtım yükü (tek bir binary, tek bir konfig) için güçlü bir tercihtir.\n\nWeb panosu ise paylaşılan görünürlük veya rehberli adımlar gerektiğinde daha iyidir. İnsanları zaman aralıkları, ortamlar ve önceden onaylanmış eylemler gibi güvenli varsayılanlara yönlendirerek hataları azaltabilir. Panolar takım çapında durum görünümleri, onay gerektiren korunmuş eylemler ve bir butonun ne yaptığını açıklayan yerleşik açıklamalar için de iyidir.\n\nMümkünse her ikisi için aynı backend API'yi kullanın. Kimlik doğrulama, hız limitleri, sorgu limitleri ve denetim kaydı o API'de olsun, UI'da değil. Böylece CLI ve pano farklı ergonomilere sahip istemciler olur.\n\nAyrıca nerede çalıştığına karar verin; çünkü bu riski değiştirir. Dizüstünde çalışan bir CLI token sızdırabilir. Bunu bir bastion hostta veya dahili bir kümede çalıştırmak maruz kalmayı azaltabilir ve loglama ile politika uygulamalarını kolaylaştırır.\n\nÖrnek: log arama için, on-call mühendisi son 10 dakikayı bir servis için çekiyorsa CLI harikadır. Bir olay odasında herkesin aynı filtrelenmiş görünümüne ihtiyaç varsa ve “postmortem için dışa aktar” gibi önceden onaylı bir eylem gerekiyorsa, pano daha iyidir.\n\n## Gerçekçi bir örnek: on-call için log arama aracı\n\nSaat 02:10 ve on-call bir rapor alır: “Pay tıklayınca bazen bir müşteri için başarısız oluyor.” Destek bir request ID içeren ekran görüntüsü göndermiş ama kimse log sistemine rastgele sorgular yapıp admin izinlerini kullanmak istemez.\n\nKüçük bir CLI bunu güvenli şekilde çözebilir. Anahtar, kapsamı dar tutmaktır: hatayı hızlıca bulmak, yalnızca gerekeni göstermek ve üretim verilerini değiştirmemek.\n\n### Minimal bir CLI akışı\n\nZaman sınırlarını zorlayan ve belirli bir tanımlayıcı gerektiren tek bir komutla başlayın. Bir request ID ve bir zaman penceresi zorunlu kılın, kısa bir pencere varsayılan olsun.\n\n\n\nÖnce bir özet döndürün: servis adı, hata sınıfı, sayım ve en iyi 3 eşleşen mesaj. Sonra kullanıcı açıkça genişletme istediğinde yalnızca o zaman tam log satırlarını yazdıran bir genişletme adımı sunun.\n\n\n\nBu iki adımlı tasarım kazara veri dökümlerini önler. Ayrıca aracın güvenli-öncelikli bir yolu olduğu için incelemeleri de kolaylaştırır.\n\n### İsteğe bağlı takip eylemi (yazma yok)\n\nOn-call genellikle bir sonraki kişi için bir iz bırakmak ister. Veritabanına yazmak yerine, ticket notu yükü oluşturan veya olay sisteminde bir etiket uygulayan isteğe bağlı bir eylem ekleyin, ama asla müşteri kayıtlarına dokunmayın.\n\nEn az ayrıcalık için CLI salt-okunur bir log tokenı kullanmalı ve ticket veya etiket eylemi için ayrı, kapsamlı bir token olmalı.\n\nHer çalıştırma için bir denetim kaydı saklayın: kim çalıştırdı, hangi request ID, hangi zaman sınırları kullanıldı ve ayrıntılar genişletildi mi. Bu denetim kaydı bir şey ters gittiğinde veya erişim incelenmesi gerektiğinde güvenlik ağınızdır.\n\n## Güvenlik ve güvenilirlik sorunlarına yol açan yaygın hatalar\n\nKüçük dahili araçlar genellikle “sadece hızlı bir yardımcı” olarak başlar. İşte tam bu yüzden tehlikeli varsayılanlarla sonuçlanırlar. Güveni kaybetmenin en hızlı yolu bir kötü olaydır; örneğin bir aracın read-only olması gerekirken veri silmesi.\n\nEn sık görülen hatalar:\n\n- Araç sadece okumaya ihtiyaç duyduğu halde üretim veritabanına yazma erişimi verme ve sonra "dikkatli oluruz" varsayımı\n- Denetim izi atlanması, böylece sonradan kimin komut çalıştırdığını, hangi girdileri kullandığını ve neyin değiştiğini cevaplayamama\n- Serbest form SQL, regex veya ad-hoc filtrelere izin verip istemeden büyük tabloları veya logları tarayıp sistemleri çökertme\n\n- Ortamları karıştırmak; staging eylemlerinin production'a ulaşması çünkü konfigler, tokenlar veya base URL'ler paylaşılmış\n\n- Terminale, tarayıcı konsoluna veya loglara sır basmak ve sonra bu çıktının ticket ve sohbete kopyalandığını unutmak\n\nGerçekçi bir başarısızlık şöyle görünür: bir on-call mühendisi bir olay sırasında log-search CLI'sini kullanır. Araç herhangi bir regex kabul eder ve bunu log altyapısına gönderir. Pahalı bir desen saatlerce yüksek hacimli loglar üzerinde çalışır, maliyetleri fırlatır ve aramaları yavaşlatır. Aynı oturumda CLI debug çıktısında bir API tokenı yazdırır ve bu token kamuya açık bir olay dokümanına yapıştırılır.\n\n### Çoğu olayı önleyen daha güvenli varsayılanlar\n\nSalt-okunuru gerçek bir güvenlik sınırı olarak ele alın, bir alışkanlık değil. Ortam başına ayrı kimlik bilgileri kullanın ve her araç için ayrı servis hesapları oluşturun.\n\nBirkaç koruyucu çoğu işi yapar:\n\n- Ham SQL yerine izin verilen sorgular (veya şablonlar) kullanın, zaman aralıklarını ve satır sayılarını sınırlandırın\n- Her eylemi istek ID'si, kullanıcı kimliği, hedef ortam ve tam parametrelerle loglayın\n- Ortam seçimini zorunlu kılın, üretim için yüksek sesli onay gerektirin\n- Varsayılan olarak sırları kırpın ve debug çıktısını ayrıcalıklı bir bayrak olmadıkça devre dışı bırakın\n\nAracın tehlikeli bir şeyi tasarımsal olarak yapamaması durumunda, ekibiniz 03:00'te mükemmel dikkat beklemek zorunda kalmaz.\n\n## Aracı yayınlamadan önce hızlı kontrol listesi\n\nDahili aracınız gerçek kullanıcılara ulaşmadan (özellikle on-call için) önce onu bir üretim sistemi gibi ele alın. Erişim, izinler ve güvenlik sınırlarının gerçek olduğundan, ima edilmediğinden emin olun.\n\nErişim ve izinlerle başlayın. Birçok kaza "geçici" erişim kalıcı hale geldiği veya bir aracın zaman içinde sessizce yazma gücü kazandığı için olur.\n\n- kimlerin giriş yapabileceğini, erişimin nasıl verildiğini ve birisi takım değiştirdiğinde aynı gün nasıl kaldırılacağını doğrulayın\n- maksimum 2-3 rol tutun (viewer, operator, admin) ve her rolün ne yapabileceğini yazın\n- görüntüleme varsayılan yol olsun ve veriyi değiştirecek her şey için açık bir rol gerektirin\n- tokenları ve anahtarları depo dışı saklayın ve aracın bunları log veya hata mesajlarında asla yazdırmadığını doğrulayın\n- acil erişim gerekiyorsa, bunun zaman sınırlı ve loglanan bir yolunun olmasını sağlayın\n\nSonra yaygın hataları önleyen koruyucuları doğrulayın:\n\n- silme, backfill veya konfig değişiklikleri için yazılı onay gerektirin\n- sonuç boyutunu sınırlayın, zaman pencerelerini uygulayın ve sorguların sonsuza kadar çalışmasını önleyin\n- ID'leri, tarihleri ve ortam adlarını doğrulayın; “her yerde çalıştır” gibi görünenleri reddedin\n- kimin ne zaman ve nereden ne yaptığını kaydedin; logları olay sırasında kolay aranabilir yapın\n- başarı oranı, gecikme ve en sık hata türlerini izleyin ki bozulma erken fark edilsin\n\nDeğişiklik kontrolünü diğer servislerde olduğu gibi yapın: eş kod incelemesi, tehlikeli yollar için birkaç odaklı test ve hızlı bir geri alma planı (aracı çabuk devre dışı bırakma yolu dahil).\n\n## Sonraki adımlar: güvenli şekilde kullanıma sunma ve geliştirmeye devam etme\n\nİlk sürümü kontrollü bir deney gibi ele alın. Bir takımla, bir iş akışıyla ve küçük bir gerçek görev setiyle başlayın. On-call için bir log arama aracı iyi bir pilot olur çünkü kazançları ölçebilir ve riskli sorguları hızla tespit edebilirsiniz.\n\nYayılımı öngörülebilir tutun: 3–10 kullanıcı ile pilot, staging'de başlama, en az ayrıcalık rolleri ile erişimi kısıtlama (paylaşılan tokenlar değil), net kullanım limitleri belirleme ve her komut veya buton tıklaması için denetim logları kaydetme. Konfigürasyon ve izin değişikliklerini hızla geri alabileceğinizden emin olun.\n\nAracın sözleşmesini yalın dille yazın. Her komutu (veya pano eylemini), izin verilen parametreleri, başarının neye benzediğini ve hataların ne anlama geldiğini listeleyin. İnsanlar çıktılar belirsiz olduğunda dahili araçlara güvenmeyi bırakır, kod doğru olsa bile.\n\nGeribildirim döngüsü ekleyin ve gerçekten kontrol edin. Hangi sorguların yavaş olduğunu, hangi filtrelerin yaygın olduğunu ve hangi seçeneklerin insanları şaşırttığını takip edin. Tekrarlanan geçici çözümler görüyorsanız, bu genellikle arayüzün güvenli bir varsayılanı eksik olduğunu gösterir.\n\nBakım için bir sahip ve bir program belirleyin. Kim bağımlılıkları güncelleyecek, kim kimlik bilgilerini döndürecek ve araç bir olay sırasında bozulduğunda kim aranacak karar verin. AI tarafından üretilen değişiklikleri de bir üretim servisi gibi inceleyin: izin farkları, sorgu güvenliği ve loglama.\n\nEkip sohbetine dayalı yinelemeyi tercih ediyorsanız, Koder.ai (koder.ai) küçük bir CLI veya pano oluşturmak, bilinen iyi durumların anlık görüntülerini tutmak ve bir değişiklik risk getirdiğinde hızlıca geri almak için pratik bir yol olabilir.
