1~
2Bir kodlama temsilcisi sizin için ilk kez bir hatayı düzelttiğinde, tepki neredeyse her zaman aynıdır: coşku ve şüphe karışımı. Elbette güzel. Ama sonra farka bakıp kendinize şunu soruyorsunuz: "Tamam ama tam olarak neye dokundu? Ona güvenebilir miyim? Yarın da aynı şekilde yapacak mı?".
3~
4İlginç kısmın burada başladığını düşünüyorum. Aracı bir işlev yazdığında değil, işin tamamını üstlenebilecek kapasiteye ulaştığında: veri deposunu okuyun, bir yama oluşturun, testler çalıştırın, bir PR açın, bir inceleme yorumundan sonra geri gelin. Codex tam olarak bu yönde ilerliyor: arka plan çalışması, ayrı çalışma ağaçları, entegre tarayıcı, otomasyonlar, eklentiler, bellek ve daha açık izin kontrolleri.
5~
6Önemli olan artık kimsenin kod okumadığı bir gelecek hayal etmek değil. Korkunç bir gelecek olurdu, aynı zamanda oldukça naif. Önemli olan, her şeyi yapmalarına izin vermeden çok şey yapabilen temsilcilerle nasıl çalışılacağını bulmaktır.
7~
8## Alışkanlık değişikliği
9~
10Geleneksel otomatik tamamlama ile her zaman direksiyon başındaydınız. Yapay zeka bir çizgi önerdi, siz karar verdiniz. Ancak bir temsilciyle ilişki değişir: Ona bir hedef verirsiniz ve o da kendi başına birçok adım atar.
11~
12Bu güçlüdür ancak sorunu değiştirir. Soru artık sadece "model programlayabilir mi?" değil. Soru şöyle oluyor:
13~
14- Ona yeterince küçük bir dürbün verdim mi?
15- sonucu nasıl kontrol edeceğinizi biliyor musunuz?
16- İzole bir ortamda mı çalışıyorum?
17- Son inceleme hâlâ insani ve dikkatli mi?
18~
19Sağlıklı bir iş akışı, sihirli bir değnekten çok şuna benzer:
20~
21```mermaid
22flowchart LR
23    Idea[İnsan görevi] --> Scope[Küçük, doğrulanabilir amaç]
24    Scope --> Agent[Çalışma ağacındaki ajan izole edildi]
25    Agent --> Checks[Test, tüy bırakma, derleme, tarayıcı]
26    Checks --> Review[İnsan incelemesi]
27    Review --> Merge[Birleştirme veya yeni yineleme]
28    Review --> Iterate[Fark hakkında kesin yorumlar]
29    Iterate --> Agent
30```
31~
32"Acente her şeyi yapar" ifadesinden daha az romantik geliyor ama çok daha iyi çalışıyor. İnsanlarla arası iyi olan ekipler de bu şekilde çalışır: net görevler, hızlı geri bildirim, açık sorumluluk.
33~
34## İyi istem neredeyse iyi bir bilettir
35~
36En tehlikeli istem belirsiz ama kendinden emin olanıdır: "fatura sayfasını düzeltin", "mimariyi geliştirin", "kimlik doğrulama modülünü temizleyin". Bunlar kulağa üretken gelen ve büyük farklar yaratan isteklerdir. Ama sonra kendinizi arkeoloji yaparken buluyorsunuz.
37~
38Yararlı bir bilgi istemi daha sıkıcıdır. Örneğin: tablonun `app/(dashboard)/invoices/page.tsx`'da olduğunu, sorguların `src/server/invoices.ts`'de olduğunu ve `app/(dashboard)/reports`'de zaten benzer bir model olduğunu bilerek faturalar sayfası için CSV dışa aktarımını uygulayın.
39~
40Ardından net kısıtlamalar ekleyin: veritabanı şemasını değiştirmeyin, küçük bir yardımcı program yeterliyse bağımlılıklar eklemeyin, mevcut kullanıcı arayüzü stilini koruyun. Ve doğrulamayı şu şekilde sonlandırın: `npm test -- invoices` ve `npm run build`.
41~
42Bu tür brifinglerin amacı "Yapay zekaya daha iyi açıklama yapmak" değildir. Her şeyden önce neyi devrettiğinizi size daha açık hale getirmeye hizmet eder. Eğer bunu somut olarak yazamıyorsanız, belki de görev henüz bir temsilci için hazır değildir.
43~
44## İsteyerek devrettiğim üç iş
45~
46Birincisi tekrarlanan ancak doğrulanabilir bir çalışmadır: testler eklemek, çağrıları yeni bir dahili API'ye taşımak, içe aktarmaları güncellemek, kullanım dışı bileşenleri değiştirmek, TypeScript hatalarını düzeltmek. Burada acente saatlerce tasarruf edebilir ve risk kontrol edilebilir.
47~
48İkincisi keşif çalışmasıdır: "bu toplamın nerede hesaplandığını bulun", "bu testin neden hassas olduğunu bana açıklayın", "hatayı yeniden üretin ve bana hangi dosyaların etkilenmiş göründüğünü söyleyin". Hemen bir yama üretmese bile yararlı keşifler yapabilir.
49~
50Üçüncüsü ise yinelenen bakım çalışmalarıdır: küçük bağımlılık güncellemeleri, eski özellik işaretlerinin temizlenmesi, engellenen PR'lerin özeti, unutulan TODO'ların kontrol edilmesi. Gösterişli değil ama tam da birikme eğiliminde olan türden bir iş.
51~
52## İnsan olarak tuttuğum üç iş
53~
54Ürün kararları insani kalır. Bir değişiklik kullanıcının ödeme yapma, verileri silme, fiyatları görme veya bir izni anlama şeklini değiştirirse sorumlu bir kişi istiyorum.
55~
56Güvenlik sınırları aynı zamanda insanların ilgisini de hak ediyor: kimlik doğrulama, roller, belirteçler, hassas veri kaydı, veritabanı geçişleri. Bir temsilci uygulamaya yardımcı olabilir ancak tek karar verici olması gerekmez.
57~
58Son olarak mimari zevk gerektiren her şeyi insani tutuyorum. Bir etmen bir yeniden düzenleme önerebilir, ancak bir soyutlamanın gerçekten gerekli olup olmadığını veya sadece var olmayan bir sorunu düzeltip düzeltmediğimizi anlamak bir iş olarak kalır.
59~
60## İnceleme isteğe bağlı değildir
61~
62Bir temsilci iyi olduğunda, cazibesi CI'nın yeşiline güvenmektir. Bu anlaşılabilir bir durum. Aynı zamanda sorunların da başladığı zamandır.
63~
64Her zaman en az beş şeye bakarım:
65~
661. Yama yalnızca istenen görevi çözüyor mu?
672. Hiçbir ilgisi olmayan dosyalara dokundu mu?
683. Testler yeni davranışları mı yoksa sadece mutlu şansı mı kapsıyor?
694. Kod yerel kalıpları takip ediyor mu?
705. Hatalar projenin geri kalanında olduğu gibi ele alınıyor mu?
71~
72Bir şeyler yanlış olduğunda geri bildirimin spesifik olması gerekir. "Düzelt" tembelliktir. Daha iyisi: bu yardımcı program `parseMoney` dosyasını `src/lib/money.ts` dosyasına kopyalar; bu işlevi yeniden kullanın, EUR durumu için bir test ekleyin ve faturalandırma modülünün genel API'sini değiştirmeyin.
73~
74Temsilciler küçük, doğrulanabilir yorumlara çok daha iyi yanıt verir. İlginç bir şekilde insanlar da öyle.
75~
76## Çabaya değer korkuluklar
77~
78Bir aracı dosyaları okuyabiliyor, kod yazabiliyor ve komutları yürütebiliyorsa, bunun güçlü bir süreç olarak ele alınması gerekir. Paranoyaya gerek yok, hijyene ihtiyacınız var.
79~
80Ayrı çalışma ağaçları veya dalları kullanın. Böylece farkı karşılaştırabilir, başarısız deneyleri bir kenara atabilir ve aracının işini sizin yaptığınız işle karıştırmazsınız.
81~
82İzinleri sınırlayın. `rg`, `git diff`, `npm test` ve `npm run build` gibi komutlar oldukça ücretsiz olabilir. Dağıtımlar, veritabanı geçişleri, sırlara erişim ve yıkıcı komutlar açık kalmalıdır.
83~
84İhtiyacınız olmadığında ağ erişimini azaltın. Birçok görev için resmi belgeler, paket kaydı ve belirli dahili hizmetler yeterlidir. Daha az yüzey alanı, daha az sürpriz.
85~
86Eylemleri izleyin. Bir yama incelemeye alındığında, istemleri, yürütülen komutları, geçilen testleri ve değiştirilen dosyaları yeniden oluşturabilmelisiniz. Bürokrasi yaratmak değil, bir şeyler ters giderse ne olduğunu anlayabilmek.
87~
88## Ekip olarak başlamanın kolay bir yolu
89~
90Eğer ajanları küçük bir ekibe katacak olsaydım, büyük devrimler olmadan başlardım.
91~
92Kapsamı net olan sorunlar için bir `agent-ready` etiketi oluştururdum. Bağlam, kısıtlamalar ve doğrulama komutlarını içeren bir şablon eklerdim. İdeal olarak birkaç yüz satırın altında küçük bir PR isterim. Görünür değişiklikler için testlere veya ekran görüntülerine ihtiyacım var. Ve her şeyden önce birleşmeden bir kişiyi sorumlu tutardım.
93~
94İki hafta sonra verilere bakardım: Hangi görevler gerçekten hızlandırıldı, hangi incelemeler ağırdı, hangi istemler kafa karıştırıcıydı, kod tabanının hangi bölümleri devredilemeyecek kadar kırılgandı.
95~
96"Bugünden itibaren her şeyi menajerlerle yapacağız" yaklaşımından daha az gösterişli bir yaklaşım ama pişmanlık duymadan üçüncü haftaya geçmenizi sağlayan yaklaşım.
97~
98## En insani kısmı
99~
100İşin komik yanı, temsilciler ne kadar özerk olursa, klasik beceriler de o kadar önemli hale geliyor: iyi bir bilet yazmak, küçük kesintiler yapmak, testler oluşturmak, farkları okumak, takasları iletmek. Temsilci, nasıl iyi çalışacağını zaten bilenleri hızlandırır. Aynı zamanda kötü yetki verenlerin kaosunu da artırıyor.
101~
102Yani hayır, çok aracılı iş akışlarını mühendislik yapmayı bırakmanın kısayolu olarak görmüyorum. Bunları, önemli parçalara daha fazla enerji aktarmanın bir yolu olarak görüyorum: Ne inşa edileceğine karar vermek, çalıştığından emin olmak, sistemi anlaşılır tutmak.
103~
104Temsilciler harika asenkron iş arkadaşları yaratabilirler. Ancak asenkron bir meslektaşın faydalı olabilmesi için bağlama, sınırlara ve incelemeye ihtiyacı vardır. Tıpkı diğer herkes gibi.
105~
106## Yararlı kaynaklar
107~
108- [(Neredeyse) her şey için kodeks - OpenAI](https://openai.com/index/codex-for-almost-everything/)
109- [Codex'i OpenAI'de güvenle çalıştırma](https://openai.com/index/running-codex-safely/)
110- [Codex'e Giriş - OpenAI](https://openai.com/index/introducing-codex/)
111- [GitHub Copilot kodlama aracısındaki yenilikler](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)
112~