Teknik Özellikler Yeni Tel Çerçeve Oldu: 2026'da Teknik Özelliklere Dayalı Tasarım

Tel çerçeve artık gereksiz bir yük. Şimdi ürünün piyasaya sürülmesini sağlayan asıl unsur teknik şartname.

Yirmi yıldır tel çerçeve, ürün tasarımının merkezinde yer alıyordu. Kutular, oklar, düşük çözünürlüklü dikdörtgenler, yer tutucu metinler. İlk teslim edilebilir üründü, hizalama aracıydı, gerçek piksellere kimse dokunmadan önce Figma dosyasına sürüklediğiniz şeydi.

2026'da bu unsur sessizce geri plana atıldı. Yapay zeka kod üreteçleri, tel çerçevelerden daha iyi yapılandırılmış niyetleri okuyor ve ürün yöneticileri teknik şartnameleri doğrudan Cursor'a yönlendiriyor.

Mühendisler, Figma bağlantısı görünmeden spec.md dosyalarından özellikleri piyasaya sürüyor. Maket artık son adım, hatta bazen hiç görünmüyor.

Bu bir araç hikayesi değil. Bu bir zanaat değişimi. Teknik şartnameyi birincil unsur olarak ele alan tasarımcılar daha hızlı ürün teslim ediyor, daha temiz bir şekilde devrediyor ve piksel dosyalarıyla olduğundan daha fazla yüzey alanına sahip oluyorlar. Figma tuvalinde sürekli dikdörtgenler çizen tasarımcılar, etkilerinin gerçek zamanlı olarak buharlaştığını görüyorlar.

Tel çerçevelerin önceliğini kaybetmesinin nedenleri

Tel çerçeve, bir ekranın teslimi için dört kişi, üç el değiştirme ve bir sprint gerektiği bir dünyada yerini kazandı. Yüksek çözünürlüklü olanı pahalı olduğu için düşük çözünürlüklü bir ürüne ihtiyaç duyuluyordu. Mühendisler ve proje yöneticileri bir Figma dosyasına bakıp ne anlama geldiği konusunda anlaşamadıkları için bir çeviri katmanına ihtiyaç duyuluyordu.

O dünya artık yok. Cursor, Claude Code, v0, Bolt ve onlardan sonra gelen dört araç, bir özelliğin açık bir yazılı tanımını alıp dakikalar içinde çalışan bir yüzey üretebiliyor. Tel çerçevenizi okuyamıyorlar. Spesifikasyonunuzu okuyabiliyorlar.

Darboğaz yer değiştirdi. Pikseller artık ucuz, niyet kıt bir kaynak.

Tel çerçeve düzeni kodlar. Spesifikasyon ise niyeti, davranışı, uç durumları ve özelliğin doğru olduğu koşulları kodlar. Tahmin edin, bir kod oluşturma aracı aslında hangisine ihtiyaç duyuyor?

Ayrıca, ekip düzeyinde daha sessiz bir değişim yaşanıyor. Tasarımcı-proje yöneticisi rolünün bulanıklaşması, tasarım mühendisinin yükselişi, çoğu ürün ekibinde özel araştırmacının ortadan kaybolması. Hepsi aynı yöne işaret ediyor. Bu bulanık roller arasında iyi bir şekilde ilerleyen unsur, kutular değil, metindir.

Tel çerçeveler de temelde henüz şeyi göremeyen insanlar için bir planlama aracıydı. Yapay zeka araçları, bir açıklamadan saniyeler içinde kabul edilebilir bir çalışma yüzeyi oluşturabilir. "Hadi görelim"in maliyeti düştü.

Düşük çözünürlüklü bir versiyonu çizmekten daha kısa sürede gerçek bir etkileşimli yüzey oluşturabildiğinizde, düşük çözünürlüklü versiyon artık kullanışlı olmaktan çıkar. Ya doğrudan spesifikasyona geçersiniz ya da doğrudan prototipe geçersiniz ve dikdörtgenleri tamamen atlarsınız.

Maket neyi açıklar. Spesifikasyon nedenini açıklar.

Bir maket tek bir soruyu yanıtlar: Bu nasıl görünmeli? Bir spesifikasyon daha zor soruları yanıtlar. Bu ne için ve kimin için?

Veriler boş olduğunda ne olur? Ağ çöktüğünde ne olur? Burada başarı ne anlama geliyor?

2026'da iyi bir tasarımcı önce teknik şartnameyi yazar ve görselin kendiliğinden ortaya çıkmasına izin verir. Tersine değil. Görsel, kararın sonrasında gelir ve karar teknik şartnamede yer alır.

Bu yeni bir bilgi değil. Kıdemli tasarımcılar yıllardır yapılandırılmış gerekçeler yazıyorlar. Yeni olan şey, teknik şartnamenin artık yapay zeka araçlarının doğrudan tükettiği varlık olması, yani teknik şartnamenizin yazım kalitesinin artık çok önemli olmasıdır.

Belirsiz bir teknik şartname belirsiz çıktı üretir ve bu belirsizliğin maliyeti artık kafası karışmış bir mühendis değildir. Hurdaya çıkarmak zorunda kaldığınız yarım kalmış bir özelliktir.

Harika bir tasarım teknik şartnamesinin anatomisi

Hem mühendislerle hem de yapay zekayla temastan sağ çıkan teknik şartnamelerin istikrarlı bir şekli vardır. Hızlı ürün gönderen ürün ekiplerinde yüzlerce teknik şartnameye baktıktan sonra, desen tutarlıdır.

Çalışan bir tasarım spesifikasyonu, şu sırayla yedi bölümü kapsar:

1. Amaç. Bunun neden var olduğunu, hangi kullanıcı sorununu çözdüğünü ve ürün piyasaya sürüldükten sonra ne gibi değişiklikler getirdiğini açıklayan bir paragraf.

2. Kapsam. Nelerin dahil olduğu ve nelerin açıkça hariç tutulduğu; hariç tutulanlar listesi, dahil edilenler listesinden daha fazla iş görür.

3. Davranış. Kullanıcının özellik ile etkileşime girdiğinde adım adım neler olduğunu, tetikleyicileri, durumları, geçişleri ve sonuçları da içerecek şekilde açıklayan bir liste.

4. Uç Durumlar. Kimsenin yazmak istemediği ama herkesin ihtiyaç duyduğu gösterişsiz liste: boş durum, hata durumu, yükleme durumu, izin reddedildi, ağ çevrimdışı, hız sınırı aşıldı, eski veriler.

5. Başarı Kriterleri. Nasıl çalıştığını nasıl anlıyoruz, ölçülebilir, "kullanıcıların tasarruf etmekten memnun olması" değil, "yüzde 40'ın üzerinde tasarruf oranı" gibi.

6. Değerlendirmeler. Uygulamanın amacına uygunluğunu doğrulamak için otomatik olarak test edeceğimiz şeyler; yapay zeka iş akışlarının eski tasarımdan gerçekten ayrıldığı nokta burasıdır.

7. Erişilebilirlik ve metin. WCAG gereksinimleri, klavye yolları, ekran okuyucu davranışı ve kullanıcının ürünün sesinde gördüğü her metin.

İşte çalışma çekirdeği budur. Bazı özellikler, tasarım sistemi belirteçlerine, benzer özelliklere veya emsallere bağlantı veren bir "Referanslar" bölümü ekler. Bazıları, ekibin geliştirme sırasında dikkat etmesi gereken şeyleri işaretleyen bir "Riskler" bölümü ekler. Yukarıdaki yedi madde müzakere edilemez.

İçinde olmayanlara dikkat edin. Ekran görüntüsü yok, yerleşim şeması yok, kutu ve ok akışı yok. Özellik, özelliği bir resim olarak değil, bir dizi kısıtlama ve davranış olarak tanımlar.

Uygulamada önce tel çerçeve mi yoksa önce özellik mi?

Önce tel çerçeveden önce özellik'e geçiş, yapıttan daha fazlasını değiştirir. Bu, bir ekipte kimin neyi, ne zaman ve nasıl yaptığını değiştirir.

| Boyut | Tel çerçeve öncelikli iş akışı | Spesifikasyon öncelikli iş akışı |

|---|---|---|

| Birincil çıktı | Düşük çözünürlüklü ekranlar içeren Figma dosyası | Markdown spesifikasyonu, ~200 ila 500 satır |

| İlk derleme süresi | 3 ila 7 gün | Aynı gün, genellikle aynı saat |

| Mühendis girdisi zamanlaması | Maket "tamamlandıktan" sonra | Spesifikasyon taslağı sırasında |

| Yapay zeka aracı kullanımı | Sınırlı, geç aşama | Birincil derleme yolu |

| Uç durum kapsamı | Kalite kontrolünde keşfedilir | 4. bölümde önceden yazılır |

| Teslim formatı | Figma bağlantısı artı açıklamalar | Spesifikasyon dosyası artı tasarım belirteçleri |

| Yineleme birimi | Ekran veya akış | Spesifikasyonun bölümü |

| Niyetin nerede olduğu | Tasarımcının kafasında | Sayfada, yazılı olarak |

Önce spesifikasyon yazma yaklaşımı gelecekteki bir durum değil. En hızlı ürün geliştirme ekiplerinin 2026'da zaten nasıl çalıştığını gösteriyor. Önce tel çerçeve oluşturma yaklaşımı ise yavaş ekiplerin hala "tasarım" dediği şeydir.

Spesifikasyonların Yapay Zeka Araçları Üzerinden Nasıl Yönlendirildiği

İyi yazılmış bir spesifikasyon, Notion'da sonsuza dek kalan bir çıktı değildir. Bir girdidir.

Özellik, özelliğin iskeletini oluştururken Cursor'a yapıştırdığınız şeydir. Çalışan bir rota istediğinizde Claude Code'e verdiğiniz şeydir. İlk kullanıcı arayüzünü oluşturduğunuzda v0'ın okuduğu şeydir. Bir prototip çalıştırdığınızda Bolt'un tükettiği şeydir.

Aynı yapıt, farklı şekilde yönlendirilerek, yapının her bölümünü yönlendirir.

Mühendisler uygulama sırasında buna başvurur. Tasarım sistemleri ekipleri, belirteç kullanımını doğrulamak için bunu kullanır. QA, başarı kriterleri ve değerlendirme bölümlerine karşı testler yazar. Hatta pazarlama ekibi bile niyet paragrafından lansman metnini çıkarabilir.

Bu, spesifikasyonun bir yapıt olarak ele alınmasının gerçek kazanımıdır. Tek bir doğruluk kaynağı, bir kez yazılır, her araç ve her rol tarafından kullanılır. Artık "Figma güncel değil ama Linear biletinde en güncel sürüm var" yok. Arka uç kısıtlamaları keşfedildikten sonra tasarımcıların mühendisleri takip ederek mock'ları güncellemelerini istemelerine gerek yok.

Spesifikasyon depoda yaşar. Kodla birlikte hareket eder ve çekme isteklerinde incelenir. Spesifikasyon değiştiğinde, değişiklik izlenir, tarihlendirilir ve kredilendirilir. Bunu bir Figma dosyasıyla yapmayı deneyin.

Mühendisler ve Yapay Zeka ile temastan sağ çıkacak spesifikasyonlar yazmak

Kötü bir spesifikasyonu tespit etmenin en hızlı yolu, onu bir kod üreteciye vermek ve geri gelenleri okumaktır. Çıktı yanlışsa, spesifikasyon yanlıştır. Model acımasız ama adil bir editördür.

Kötü özellikler ortak özellikler taşır. Ürün ekibinin jargonunu kullanırlar, ekip dışındaki kimse anlamaz ve etkileşimleri kullanıcı eylemleri ("kullanıcı kaydetmeyi onaylar") yerine kullanıcı arayüzü bileşenleri ("modal") olarak tanımlarlar. Yazar, okuyucunun anlayacağını varsaydığı için uç durumları atlar. Başarı kriterlerini birinin kafasında saklarlar.

İyi özellikler somuttur. Bileşenleri değil, davranışları adlandırırlar ve boş durumu sade bir dille yazarlar. Başarıyı, sistemin ölçebileceği sayılarla tanımlarlar. Okuması sıkıcıdır çünkü belirsizlikten kurtulan şey sıkıcılıktır.

Faydalı bir test: Özelliğinizi ürünü hiç görmemiş birine verin ve neyin inşa edildiğini açıklamasını isteyin. Bunu yapabiliyorsa, özellik iyidir. Üç açıklayıcı soru soruyorsa, özellikte üç eksiklik vardır. Bunları düzeltin ve yayınlayın.

İçgörü: Bir kod üreteci, özelliğinizin karşılaşacağı en dürüst editördür. Derleme yanlışsa, yazım yanlıştır.

Tam Açıklamalı Mini-Spesifikasyon

İşte gerçek bir özellik için çalışan bir spesifikasyonun nasıl göründüğü. Bu, varsayımsal bir SaaS için, bugün bir depoya kopyalanıp yapıştırılabilir şekilde yazılmış, kısa ve öz bir şekilde hazırlanmış koleksiyona kaydetme şablonudur.

# Spec: Save to Collection ## Intent Users browsing content need a way to bookmark items into named groups so they can return to them later. Without this, repeat visit rate drops and high-intent users churn. ## Scope In: save action on any content card. Collection picker. Default "Saved" collection. Create new collection inline. Out: collection sharing. Collaborative collections. Collection cover images. Reordering items within a collection. ## Behavior 1. User clicks the save icon on a content card. 2. Picker opens, anchored to the card, listing user's collections plus a "+ New collection" row. 3. User selects a collection. Item is saved. Picker closes. Toast confirms with collection name and an Undo action. 4. If user selects "+ New collection", inline input appears. On submit, collection is created and item is saved to it. ## Edge cases - User not signed in: clicking save opens auth modal, resumes save action after auth. - No collections exist: picker shows "+ New collection" only, with placeholder text "Save your first item." - Network error mid-save: toast shows error, save action remains available, item is not marked saved. - Item already in target collection: picker shows checkmark, selecting it removes the item from that collection. - User hits free-tier collection limit: "+ New collection" row shows lock icon and routes to upgrade. ## Success criteria - 30%+ of weekly active users save at least one item per month. - Average user has 2.4+ collections within 30 days of first save. - 60%+ of saved items are revisited within 14 days. ## Evals - E2E: save flow completes in under 2 seconds on 4G. - Unit: collection picker renders correctly with 0, 1, 50 collections. - Visual: picker anchoring stays within viewport on all breakpoints. ## Accessibility and copy - Save button: aria-label "Save to collection". - Picker is fully keyboard navigable. Esc closes. - Focus returns to save button on close. - Toast is announced via aria-live="polite". - Copy: "Saved to [Collection]" / "Undo" / "Save your first item".

Bu spesifikasyon yaklaşık 40 satırdan oluşuyor ve sıfır piksel içeriyor. Bir yapay zeka aracı, bu özelliğin çalışan bir sürümünü tek seferde oluşturabilir. Bir mühendis bunu on beş dakikada kapsamlandırabilir ve bir QA lideri test planını doğrudan değerlendirmeler bölümünden yazabilir.

İşte bu, ortaya çıkan sonuç. Bir Figma dosyası değil. Bir akış şeması değil. İşte bu.

İlk Spesifikasyonunuzu Nasıl Yazarsınız

Daha önce hiç yazmadıysanız, buradan başlayın. İyi bildiğiniz küçük bir özellik seçin ve boş bir Markdown dosyası açın. Yukarıdaki yedi bölümlü şablonu kullanın ve 90 dakikalık bir zamanlayıcı ayarlayın.

Önce niyet paragrafını yazın. Eğer üç cümleyle yazamıyorsanız, özelliği henüz tam olarak anlamamışsınız demektir. Durun ve devam etmeden önce bunu çözün.

Ardından kapsamı yazın. "Dış" listesi en önemli kısımdır. Bu özelliğin ne olmadığına dair beş şey yazmaya kendinizi zorlayın. Çoğu spesifikasyonun gerçek sınırlarını burada bulur.

Sonraki adım davranış. Numaralandırılmış bir liste olarak, sade bir dille, ürünü hiç kullanmamış zeki bir arkadaşınıza anlatıyormuş gibi yazın. Bileşen adları yok, tasarım jargonları yok, sadece kullanıcının ne yaptığı ve ne olduğu.

Kenar durumları ilk seferde en zor bölüm olacaktır. Davranış listenizi okuyun ve her adımda "ya bu başarısız olursa" diye sorun.

Boş veri, yanlış izinler, yavaş ağ. Kullanıcı yarı yolda geri çekiliyor. Her birini bir cümle olarak yazın.

Başarı kriterleri ve değerlendirmeler, belirsiz beklentileri ölçülebilir olanlarla değiştirdiğiniz yerdir. "Kullanıcılar bayılacak" bir başarı kriteri değildir. "Kaydetme oranı %30'un üzerinde" bir başarı kriteridir. İncelemede gerçekten savunacağınız üç sayı seçin.

Son olarak, erişilebilirlik ve kopyalama. Her dizeyi yazın, klavye yollarını tanımlayın ve aria etiketlerini belirtin. Bu bölüm, başka hiçbir şeyin yapamayacağı netliği zorunlu kılar.

Dosyayı Notion'de değil, depoda kaydedin. Özellik klasöründe spec.md olarak adlandırın. Bundan sonra, bu kaynak koddur.

İpucu: Depoda bulunan özellikler kodla birlikte taşınır. Notion'de bulunan özellikler, derleme başladığı anda geçersiz hale gelir.

Tasarım sisteminin yeri

Özellik odaklı tasarım, ancak altındaki tasarım sistemi sağlam ise işe yarar. Özellikler amacı tanımlar. Tasarım sistemi bileşenleri sağlar. Sistem karmaşık ise, özellikler bu karmaşayı her özelliğe aktarır.

2026'da hızlı teslimat yapan ekipler, tasarım sistemlerini yapay zeka araçları için halka açık bir API olarak ele alırlar. Token'lar görünüşe göre değil, amaca göre adlandırılır. Bileşenlerin belgelenmiş özellikleri, beklenen davranışları ve erişilebilirlik sözleşmeleri vardır. Sistemdeki her bileşen sayfası, niyet, davranış, uç durumlar ve kod içeren küçük bir spesifikasyon gibi okunur.

Bir spesifikasyon bir bileşene referans verdiğinde, bir ekran görüntüsüne değil, istikrarlı bir sözleşmeye işaret eder. "Yükseklik seviyesi 2 olan standart Card bileşenini kullanın" yeterlidir. Yapay zeka aracı bileşen belgelerini okur, spesifikasyon kısıtlamalar olarak okunur ve derleme özellikler arasında tutarlı olur.

Tasarım sisteminiz hala isimsiz yerel stillerle dolu bir Figma kütüphanesi ise, tamamen spesifikasyon odaklı yaklaşıma geçmeden önce ödeviniz var. Bileşenleri sade bir dille belgeleyin. Token'ları ne anlama geldiklerine göre adlandırın. Sistemi, yazdığınız ilk spesifikasyon olarak ele alın.

Tel çerçeveler hala işe yaradığında

Spesifikasyonlar çoğu tel çerçevenin yerini alır. Hepsinin değil. Hâlâ düşük çözünürlüklü bir görselin doğru araç olduğu durumlar var ve aksini iddia etmek sadece eğlence için karşı çıkmaktan ibaret.

Bir tel çerçevenin hâlâ yerini koruduğu üç durum:

1. Gerçekten yeni düzenler. Yeni bir mekânsal desen icat ediyorsanız, tasarım sisteminin henüz desteklemediği bir şeyse, onu çizmeniz gerekir, çünkü sadece kelimeler sizi oraya götürmez ve mekânsal bir fikir mekânsal bir çizime ihtiyaç duyar.

2. Kahraman bölümler ve marka odaklı anlar. Pazarlama sayfaları, lansman yüzeyleri ve kahraman modülleri; burada düzenin kendisi mesajdır, çünkü bir teknik özellik "pahalı hissettiriyor" mesajını iletemez ve bir tel çerçeve, görsel tasarımcı devreye girmeden önce en azından buna işaret eder.

3. Ürün dışı organizasyonlarda liderlik uyumu. Teknik özellik odaklı iş akışlarını benimsememiş bir yönetici ekibine sunum yapıyorsanız, tel çerçeve hâlâ birincil araçtan ziyade bir çeviri aracı olarak kullanılan ortak dildir.

İşte liste bu. Üç örnek. Diğer her şeyde, teknik şartname daha iyi bir eserdir ve tel çerçeve (wireframe) bırakmanız gereken bir alışkanlıktır.

Tasarımcılar için yeni portföy

Portföy sorusu, eser sorusunu takip eder. Eğer teknik şartnameler işin kendisiyse, bir portföy nasıl görünür?

2026'nın en güçlü tasarım portföyleri, ekran maketlerinden ziyade teknik şartname özetleriyle başlar. Niyet paragrafı, uç durum listesi ve teslim edilen özelliğin ekran görüntüsünü içeren bir sayfa, işe alım yöneticisi için on Dribbble fotoğrafından daha fazlasını ifade eder.

Karar verme yeteneğini gösterir. Kapsam disiplinini gösterir. Adayın gerçek işi yapabileceğini gösterir.

Maket galerisi hala mevcut, ancak portföyün ilk değil, ikinci kademesidir. Görseller zevki gösterir. Teknik şartnameler düşünmeyi gösterir. Gerçekten çalışmak istediğiniz şirketlerdeki işe alım yöneticileri düşünmeyi değerlendiriyor.

2026'ya geçiş yapan tasarımcılar, portföylerini her biri teknik şartnameye dayanan ve teslim edilen sonuçla biten üç ila beş örnek olay etrafında yeniden oluşturmalıdır. Figma bağlantısı değil. Gönderilen ürün. Teknik özellikler, işin özü.

Genç tasarımcılar nasıl yeniden beceri kazanmalı?

Şu anda iki grup genç tasarımcı var. Yapay zeka araçlarını saklamaları gereken ödev kopyaları olarak görenler ve onları yeni bir meslek olarak görenler. Beş yıl içinde sadece ikinci grubun kariyeri olacak.

Yeniden beceri kazanma yolu basittir. Yazmayı öğrenin, ama "tasarım eleştirisi geri bildirimi yazmayı öğrenmek" değil. Bir proje yöneticisinin PRD veya bir mühendisin RFC yazdığı gibi, yapılandırılmış teknik metin yazmayı öğrenin.

İyi teknik özellikler okuyun, onları taklit edin ve kıdemli birinden sizinkini gözden geçirmesini isteyin.

Yazdığınız bir teknik özellik ile günde bir saat Cursor veya Claude Code'de vakit geçirin, neyin inşa edildiğini ve amacınızdan nerede saptığını izleyin. Her sapma, teknik özelliğinizde bir boşluktur. Onu yamalayın, tekrar çalıştırın. Üç ay boyunca her gün yapılan bu döngü, tasarım hakkındaki düşüncelerinizi yeniden şekillendirecek.

Figma eklentileri hakkındaki eğitimlere zaman ayırmayı bırakın. Her araç değişikliğinde geçerliliğini koruyan yapılandırılmış düşünceye zaman ayırmaya başlayın. Teknik özellikler geçerliliğini korur. Piksel itme ise korumaz.

İçgörü: İyi teknik özellikler yazan genç tasarımcılar, yalnızca piksel iten meslektaşlarından iki kademe üstte çalışıyorlar. Bu fark her hafta daha da artıyor.

Bunu iki bitişik beceriyle birleştirin. İlk olarak, yapay zeka araçlarının teknik özelliklerinizden ne oluşturduğunu inceleyebilecek kadar iyi kod okumayı öğrenin. Üretim React yazmanıza gerek yok, ancak bir bileşen dosyasına bakıp belirttiğiniz davranışla eşleşip eşleşmediğini bilmeniz gerekiyor.

İkincisi, değerlendirmeleri öğrenin. "Boş durumun doğru kopyayı oluşturduğunu" doğrulayan bir test yazmak artık sadece mühendislik sorumluluğu değil, tasarım sorumluluğudur. Teknik özellik doğruluğu tanımlar, değerlendirmeler ise bunu uygular. Hem test hem de değerlendirme yazabilen bir tasarımcı, yalnızca piksel itebilen bir tasarımcıdan iki kademe üstte çalışıyor demektir.

Tasarımcılar İçin Bunun Anlamı

Piksel işleme artık araçlar tarafından otomatikleştirilmiş, şablonlar tarafından ticarileştirilmiş, daha alt düzey bir görev haline geldi. İş, hiyerarşide daha üst bir seviyeye çıktı. İş artık niyet tasarımı, kapsam disiplini, uç durum düşünme ve bir yapay zeka aracının sizin metninizden bir özellik üretebilmesi için yeterince iyi yazma becerisi gerektiriyor.

Bu, disiplin için bir gerileme değil. Tam tersi. İyi özellikler yazan tasarımcılar, eski iş akışının asla izin vermediği kadar geniş bir etki alanıyla, ürün stratejisine her zamankinden daha yakın çalışıyorlar.

İyi bir özellik yazma alışkanlığına sahip bir tasarımcı, eskiden dört kişilik bir ekibin yaptığı işi yapabilir. Çıktı farkı gerçek ve hafta hafta artıyor.

Bu hafta yapılacak iş küçük ve somut. Üzerinde çalıştığınız bir özelliği seçin, özelliklerini yazın, yedi bölümü kullanın. Bunu paralel olarak bir mühendise ve bir yapay zeka aracına verin.

Ne geri döndüğüne bakın. Bir tel çerçeve ile üreteceğiniz şeyle karşılaştırın. İki çıktı arasındaki fark, eski zanaat ile yeni zanaat arasındaki farktır.

Tel çerçeve uzun süre işe yaradı. Şimdi ise teknik özellikler işe yarıyor. Bir sonrakini yazın.

⟦KOD1⟧