Donanım mühendisliği: ajan öncelikli dünyada Codex'ten yararlanma
Hazırlayan: Ryan Lopopolo, Teknik Personel Üyesi
Son beş aydır ekibimiz bir deney yürütüyor: elle yazılmış 0 satır kod ile bir yazılım ürününün dahili betasını geliştirip yayınlıyor.
Ürünün dahili günlük kullanıcıları ve harici alfa testçileri var. Gönderir, dağıtır, bozar ve onarır. Farklı olan, her bir kod satırının—uygulama mantığı, testler, CI yapılandırması, dokümantasyon, gözlemlenebilirlik ve dahili araçlar—Codex tarafından yazılmış olmasıdır. Bunu, kodu elle yazmak için gereken sürenin yaklaşık 1/10'unda oluşturduğumuzu tahmin ediyoruz.
İnsanlar yönlendirir. Otonom ajanlar yürütür.
Mühendislik hızını katbekat artırmak için gerekenleri inşa edebilmek amacıyla bu kısıtlamayı bilerek seçtik. Sonunda bir milyon satır kod haline gelen şeyi teslim etmek için haftalarımız vardı. Bunu yapmak için, bir yazılım mühendisliği ekibinin birincil görevi artık kod yazmak değil de ortamlar tasarlamak, niyeti belirtmek ve Codex ajanlarının güvenilir bir şekilde çalışmasına olanak tanıyan geri bildirim döngüleri oluşturmak olduğunda nelerin değiştiğini anlamamız gerekiyordu.
Bu yazı, ajanlardan oluşan bir ekiple yepyeni bir ürün geliştirirken neler öğrendiğimiz hakkında. Nelerin bozulduğunu, nelerin biriktiğini ve gerçekten kıt olan tek kaynağımızı, yani insan zamanı ve dikkatini, nasıl en üst düzeye çıkarabileceğimizi anlatıyor.
Boş bir depoya yapılan ilk commit, Ağustos 2025'in sonlarına doğru yapıldı.
İlk iskelet depo yapısı, CI yapılandırması, biçimlendirme kuralları, paket yöneticisi kurulumu ve uygulama çerçevesi, mevcut şablonlardan oluşan küçük bir küme rehberliğinde, GPT‑5 kullanılarak Codex CLI tarafından oluşturuldu. Otonom ajanlara depoda nasıl çalışacaklarını gösteren ilk AGENTS.md dosyası bile Codex tarafından yazılmıştı.
Sistemi temellendirecek önceden var olan, insanlar tarafından yazılmış bir kod yoktu. En başından itibaren depo, otonom ajan tarafından şekillendirildi.
Beş ayın sonunda, depo uygulama mantığı, altyapı, araçlar, belgeler ve dahili geliştirici yardımcı programları genelinde yaklaşık bir milyon satırlık kod içeriyor. Bu süre zarfında, Codex'i yöneten sadece üç mühendisten oluşan küçük bir ekip tarafından yaklaşık 1.500 pull request açılmış ve birleştirilmiştir. Bu, mühendis başına günde ortalama 3,5 PRs işlem kapasitesine karşılık geliyor ve şaşırtıcı bir şekilde ekip şimdi yedi mühendis olmasına rağmen işlem kapasitesi arttı. Önemle belirtmek gerekir ki bu, sırf çıktı olsun diye üretilmiş bir çıktı değildi: ürün, dâhilî olarak yüzlerce kullanıcı tarafından, günlük dâhilî ileri düzey kullanıcılar da dâhil olmak üzere, kullanıldı.
Geliştirme süreci boyunca, insanlar doğrudan hiçbir kod katkısında bulunmadı. Elle yazılmış kod olmaması, ekip için temel bir felsefe haline geldi.
İnsan eliyle doğrudan kodlama yapılmaması sistemler, altyapı ve kaldıraç etkisine odaklanan farklı bir mühendislik türünü ortaya çıkardı.
İlk ilerleme beklediğimizden daha yavaştı; bu, Codex'in yetersizliğinden değil, ortamın yeterince tanımlanmamış olmasından kaynaklanıyordu. Otonom ajan, üst düzey hedeflere ulaşmak için gerekli olan araçlar, soyutlamalar ve iç yapıdan yoksundu. Mühendislik ekibimizin öncelikli görevi, ajanların faydalı işler yapabilmesini sağlamak oldu.
Pratikte bu, derinlemesine çalışmak anlamına geliyordu: daha büyük hedefleri daha küçük yapı taşlarına (tasarım, kod, inceleme, test, vb.) ayırmak, otonom ajanı bu taşları oluşturması için yönlendirmek ve bunları daha karmaşık görevlerin kilidini açmak için kullanmak. Bir şey başarısız olduğunda, çözüm neredeyse hiçbir zaman "daha çok çabalamak" değildi. İlerleme kaydetmenin tek yolu Codex'in işi yapmasını sağlamak olduğundan, insan mühendisler her zaman göreve dahil olur ve şunu sorardı: "Hangi yetenek eksik ve bunu otonom ajan için hem anlaşılır hem de uygulanabilir hale nasıl getiririz?"
İnsanlar sistemle neredeyse tamamen komutlar aracılığıyla etkileşim kurar: bir mühendis bir görevi tanımlar, otonom ajanı çalıştırır ve onun bir pull request açmasına izin verir. Bir PR’yi tamamlamak için Codex’e kendi değişikliklerini yerelde gözden geçirmesini, hem yerelde hem de bulutta ek ve belirli otonom ajan incelemeleri talep etmesini, insan veya otonom ajan tarafından verilen geri bildirimlere yanıt vermesini ve tüm otonom ajan inceleyiciler memnun kalana kadar bir döngü içinde yinelemesini söyleriz (bu, etkili bir şekilde bir Ralph Wiggum Döngüsü(yeni bir pencerede açılır)'dür). Codex, CLI'ye kopyala-yapıştır yapmaya gerek kalmadan bağlam toplamak için standart geliştirme araçlarımızı (gh, yerel betikler ve depoya gömülü beceriler) doğrudan kullanır.
İnsanlar pull request'leri inceleyebilir, ancak incelemek zorunda değiller. Zamanla, neredeyse tüm inceleme çabalarını otonom ajanlar arasında yürütülecek şekilde yönlendirdik.
Kod verimi arttıkça, darboğazımız insan kaynaklı kalite kontrol kapasitesi haline geldi. Sabit kısıt insan zamanı ve dikkati olduğundan, uygulama kullanıcı arayüzü, günlükler ve uygulama metrikleri gibi unsurları Codex tarafından doğrudan okunabilir hale getirerek otonom ajana daha fazla yetenek kazandırmak için çalıştık.
Örneğin, uygulamayı her git worktree için önyüklenebilir hale getirdik, böylece Codex her değişiklik için bir örnek başlatıp yönetebiliyor. Chrome DevTools Protocol'ü otonom ajan çalışma zamanına entegre ettik ve DOM anlık görüntüleri, ekran görüntüleri ve gezinme ile çalışmak için beceriler geliştirdik. Bu, Codex'in hataları yeniden üretmesini, düzeltmeleri doğrulamasını ve kullanıcı arayüzü davranışı hakkında doğrudan mantık yürütmesini sağladı.

Gözlemlenebilirlik araçları için de aynı işlemi gerçekleştirdik. Günlükler, metrikler ve izler, herhangi bir çalışma ağacı için geçici olan yerel bir gözlemlenebilirlik yığını aracılığıyla Codex'e sunulur. Codex, o uygulamanın tamamen yalıtılmış bir sürümü üzerinde çalışır; günlükleri ve metrikleri de dahil olmak üzere, görev tamamlandığında bunlar kaldırılır. Ajanlar, LogQL ile günlükleri sorgulayabilir ve PromQL ile metrikleri sorgulayabilir. Bu bağlam mevcut olduğunda, "hizmetin başlatılmasının 800 ms'nin altında tamamlanmasını sağlayın" veya "bu dört kritik kullanıcı yolculuğunun hiçbirindeki süre iki saniyeyi aşmasın" gibi komutlar uygulanabilir hale gelir.
Tek bir Codex çalıştırmasının tek bir görev üzerinde altı saatten fazla çalıştığını düzenli olarak gözlemliyoruz (çoğu zaman insanlar uyurken).
Bağlam yönetimi, ajanların büyük ve karmaşık görevlerde etkili olmasını sağlamanın en büyük zorluklarından biridir. Öğrendiğimiz en erken derslerden biri basitti: Codex'e 1.000 sayfalık bir talimat kılavuzu yerine bir harita vermek.
"Tek büyük AGENTS.md(yeni bir pencerede açılır)" yaklaşımını denedik. Öngörülebilir şekillerde başarısızlık gösterdi:
- Bağlam sınırlı bir kaynaktır. Devasa bir talimat dosyası görevi, kodu ve ilgili belgeleri gölgede bırakır. Bu yüzden otonom ajan ya önemli kısıtlamaları gözden kaçırır ya da yanlış kısıtlamalar için optimizasyon yapmaya başlar.
- Çok fazla rehberlik, rehberliksizlik haline gelir. Her şey "önemli" olduğunda, hiçbir şey önemli değildir. Ajanlar, kasıtlı bir şekilde gezinmek yerine yerel olarak örüntü eşleştirmeye başlar.
- Hemen çürür. Tek parça bir kılavuz, bayatlamış kuralların mezarlığına dönüşür. Ajanlar neyin hâlâ doğru olduğunu belirleyemez, insanlar onu güncel tutmayı bırakır ve dosya sessizce çekici bir sorun haline gelir.
- Doğrulaması zor. Tek bir blob, mekanik kontrollerin (kapsam, güncellik, sahiplik, çapraz bağlantılar) yapılmasına uygun değildir; bu nedenle sapma kaçınılmazdır.
Bu nedenle AGENTS.md'yi ansiklopedi olarak görmek yerine, onu içindekiler tablosu olarak görüyoruz.
Deponun bilgi tabanı, kayıt sistemi olarak kabul edilen yapılandırılmış bir docs/ dizininde yer alır. Kısa bir AGENTS.md (yaklaşık 100 satır) bağlama enjekte edilir ve öncelikle bir harita görevi görür, başka yerlerdeki daha derin bilgi kaynaklarına işaret eder.
Tasarım dokümantasyonu, doğrulama durumu ve otonom ajan öncelikli işletim ilkelerini tanımlayan bir dizi temel inanç dahil olmak üzere kataloglanıp dizinlenir. Mimari dokümantasyon(yeni bir pencerede açılır), alanlar ve paket katmanlaması için üst düzey bir harita sunar. Kalite belgesi, her ürün alanını ve mimari katmanı değerlendirir, zamanla boşlukları izler.
Planlar birinci sınıf eserler olarak ele alınır. Geçici hafif planlar küçük değişiklikler için kullanılırken, karmaşık işler ilerleme ve karar günlükleriyle birlikte depoya kaydedilen yürütme planlarında(yeni bir pencerede açılır) belgelenir. Etkin planlar, tamamlanmış planlar ve bilinen teknik borçlar sürümlendirilip aynı yerde toplanır, böylece ajanlar harici bağlama ihtiyaç duymadan çalışabilir.
Bu, aşamalı bilgi vermeyi mümkün kılar: ajanlar küçük, sabit bir giriş noktasıyla başlar ve başlangıçta bunalmadan, bir sonraki adımda nereye bakacakları öğretilir.
Bunu otomatik olarak uygularız. Özel linter'lar ve CI işleri, bilgi tabanının güncel olduğunu, çapraz bağlantılar içerdiğini ve doğru şekilde yapılandırıldığını doğrular. Yinelenen bir "doc-gardening" otonom ajan, gerçek kod davranışını yansıtmayan eski veya geçerliliğini yitirmiş dokümantasyonu tarar ve düzeltme amaçlı pull requestler açar.
Kod tabanı geliştikçe, Codex'in tasarım kararları çerçevesinin de gelişmesi gerekiyordu.
Depo tamamen otonom ajan tarafından oluşturulduğundan, öncelikle Codex'in okunabilirliği için optimize edilmiştir. Ekiplerin yeni mühendis işe alımlarında kodlarının gezilebilirliğini iyileştirmeyi hedeflemesine benzer şekilde, insan mühendislerimizin hedefi, bir otonom ajanın tüm iş alanı hakkında doğrudan depo üzerinden akıl yürütebilmesini mümkün kılmaktı.
Otonom ajana göre, çalışırken bağlam içinde erişemediği herhangi bir şey aslında mevcut değildir. Google Docs'ta, sohbet dizilerinde veya insanların zihninde bulunan bilgiler sisteme erişilebilir değildir. Depo yerelindeki sürümlenmiş yapıtlar (örneğin, kod, markdown, şemalar, çalıştırılabilir planlar) onun görebildiği her şeydir.

Zamanla depoya daha fazla bağlam eklememiz gerektiğini öğrendik. Ekibi mimari model konusunda aynı görüşte birleştiren Slack tartışması mı? Otonom ajan tarafından keşfedilemiyorsa, üç ay sonra katılan yeni bir çalışanın bilmeyeceği şekilde okunaksızdır.
Codex'e daha fazla bağlam sağlamak, ajanı geçici talimatlarla boğmak yerine, doğru bilgileri düzenleyip ortaya koyarak ajanın bu bilgiler üzerinde mantıklı kararlar almasını sağlamak anlamına gelir. Yeni bir ekip arkadaşını ürün ilkeleri, mühendislik normları ve ekip kültürü (emoji tercihleri dahil) konusunda oryantasyon yaparken olduğu gibi, otonom ajana bu bilgileri vermek daha uyumlu çıktılar elde edilmesini sağlar.
Bu çerçeve, birçok ödünleşimi netleştirdi. Depo içinde tamamen içselleştirilebilen ve üzerinde akıl yürütülebilen bağımlılıkları ve soyutlamaları tercih ettik. Genellikle "sıkıcı" olarak tanımlanan teknolojiler, birleştirilebilirlikleri, API kararlılıkları ve eğitim setinde temsil edilmeleri sayesinde ajanlar tarafından daha kolay modellenebilir. Bazı durumlarda, herkese açık kütüphanelerden gelen belirsiz üst akış davranışını aşmaya çalışmaktansa, otonom ajanın işlevselliğin alt kümelerini yeniden uygulaması daha ucuza geliyordu. Örneğin, genel bir p-limit tarzı paket kullanmak yerine, kendi eşzamanlılık yardımcı programımızı uyguladık: bu program, OpenTelemetry enstrümantasyonumuzla sıkı bir şekilde entegre edilmiştir, %100 test kapsamına sahiptir ve çalışma zamanımızın beklediği şekilde çalışır.
Sistemin daha büyük bir kısmını ajanın doğrudan inceleyebileceği, doğrulayabileceği ve değiştirebileceği bir forma çekmek, sadece Codex için değil, aynı kod tabanında çalışan diğer ajanlar (örneğin Aardvark) için de kaldıraç etkisini artırır.
Yalnızca dokümantasyon, tamamen otonom ajan tarafından üretilen bir kod tabanının tutarlılığını sağlamaz. Değişmezleri dayatıp uygulamaları mikro düzeyde yönetmeyerek, ajanların temeli zayıflatmadan hızlıca teslimat yapmalarını sağlıyoruz. Örneğin, Codex'in sınırda veri şekillerini ayrıştırmasını(yeni bir pencerede açılır) istiyoruz, ancak bunun nasıl yapılacağı konusunda bir kural koymuyoruz (model Zod'u seviyor gibi görünüyor, ancak o belirli kütüphaneyi belirtmedik).
Otonom ajanlar, katı sınırlar ve öngörülebilir yapıya sahip(yeni bir pencerede açılır) ortamlarda en etkili şekilde çalışır, bu yüzden uygulamayı katı bir mimari model üzerine inşa ettik. Her iş alanı, bağımlılık yönleri sıkı bir şekilde doğrulanan ve izin verilen kenarların sınırlı bir kümesine sahip sabit bir katman kümesine ayrılır. Bu kısıtlamalar, Codex tarafından üretilmiş özel lint araçları ve yapısal testler aracılığıyla mekanik olarak uygulanmaktadır.
Aşağıdaki şema kuralı göstermektedir: her bir iş alanı içinde (ör. Uygulama Ayarları), kod yalnızca sabit bir katmanlar dizisi (Türler → Yapılandırma → Depo → Hizmet → Çalışma Zamanı → Kullanıcı Arayüzü) aracılığıyla "ileriye doğru" bağımlı olabilir. Çapraz kesen konular (kimlik doğrulama, bağlayıcılar, telemetri, özellik bayrakları) tek bir açık arayüzden girer: Sağlayıcılar. Bunun dışındaki her şey yasaktır ve mekanik olarak uygulanır.

Bu, genellikle yüzlerce mühendise sahip olana kadar ertelediğiniz türden bir mimaridir. Kodlama ajanları için, bu erken bir ön koşuldur: kısıtlamalar, bozulma veya mimari sapma olmadan hızı mümkün kılar.
Pratikte, bu kuralları özel linter'lar ve yapısal testlerle, ayrıca küçük bir "zevk değişmezleri" kümesiyle uygularız. Örneğin, özel lint'lerle yapılandırılmış günlük kaydını, şema ve türler için adlandırma kurallarını, dosya boyutu sınırlarını ve platforma özgü güvenilirlik gereksinimlerini statik olarak zorunlu kılıyoruz. Lint'ler özel olduğundan, düzeltme talimatlarını otonom ajan bağlamına yerleştirmek için hata mesajlarını yazarız.
İnsan öncelikli bir iş akışında, bu kurallar gereksiz yere titiz veya kısıtlayıcı gelebilir. Ajanlarla, çarpan etkisi yaratırlar: bir kez kodlandıklarında, her yerde aynı anda uygularlar.
Aynı zamanda, kısıtlamaların hangi durumlarda önemli olduğunu ve hangi durumlarda olmadığını açıkça ifade ediyoruz. Bu, büyük bir mühendislik platformu organizasyonunu yönetmeye benzer: sınırları merkezi olarak uygulayın, yerelde otonomiye izin verin. Sınırlar, doğruluk ve yeniden üretilebilirlik konularına büyük önem veriyorsunuz. Bu sınırlar içinde, ekiplerin veya ajanların çözümleri nasıl ifade edecekleri konusunda önemli ölçüde özgürlüğe sahip olmalarına izin verirsiniz.
Ortaya çıkan kod her zaman insan stil tercihleriyle örtüşmeyebilir ve bu sorun teşkil etmez. Çıktı doğru, sürdürülebilir ve gelecekteki otonom ajan çalıştırmalarında okunabilir olduğu sürece, gereken standardı karşılar.
İnsan zevki sisteme sürekli olarak geri beslenir. İnceleme yorumları, refactoring pull request'leri ve kullanıcıya dönük hatalar, dokümantasyon güncellemeleri olarak kaydedilir veya doğrudan araçlara entegre edilir. Dokümantasyon yetersiz kaldığında, kuralı koda terfi ettiririz
Codex’in işlem kapasitesi arttıkça, birçok geleneksel mühendislik normu verimsiz hale geldi.
Depo, minimum engelleme ile çalışan birleştirme geçitlerine sahiptir. Pull requestler kısa ömürlüdür. Test hataları, ilerlemeyi süresiz olarak engellemek yerine genellikle takip çalışmalarıyla ele alınır. Ajan verimliliğinin insan dikkatini çok aştığı bir sistemde, düzeltmeler ucuzdur ve beklemek pahalıdır.
Bu, düşük işlem kapasiteli bir ortamda sorumsuzca bir davranış olurdu. Burada, çoğu zaman doğru tercih budur.
Kod tabanının Codex ajanları tarafından oluşturulduğunu söylediğimizde, kod tabanındaki her şeyi kastediyoruz.
Otonom ajanlar şunları üretir:
- Ürün kodu ve testler
- CI yapılandırması ve sürüm araçları.
- Dahili geliştirici araçları
- Dokümantasyon ve tasarım tarihi
- Değerlendirme donanımları
- İnceleme yorumları ve yanıtlar
- Depoyu kendisi yöneten betikler
- Üretim gösterge paneli tanım dosyaları
İnsanlar her zaman sürece dâhil olur, ancak artık farklı bir soyutlama katmanında çalışırlar. İşleri önceliklendirir, kullanıcı geri bildirimlerini kabul kriterlerine dönüştürür ve sonuçları doğrularız. Otonom ajan zorlandığında, bunu bir sinyal olarak değerlendiririz: eksik olanı (araçlar, koruyucu önlemler, belgeler) belirler ve her zaman Codex'in düzeltmeyi kendisinin yazmasını sağlayarak bunu depoya geri bildiririz.
Otonom ajanlar standart geliştirme araçlarımızı doğrudan kullanır. İnceleme geri bildirimlerini alır, satır içi yanıt verir, güncellemeleri gönderir ve genellikle kendi pull request'lerini birleştirip sıkıştırırlar.
Geliştirme döngüsünün daha büyük bir kısmı doğrudan sisteme kodlandıkça (test, doğrulama, inceleme, geri bildirim yönetimi ve kurtarma), depo kısa süre önce Codex'in yeni bir özelliği uçtan uca yönlendirebileceği anlamlı bir eşiği aştı.
Tek bir komut verildiğinde, otonom ajan artık şunları yapabilir:
- Kod tabanının mevcut durumunu kontrol etme
- Bildirilen bir hatayı yeniden oluşturma
- Arızayı gösteren bir video kaydetme
- Bir düzeltme yapma
- Uygulamayı çalıştırarak düzeltmeyi doğrulama
- Çözümü gösteren ikinci bir video kaydetme
- Bir pull request açma
- Otonom ajan ve insan geri bildirimlerine yanıt verme
- Derleme hatalarını tespit edip düzeltme
- Yalnızca muhakeme gerektiğinde bir insana yönlendirme
- Değişikliği birleştirme
Bu davranış, bu deponun özel yapısına ve araçlarına büyük ölçüde bağlıdır ve benzer bir yatırım yapılmadan genelleştirilebileceği varsayılmamalıdır — en azından şimdilik.
Tam otonom ajanlar, yeni sorunlar da ortaya çıkarır. Codex, depoda zaten var olan kalıpları, düzensiz veya optimal olmayanları bile tekrarlar. Zamanla bu kaçınılmaz olarak sapmaya neden olur.
Başlangıçta, insanlar bunu elle çözdü. Ekibimiz eskiden her Cumayı (haftanın %20’si) "AI slop"u temizlemekle geçirirdi. Tahmin edilebileceği gibi, bu durum ölçeklenebilir olmadı.
Bunun yerine, "altın ilkeler" olarak adlandırdığımız prensipleri doğrudan depoya kodlamaya başladık ve düzenli bir temizlik süreci oluşturduk. Bu ilkeler, kod tabanını gelecekteki otonom ajan çalıştırmaları için okunabilir ve tutarlı tutan, belirli bir görüşe dayanan mekanik kurallardır. Örneğin: (1) değişmezleri merkezileştirmek için özel yazılmış yardımcılar yerine ortak yardımcı program paketlerini tercih ederiz ve (2) verileri "YOLO tarzında" gelişigüzel test etmeyiz; bunun yerine sınır doğrulaması yapar veya tip tanımlı SDK'lara güveniriz; böylece otonom ajan, tahmine dayalı veri yapıları üzerine yanlışlıkla işlem inşa edemez. Düzenli aralıklarla, sapmaları tarayan, kalite derecelerini güncelleyen ve hedefe yönelik yeniden düzenleme pull request'leri açan bir dizi arka plan Codex görevimiz var. Bunların çoğu bir dakikadan kısa sürede gözden geçirilebilir ve otomatik birleştirilebilir.
Bu, çöp toplama sistemi gibi çalışır. Teknik borç, yüksek faizli bir kredi gibidir: Birikmesine izin verip acı verici ataklarla ele almaktansa, onu sürekli ve küçük artışlarla azaltmak neredeyse her zaman daha iyidir. İnsan zevki bir kez yakalanır ve ardından her bir kod satırında sürekli olarak uygulanır. Bu, kötü örüntülerin kod tabanında günlerce veya haftalarca yayılmasına izin vermek yerine, günlük olarak yakalanıp çözülmesini sağlar.
Bu strateji, şimdiye kadar OpenAI'da iç lansman ve benimsenme sürecine kadar iyi çalıştı. Gerçek kullanıcılar için gerçek bir ürün geliştirmek, yatırımlarımızı gerçekliğe dayandırmamıza ve uzun vadeli sürdürülebilirliğe yönlendirmemize yardımcı oldu.
Henüz bilmediğimiz ise, tamamen otonom ajan tarafından üretilen bir sistemde mimari tutarlılığın yıllar içinde nasıl geliştiğidir. İnsan muhakemesinin en fazla etkiyi nerede sağladığını ve bu muhakemeyi birleştirici bir etki yaratacak şekilde nasıl kodlayacağımızı hâlâ öğreniyoruz. Ayrıca, modeller zamanla daha yetenekli hale geldikçe bu sistemin nasıl gelişeceğini de bilmiyoruz.
Açıkça görünen şu: yazılım geliştirmek hâlâ disiplin gerektiriyor, ancak bu disiplin daha çok kodun etrafındaki yapılandırmada kendini gösteriyor. Kod tabanının tutarlılığını sağlayan araçlar, soyutlamalar ve geri bildirim döngüleri giderek daha önemli hale geliyor.
Şu anda en zorlu sorunlarımız, ajanların hedefimize ulaşmasına yardımcı olacak ortamlar, geri bildirim döngüleri ve kontrol sistemleri tasarlamaya odaklanıyor: geniş ölçekte karmaşık ve güvenilir yazılımlar geliştirmek ve sürdürmek.
Codex gibi operatörler yazılım yaşam döngüsünün daha büyük bölümlerini üstlendikçe, bu sorular daha da önemli hale gelecek. Bazı erken dersleri paylaşmanın, çabanızı nereye yatırmanız gerektiğini değerlendirmenize yardımcı olmasını umuyoruz; böylece sadece bir şeyler geliştirebilirsiniz.


