Lovable, Cursor, Claude ve Codex aynı geliştirme sürecinde nasıl konumlanıyor?

AI coding araçlarını karşılaştıran içeriklerin çoğu tek bir soruya odaklanıyor: hangisi daha iyi? Benim gerçek çalışma hayatımda bu soru giderek daha az işe yarıyor. Çünkü Lovable, Cursor, Claude ve Codex'i aynı anda kullanırken asıl problem bir kazanan seçmek değil; hangi işi kime vereceğimi belirlemek.

Aynı görevi dört araca birden verirseniz dört farklı mimari, dört farklı yorum ve dört farklı ‘tamamlandı’ tanımı elde edebilirsiniz. Bu hız değil. Koordinasyon borcu.

AI tool stack'in değeri araç sayısından değil, araçların birbirine basmadığı görev sınırlarından geliyor.

Önce bir yanlışı düzelteyim: bunlar sabit roller değil

Araçlar çok hızlı değişiyor. Bugün bir modelin zayıf olduğu alan birkaç hafta sonra güçlenebilir. Dolayısıyla aşağıdaki dağılım ‘Claude bunu yapamaz’, ‘Codex sadece şunu yapar’ gibi kalıcı bir ürün karşılaştırması değil. Benim mevcut çalışma sistemimde sürtünmeyi azaltan rol dağılımı.

1const principle = {2  chooseBy: "task shape",3  notBy: "favorite tool",4};

Benim zihinsel modelim: fikirden production'a dört farklı iş tipi

Bir ürün özelliği genellikle tek bir ‘kodlama işi’ değil. Keşif, tasarım, implementation, review ve acceptance gibi farklı bilişsel işleri var. Araçları bu iş tiplerine göre ayırdığınızda rekabet etmeyi bırakıp pipeline'ın parçalarına dönüşüyorlar.

1type WorkMode =2  | "explore"3  | "shape"4  | "implement"5  | "audit"6  | "verify";

Lovable: fikri görünür hale getirme ve UI üzerinde hızlı iterasyon

Lovable'ı en çok bir fikri konuşmaktan çıkarıp ekranda tartışılabilir hale getirmek istediğimde değerli buluyorum. Landing page, yeni bir ürün kabuğu, component düzeni veya görsel yön gibi konularda hızlı geri bildirim döngüsü sağlıyor.

Bu benim için önemli çünkü bazı ürün kararları kod veya metin üzerinden tartışılamıyor. Ekranı görmek gerekiyor. Hiyerarşi yanlış mı? Çok fazla kart mı var? CTA kayboluyor mu? Mobilde yapı anlamsızlaşıyor mu? Görsel çıktıyı erken görmek ürün kararını hızlandırıyor.

1const lovable = {2  strongestUseForMe: [3    "rapid UI exploration",4    "landing pages",5    "layout iteration",6    "visual product shaping",7  ],8  danger: "letting a fast prototype silently become architecture",9};

Tehlike de aynı yerde: hızlı oluşturulan çözümü sırf çalışıyor diye canonical architecture kabul etmek. Ben Lovable çıktısını gerektiğinde production koduna bağlarım, ama önce ürün ve repository gerçekliğiyle uyumunu kontrol ederim.

Cursor: repository içindeki günlük uygulama döngüsü

Cursor benim için özellikle mevcut repository bağlamında dosyalar arasında çalışırken doğal bir uygulama yüzeyi. Küçük ve orta kapsamlı değişiklik, ilgili dosyaları keşfetme, mevcut pattern'i izleme ve hızlı düzenleme döngülerinde kullanışlı.

Ama repo-aware olmak otomatik olarak product-aware olmak anlamına gelmiyor. Agent kodu görebilir; neden o kodun öyle olması gerektiğini bilmiyor olabilir. Bu yüzden prompt'ta yalnızca görev değil korunacak kararları da açık tutuyorum.

1const cursorTask = {2  goal: "fix the current behavior",3  preserve: ["existing design", "data contracts", "route semantics"],4  avoid: ["new dependency", "parallel architecture", "unrequested redesign"],5};

Claude: problemi yeniden çerçeveleme ve zor debugging

Claude'u özellikle problem birkaç başarısız denemeden sonra bulanıklaştığında, mevcut çözümü sorgulatmak veya farklı bir kök neden analizi almak istediğimde değerli buluyorum. Aynı bug'ı üçüncü kez patch'lemek yerine bazen ‘neden bu sistem sürekli buradan kırılıyor?’ diye daha geniş bakmak gerekiyor.

Bu rol implementasyon yapamayacağı anlamına gelmiyor. Yapabilir. Ama benim sistemimde güçlü olduğu noktayı yalnızca kod miktarıyla ölçmüyorum; problemi yeni bir modelle açıklayabilmesi de değer.

1const claudePrompt = `Do not patch yet.2Inspect the current behavior and previous fixes.3Explain the most likely root cause.4Show which assumption in the current architecture is wrong.5Then propose the smallest durable fix.`;

Codex: engineering görevleri, audit ve kontrollü uygulama

Codex'i repository üzerinde daha mühendislik ağırlıklı görevlerde, kapsamı net uygulamalarda, audit'lerde ve değişiklik sonrası doğrulama işlerinde kullanmayı seviyorum. Özellikle görevi preflight, implementation ve acceptance şeklinde bölmek burada iyi çalışıyor.

Benim için değerli taraflardan biri çıktıyı ‘kod yazıldı’ seviyesinde bırakmayıp hangi doğrulamaların gerçekten yapılabildiğini ayırmak. Typecheck geçti mi? Build geçti mi? Browser doğrulandı mı? Production görüldü mü? Gerçek cihaz var mı?

1const codexFlow = [2  "verify repo and branch",3  "inspect existing architecture",4  "make scoped change",5  "run available checks",6  "report unverified layers explicitly",7];

Asıl sistem: hepsinin üzerinde GitHub

Bu dört araç arasında en önemli ‘araç’ aslında bir AI ürünü değil: GitHub. Çünkü farklı agent'lar farklı worktree, local state veya preview üretebiliyor. Kaynak doğrusu olmazsa kimin yaptığı değişikliğin gerçek olduğunu takip etmek zorlaşıyor.

Agent değişebilir. Kaynak doğrusu değişmemeli.

1const sourceOfTruth = {2  repository: "GitHub",3  canonicalBranch: "explicit",4  production: "deployed commit",5};

Neden aynı görevi paralel dört agent'a vermiyorum?

Paralel agent kullanımı bazı araştırma ve alternatif çözüm görevlerinde yararlı olabilir. Fakat implementation'da dört agent'ın aynı kod tabanına farklı yönlerden saldırması merge yükü ve mimari tutarsızlık üretebilir.

Ben paralelliği daha çok bağımsız bilişsel görevlerde kullanmayı mantıklı buluyorum: biri architecture audit yapar, biri mevcut diff'i review eder, biri UI alternatifini araştırır. Ama tek feature'ın canonical implementation'ı için tek bir sorumlu akış tutmak daha temiz.

Bir agent'ın çıktısını diğerine nasıl veriyorum?

En kötü yöntem ikinci agent'a ‘Claude bunu yaptı, kontrol et’ demek. Çünkü bu ifade ilk çözümü anchor haline getiriyor. İkinci agent da farkında olmadan aynı varsayımları kabul edebilir.

Daha iyi yöntem requirements ve diff'i bağımsız biçimde verip önce uyuşmazlık bulmasını istemek.

1Do not assume the previous implementation is correct.2
3Compare:41. the requested behavior52. the current code63. the actual diff7
8Report mismatches before proposing changes.

Tool switching'in gizli maliyeti

Bir problemi çözerken her 15 dakikada bir başka AI aracına geçmek iyi bir ensemble sistemi değil. Çoğu zaman sabırsızlık. Her araçta context'i tekrar kuruyorsunuz, repository state'i yeniden anlatıyorsunuz ve farklı cevap stiline adapte oluyorsunuz.

Bu nedenle araç değişimini ‘cevabı beğenmedim’ refleksiyle değil, iş tipi gerçekten değiştiğinde yapmaya çalışıyorum.

1function switchTool(currentTask: Task) {2  return currentTask.modeChanged || currentTool.cannotAccessRequiredContext;3}

Örnek: bir mobil modal bug'ı

Diyelim Android'de klavye açılınca ekleme modalı eziliyor. Lovable'a ‘daha güzel modal yap’ demek problemi kaçırabilir. Cursor'a dosya seviyesinde birkaç CSS değişikliği yaptırmak semptomu azaltabilir. Claude'a birkaç başarısız fix sonrasında viewport/keyboard modelini analiz ettirmek kök nedeni açabilir. Codex'e de doğrulanmış kök neden üzerinden repository genelinde aynı modal pattern'lerini audit ettirmek mantıklı olabilir.

Burada araçların sırası sabit değil. Önemli olan problemin aşaması değiştikçe kullanılan iş modunun değişmesi.

1const bugLifecycle = [2  "reproduce",3  "find shared cause",4  "fix canonical primitive",5  "audit affected surfaces",6  "verify on real device",7];

Örnek: sıfırdan landing page

Yeni bir kişisel site veya ürün landing'i gibi görevde ise başlangıç ağırlığı değişebilir. Önce Lovable ile görsel direction ve bilgi hiyerarşisini hızlıca test etmek, sonra canonical GitHub repository üzerinden detayları sıkılaştırmak daha mantıklı olabilir.

Burada kritik nokta preview ile production repository arasında görünmez bir ayrışma yaratmamak. Tasarım kararı kabul edildiğinde canonical kodun nerede yaşadığı net olmalı.

Her araç için aynı preflight

Araç değişse bile bazı kurallar değişmiyor. Özellikle repository üzerinde yazma yetkisi olan agent için ilk sorular hep aynı.

1pwd2git remote -v3git branch --show-current4git status5git log -1 --oneline

Bu kontroller model zekâsıyla ilgili değil. Operasyon güvenliğiyle ilgili.

Her araç için aynı completion standardı da olmamalı

Lovable'da görsel prototip için başarı kriteri ‘direction doğru mu?’ olabilir. Repository fix'inde typecheck ve build gerekir. Mobil bug'da gerçek cihaz acceptance gerekebilir. Tool değil, task completion standardını belirler.

1function requiredVerification(task: Task) {2  if (task.kind === "visual-exploration") return ["human-review"];3  if (task.kind === "web-fix") return ["typecheck", "build", "browser"];4  if (task.kind === "native-bug") return ["build", "real-device"];5}

Benim mevcut görev dağılımım

Bu tablo ürün güncellemeleriyle değişebilir. Değişmemesi gereken şey ise görev rolünü önce tanımlamak.

En önemli ders: AI stack değil, çalışma protokolü kuruyorum

Bir dönem doğru kombinasyonu bulursam sürecin kendiliğinden hızlanacağını düşünmek kolaydı. Aslında araç kombinasyonu ikincil. Repo doğrulama, net scope, küçük diff, bağımsız review ve acceptance yoksa dört güçlü araç yalnızca daha hızlı karmaşıklık üretir.

En iyi AI coding stack, hangi agent'ın ne zaman durması gerektiğini de tanımlar.

Sonuç

Lovable, Cursor, Claude ve Codex benim için birbirini tamamen ikame eden dört ürün değil. Aynı geliştirme sisteminde farklı bilişsel yükleri taşıyabilen araçlar. Bazen roller çakışıyor, bazen biri diğerinin işini daha iyi yapıyor. Bu normal.

Benim sabit tuttuğum şey araç seçimi değil: ürün kararı insanda, kodun kaynak doğrusu GitHub'da, her görev sınırlandırılmış ve ‘done’ kelimesi doğrulama seviyesiyle birlikte söyleniyor.

1const aiWorkflow = {2  productAuthority: "human",3  codeTruth: "GitHub",4  toolChoice: "task-dependent",5  implementation: "scoped",6  review: "independent-when-needed",7  done: "verified-not-declared",8};