PlanAI: Yapay zekâ ile ev planı çizmek neden zor

Ender Çene·28 Ekim 2026·10 dk okuma

Bir süredir üzerinde çalıştığım bir ürün var: PlanAI. Kısaca anlatmak gerekirse, yapay zekâ yardımıyla ev planı ve mimari çizim üreten bir araç. Kâğıt üzerinde basit görünen bir fikir: kullanıcı ne istediğini söylesin, sistem de ona uygun bir plan çizsin. Bu yazıda o basit görünen fikrin içinden çıkan zorlukları, yaptığım hataları ve bu hatalardan sonra ürünün nasıl şekil değiştirdiğini anlatmak istiyorum. Çünkü bu süreçte öğrendiklerim yalnızca mimari yazılımlarla sınırlı değil; yapay zekâ ile ürün geliştiren herkesin bir noktada çarpacağı duvarlarla ilgili.

SEO tarafında yıllardır çalışan biri olarak "çalışıyor" ile "iyi" arasındaki farkı içerik ve site performansı üzerinden çok iyi bilirim. Bir sayfanın yayında olması, sıralama alması anlamına gelmez. PlanAI'de de aynı ayrımla bambaşka bir alanda yüz yüze geldim. Bir planın ekranda görünmesi, o planın yaşanabilir bir ev olduğu anlamına gelmiyor.

İlk yaklaşım: dil modeline koordinat yazdırmak

İşe başladığımda aklımdaki yol en kestirme olanıydı. Elimde güçlü dil modelleri vardı; metni anlıyor, yapılandırılmış çıktı üretebiliyor, hatta kod yazabiliyorlardı. O hâlde neden doğrudan oda koordinatı üretmesinler? Kullanıcının isteğini modele veriyor, karşılığında her odanın konumunu ve boyutunu sayısal olarak alıyordum. Sonra bu koordinatları çizime dönüştürüyordum.

İlk denemeler heyecan vericiydi, çünkü ekranda bir şey belirdi. Odalar vardı, isimleri vardı, bir sınırın içine yerleşmişlerdi. Ama biraz dikkatli bakınca sorunlar hemen ortaya çıktı. Odalar kutu gibi üst üste diziliyordu. Bir yatak odasına ulaşmak için salondan, mutfaktan ve banyodan geçmek gerekiyordu. Sirkülasyon, yani evin içinde insanların nasıl dolaşacağı, hiç düşünülmemiş gibiydi. Oranlar bozuktu: bazı odalar koridor kadar ince, bazıları gereksiz yere kare ve büyüktü.

Bir süre bunun komut yazımıyla çözülebileceğini düşündüm. Daha ayrıntılı talimatlar verdim, örnekler ekledim, kuralları tek tek yazdım. Sonuç biraz iyileşti ama temel sorun yerinde duruyordu. Zamanla şunu kabul etmem gerekti: dil modelleri iki boyutlu mekânsal akıl yürütmede zayıf. Bir metni sıralı biçimde üretmek ile bir düzlemde birbirine dokunan, birbirini etkileyen alanları aynı anda dengelemek çok farklı işler. Model bir odayı yerleştirirken diğer odaların bu karardan nasıl etkileneceğini gerçek anlamda "görmüyor". Sayıları üretiyor ama o sayıların oluşturduğu mekânı tartamıyor.

Mimariyi değiştirmek: program yapay zekâda, geometri motorda

Bu farkındalık ürünün mimarisini kökten değiştirdi. Yapay zekâya her şeyi yaptırmaya çalışmak yerine, onu gerçekten iyi olduğu işe odakladım. Dil modelleri insan dilini anlamakta ve bir isteği yapılandırılmış bir ihtiyaç listesine çevirmekte gerçekten başarılı. Bu yüzden yapay zekâ artık yalnızca programı çıkarıyor: hangi odalar olacak, her birinin alanı ne kadar olmalı, hangi odalar birbirine komşu olmalı, hangi oda hangi cepheye bakmak istiyor.

Geometriyi ise deterministik bir motor kuruyor. Deterministik derken şunu kastediyorum: aynı girdiyle her seferinde aynı mantıkla çalışan, kararlarının izini sürebildiğim, kurallara dayalı bir sistem. Bu motor işi birkaç adımda yapıyor:

Bölgeleme: Önce arsa ya da yapı alanı, gündüz kullanımı, gece kullanımı ve servis alanları gibi büyük bölgelere ayrılıyor.
Zon bölme: Bu bölgeler, içine odaların yerleşeceği daha küçük parçalara bölünüyor.
Kısıt çözücü ile oda yerleşimi: Odalar, alan, komşuluk ve cephe tercihleri gibi kısıtlar gözetilerek bir çözücü aracılığıyla yerleştiriliyor.
Yapı elemanları: Son aşamada duvarlar, kapılar, pencereler, akslar ve ölçüler oluşturuluyor.

Bu ayrım bana önemli bir şey öğretti. Yapay zekâyı bir ürünün içine koyarken en sık yapılan hata, ona her işi tek başına yaptırmaya çalışmak. Oysa iyi sonuç çoğu zaman yapay zekânın güçlü olduğu alanla klasik, kurallı yazılımın güçlü olduğu alanı doğru noktada birleştirmekten geliyor. Dil anlamak bir iş, geometri kurmak başka bir iş. İkisini aynı araca yüklediğinizde ikisinden de vasat sonuç alıyorsunuz.

Bir mimarın geri bildirimi her şeyi netleştirdi

Ürün belli bir olgunluğa geldiğinde, bir mimarlık ofisinin tasarım ekibinden bir mimar onu test etti. Bu benim için çok değerliydi, çünkü kendi ürününüzü kendi gözünüzle test ettiğinizde göremediğiniz şeyler oluyor. Bir mimar ise plana bambaşka bir yerden bakıyor.

Geri bildirimi açık ve netti. Üç katlı bir villa istemişti, sistem ona tek kat vermişti. CAD dosyasında duvar kesişimleri hatalıydı; kapı ve pencerelerin duvarla birleştiği yerler düzgün değildi. Genel değerlendirmesi ise şuydu: ilk taslak için faydalı.

"İlk taslak için faydalı" cümlesi bir övgü gibi görünebilir ama bana asıl söylediği başka bir şeydi. Bu cümle, ürünün nerede durduğunu ve nereye gitmesi gerektiğini aynı anda gösteriyordu. O ana kadar belki farkında olmadan taslak üreten bir araç yapıyordum. Bu geri bildirimden sonra hedefi yeniden tanımladım: amaç taslak değil, proje üretmek. Yani bir mimarın açıp üzerinde çalışabileceği, temel hataları olmayan, katları doğru ayrılmış, çizimi temiz bir çıktı.

Bu hedef değişikliğinin ardından birçok şeyi düzelttim. Bunlardan bazılarını özellikle anlatmak istiyorum, çünkü her biri farklı türden bir dersi temsil ediyor.

Katlar DXF'te üst üste basılıyordu

Çok katlı planlarda katların DXF dosyasında üst üste basıldığını fark ettim. Ekranda her kat ayrı ayrı doğru görünüyordu, ama dışa aktarılan dosyayı açtığınızda zemin kat ile üst kat aynı koordinatlara yığılmış hâldeydi. Bir mimar bu dosyayı açtığında karşısında okunamaz bir çizgi yığını buluyordu. Çözüm olarak her katı ayrı paftalara ayırdım. Bu küçük gibi görünen değişiklik, çıktının gerçekten kullanılabilir olmasını sağladı.

Sohbetle düzeltme ile yeni tasarım isteği karışıyordu

PlanAI'de kullanıcı bir planı sohbet ederek düzeltebiliyor. Örneğin bir odanın büyümesini ya da bir pencerenin taşınmasını isteyebiliyor. Ancak bazı kullanıcılar sohbet sırasında aslında tamamen yeni bir tasarım istiyordu; sistem bunu mevcut planın bir düzeltmesi gibi ele almaya çalışınca ortaya tutarsız sonuçlar çıkıyordu. Yeni tasarım isteğini düzeltme isteğinden ayrıştıran bir katman ekledim. Artık sistem önce kullanıcının ne istediğini anlıyor, sonra mevcut planı mı düzenleyeceğine yoksa sıfırdan mı başlayacağına karar veriyor.

Kötüleştiren düzeltme kaydedilmiyor

Belki de en önemli değişikliklerden biri buydu. Bir düzeltme planı iyileştirmek yerine kötüleştiriyorsa, o düzeltme artık kaydedilmiyor. Bu basit bir kural ama arkasındaki düşünce önemli: kullanıcı bir şey istedi diye sistemin elindeki iyi bir planı bozmasına izin vermemek gerekiyor. Her değişiklik bir ölçütten geçiyor ve önceki hâlden daha kötüyse geri alınıyor.

Kalite kapısı: plan dışarı çıkmadan önce

Mimarın geri bildiriminden çıkardığım en büyük ders şuydu: kaliteyi tek tek fark edilen hatalara bırakamazsınız. Kalite çıtası ölçülebilir kurallara çevrilmeli ve bu kurallar her plana otomatik olarak uygulanmalı. Bu yüzden bir kalite kapısı kurdum. Bir plan kullanıcıya gösterilmeden ya da yayına çıkmadan önce bir dizi otomatik kontrolden geçiyor.

Bu kontrollerin bazıları şunlar:

Her odanın bir kapısı var mı?
Yatak odaları hole mi açılıyor, yoksa başka bir odanın içinden mi geçiliyor?
Merdiven katlarda hizalı mı?
Üst kat, alt katın üzerinde mi duruyor, yoksa boşluğa mı taşıyor?
Balkon gerçekten dış cepheye değiyor mu?
Koridorun oranı makul mü, yoksa gereksiz uzun ve dar bir şerit mi?
Salon ile yatak odası arasındaki oran mantıklı mı?
Mutfak en az 8 m² mi?
Ebeveyn banyosu ve giyinme odası holden değil, yatak odasından mı açılıyor?

Bu liste bir mimar için büyük ihtimalle çok tanıdık. Bunlar iyi bir planın temel nitelikleri; çoğu deneyimli bir tasarımcının içgüdüsel olarak dikkat ettiği şeyler. Ama bir yazılım için içgüdü yok. Yazılımın bu nitelikleri "bilmesi" için onları açık, ölçülebilir ve kontrol edilebilir kurallara dönüştürmeniz gerekiyor. Bu dönüşüm, ürünü geliştirirken yaptığım en değerli işlerden biri oldu.

Bir hatanın anatomisi: dubleksin üst katı

Kalite kapısının neden gerekli olduğunu en iyi anlatan örnek, dubleks planların üst katında yaşadığım bir hata. Üst katta hol ile yatak odaları arasında bir koridor şeridi oluşuyordu ve bu şerit boş kalıyordu. Yani motor koridor için yer ayırıyordu ama o koridoru odalara bağlamıyordu. Sonuç olarak odalar kapısız kalıyordu. Üstelik ebeveyn yatak odasına yalnızca giyinme odasından girilebiliyordu; odanın kendine ait doğrudan bir girişi yoktu.

Bu hatayı ilginç kılan şey, planın ilk bakışta makul görünmesiydi. Odalar doğru büyüklükteydi, doğru yerlerdeydi, isimleri doğruydu. Ama içinde yaşamaya kalktığınızda bazı odalara giremiyordunuz. Tam olarak "çalışıyor ama iyi değil" durumunun somut bir örneğiydi.

Hatayı düzelttim ve daha önemlisi, kalite kapısındaki kontroller sayesinde bu tür bir hatanın bir daha fark edilmeden yayına çıkmasının önüne geçtim. Bugün bu kontrolleri geçen dubleks ve villa planları yayında. Kontrolü geçemeyen plan ise kullanıcıya ya da kütüphaneye ulaşmıyor.

Herkese açık plan kütüphanesi

Bu sürecin doğal bir sonucu olarak herkese açık bir ev planları kütüphanesi oluşturdum. Bu kütüphanenin benim için önemli bir ilkesi var: içindeki her plan motorun çıktısı ve hiçbiri elle düzenlenmedi. Yani orada gördüğünüz şey, sistemin gerçekte ne ürettiğinin dürüst bir yansıması. Her planın yanında bir oda tablosu bulunuyor ve DXF dosyası ücretsiz olarak indirilebiliyor.

Kütüphaneyi kalite kapısıyla birlikte düşündüm. Kurallardan geçmeyen plan yayımlanmıyor. Bunun birkaç somut örneği var:

10×10 m arsada bir 3+1 plan kuralları geçemedi, bu yüzden yayında değil. Aynı arsa için 2+1 plan kuralları geçti ve yayımlandı.
Tek katlı bir planda salon yatak odasından küçük çıktı. Bu oran kuralına takıldığı için o plan henüz yayında değil.

Bu kararlar bana bir ürün sahibi olarak bazen zor geldi. Kütüphanede daha fazla plan olması, daha fazla seçenek sunması cazip. Ama kuralları geçemeyen bir planı yayımlamak, kalite kapısını kurmanın bütün anlamını ortadan kaldırırdı. Daha az ama doğru plan, daha çok ama kusurlu plandan daha değerli. Şu an kütüphanede dubleks ev planları ve villa planları gibi kategoriler, bu kontrollerden geçmiş planlarla yer alıyor.

"Çalışan" ile "iyi" arasındaki fark

Bu sürecin bana öğrettiği en temel ders, "çalışan" ile "iyi" arasındaki farkın ne kadar büyük olduğu. İlk denemelerimde ekranda bir plan görünüyordu; teknik olarak sistem çalışıyordu. Ama o plan iyi değildi. Odalar üst üste diziliyordu, katlar karışıyordu, bazı odalara girilemiyordu.

Çoğu yazılım projesinde "çalışıyor" noktasına ulaşmak bir başarı gibi kutlanır. Oysa asıl iş tam o noktada başlıyor. Bir şeyin çalışması, kullanıcının onunla gerçek bir değer üretebileceği anlamına gelmiyor. Bu fark, özellikle yapay zekâ ile geliştirilen ürünlerde daha da belirgin, çünkü yapay zekâ ikna edici görünen ama içi boş çıktılar üretmekte çok başarılı.

Kullanıcı hata avcısı değildir

Öğrendiğim ikinci önemli ders şu: kullanıcı hata avcısı değildir. Bir ürünü kullanıma açıp hataları kullanıcıların bulmasını beklemek kolay bir yol gibi görünebilir. Ama bu, kullanıcının zamanına ve güvenine saygısızlık. Mimar bana o geri bildirimi verdiğinde teşekkür ettim, ama aynı zamanda bu hataların bazılarını benim daha önce yakalamam gerektiğini de fark ettim. Kalite kapısını kurmamın asıl nedeni buydu: hataları kullanıcıdan önce sistemin kendisi bulsun.

Kalite çıtası ölçülebilir olmalı

Üçüncü ders, kalite çıtasının ölçülebilir kurallara çevrilmesi gerektiği. "İyi bir plan" demek kolay, ama bunun ne anlama geldiğini tanımlamadığınız sürece onu ne ölçebilir ne de garanti edebilirsiniz. Mutfak en az 8 m² olmalı, yatak odaları hole açılmalı, merdivenler hizalı olmalı gibi somut kurallar, belirsiz bir kalite hissini kontrol edilebilir bir şeye dönüştürüyor. Bu yaklaşımı SEO işlerimde de uzun süredir kullanıyorum; burada aynı mantığın mimari bir ürüne ne kadar iyi uyduğunu görmek öğretici oldu.

Son olarak çok net bir sınırı vurgulamak istiyorum. PlanAI bir mimarın yerine geçmiyor ve geçmeye de çalışmıyor. Ruhsat projesi mimarın işidir. Bir yapının yönetmeliklere uygunluğu, statik gereklilikleri, arsanın ve çevrenin özel koşulları, kullanıcının hayatına dair ince ayrıntılar; bunların hepsi bir mimarın uzmanlığını ve sorumluluğunu gerektiren konular.

Aracın gerçek değeri başka bir yerde. İlk taslağı hızlandırıyor ve varyant aramayı kolaylaştırıyor. Bir mimar ya da ev yaptırmayı düşünen biri, farklı yerleşim seçeneklerini hızlıca görüp karşılaştırabiliyor. Bu da tasarım sürecinin en çok zaman alan kısımlarından birini kısaltıyor. Mimarın geri bildirimindeki "ilk taslak için faydalı" ifadesi bu açıdan hâlâ doğru; yalnızca ben o ilk taslağın, temel hatalardan arınmış ve üzerinde çalışılabilir bir proje niteliğinde olmasını hedefliyorum.

Sonuç: göründüğünden zor, ama doğru yolda

Yapay zekâ ile ev planı çizmek, gerçekten göründüğünden çok daha zor. Bunun nedeni yapay zekânın yetersiz olması değil; yanlış işe koşulması. Dil modellerini doğru yerde, yani insan isteğini anlayıp yapılandırılmış bir programa çevirmekte kullandığınızda çok güçlüler. Geometriyi ise kurallarla çalışan, kararlarının izini sürebildiğiniz bir motora bırakmak gerekiyor.

Bu yolculukta en çok değer veren şey, dışarıdan gelen dürüst bir bakış oldu. Bir mimarın birkaç cümlelik geri bildirimi, ürünün hedefini yeniden tanımlamama ve kalite anlayışımı kurallara dökmeme yol açtı. Bugün PlanAI'de bir plan kullanıcıya ulaşmadan önce bir dizi kontrolden geçiyor ve bu kontrolleri geçemeyen plan dışarı çıkmıyor.

Hâlâ yapılacak çok şey var. Kütüphanede henüz yayımlanmamış planlar var, çünkü kuralları geçemiyorlar. Ama bu bir eksiklik değil, sistemin doğru çalıştığının işareti. Bir ürünün neyi yayımlamadığı, en az neyi yayımladığı kadar onun kalitesi hakkında bilgi veriyor.

Eğer siz de yapay zekâ ile bir ürün geliştiriyorsanız, bu deneyimden çıkarabileceğiniz şey basit: yapay zekâyı her işi yapan sihirli bir kutu olarak değil, belirli bir işte çok iyi olan bir bileşen olarak düşünün. Kalitenizi tanımlayın, ölçülebilir kurallara çevirin ve hataları kullanıcılarınızdan önce siz yakalayın. "Çalışıyor" bir başlangıç noktası; asıl hedef "iyi" olmak.