І оновлення по темі BA як Solution Architect 🏗️

В принципі, все досить реальноBA може зробити себеМоже написати сам мегапродукт 🤖

Однак трошки ентузіазму я збавив 😄

У тому плані, що складність продукту має свої межі — принаймні наразі, з поточним розвитком технологійПроблема в тому, що в якийсь момент під час прямої роботи з LLMпри створенні застосунку або системи — просто “вибухає” контекст 🧠

Він стає складним або навіть неможливим для роботи. Задачі через це стають складнішими в реалізації. Будь-які зміни не завжди покриваються навіть топовими моделями 🤷‍♂️

І в цілому їх стає складно контролювати. Ну, як і будь-який складний проєкт, це потребує масштабуванняі більшого контролю. Тобто навіть якщо у класичній розробці ви збільшуєте команду 👨‍💻 то тут ви або збільшуєте акаунт моделі (Pro, Max, Ultra і т.д.) або підключаєте кількох агентів паралельноАле так чи інакше — все одно доведеться це контролювати 🎯

Я з цим сам стикаюсь у вільний час з тією ж моделлю Opus(зараз я її називаю “Слопус” 😅 — ну вибачте, такий тиждень із Claude не задався)Модель не все робить ідеальноІ це означає, що треба:— більше часу— більше уваги— більше контролюТреба розуміти реальний вплив змінРобити бізнес-аналізПланувати архітектуру ще на старті 🏗️

Планувати вимоги ще на старті 📋

Розуміти, яке бачення продукту єІ тоді — так, все може вийти 👍

Бо якщо писати навмання —впираєшся в серйозні проблеми:— архітектурні— логічніІ найгірше — їх дуже дорого розрулювати 💸

Дуже дорого. І тому я думаю, в цілому роль розробника як архітектора навіть в перспективі не зникне 🧩

Бо як BA знає, які вимоги треба описати в конкретній ситуації, так і архітектор знає, яке рішення попросити згенерувати у моделі або агентаБо іноді агенти заходять у тупик 🚧

І тут реально нічого нового — така сама історія, як і три роки тому 😄

Людина все одно має втрутитися і скоригувати. Більше того — не забуваємо: люди — це валідатори 👀

І все, що роблять ці агентські агенти — вони роблять це для людей. 🫂 #AIforBA