ШІ-агенти пишуть код швидше, ніж ми здатні його зрозуміти: код можна делегувати, відповідальність — ні
Привіт! Мене звати Дамир Гадієв, я Principal R&D Engineer у SoftServe. У своїй роботі я займаюсь створенням наукоємних ШІ-рішень: від комп’ютерного зору та моделювання фізичних процесів до квантових обчислень.
Одразу важливо відмітити, що цей текст не про якість коду або рішень згенерованих ШІ, і відверто кажучи, більшість тверджень стосується в такій самій мірі і звичайної роботи в команді. Інструменти ШІ з нами надовго й уже є частиною більшості робочих процесів на різних рівнях. Наша задача — зрозуміти, як ними користуватись з максимальною користю для себе і інших.
У сучасного ШІ є багато викликів, на які знаходяться відповіді. На одному кінці спектру є примарний AGI (ASI, додайте свою назву), можна вірити або не вірити у віднайдення рішення для рівнянь Нав’є-Стокса, але сам факт, що це є частиною наукової дискусії сьогодні — це дуже гарне свідчення розвитку в цьому напрямку. На іншому кінці спектра є наша прикладна робота — розробка ПЗ.
Сьогодні на власні очі бачу, як агентні системи вже пишуть новий функціонал, виправляють баги та генерують пул-ріквести швидше, ніж будь-яка команда інженерів встигає їх перевірити. І навпаки, можна дуже легко побачити, як змінюється темп розробки, коли токени підійшли до лімітів в кінці місяця. Технології масштабуються практично безлімітно (в межах ресурсів, авжеж), а наша когнітивна здатність — ні. І тут виникає складне питання: хто насправді розуміє повноцінну картину в ситуації, коли клієнт + ШІ формулювали запит, бізнес-аналітик + ШІ перетворювали його на специфікацію, архітект + ШІ драфтили архітектуру, а розробник використовував трьох агентів і напіввідомі MCP-сервери, щоб за допомогою специфікації зробити задачі до пʼятничного релізу?
Зараз ШІ-агенти ставатимуть дедалі досконалішими, а роль інженера ставатиме вужчою, якщо говорити про кількість написаного коду, але набагато вагомішою з точки зору ціни помилки. Однак це призводить до збільшення когнітивного навантаження на інженера, його можливість сприймати інформацію може знижуватися.
І в негативному сценарії розробник втрачає здатність розуміти кодову базу, а згодом — втрачає контроль над нею. Усі тести можуть бути пройденими, але це не дорівнює якості. І жоден CI/CD пайплайн не здатен виявити цю деградацію до того, як вона перетвориться на проблему, яку неможливо виправити за один спринт.
Розберемо цю проблему глибше: що відбувається з якістю коду і як нам адаптувати процеси, щоб не втратити контроль над власним продуктом.
Анатомія проблеми: коли кількість вбиває якість
Сьогодні індустрія переживає безпрецедентний бум продуктивності. Згідно з глобальним дослідженням Agentic AI in Software Development, яке SoftServe нещодавно провів спільно з MIT Technology Review, 98% ІТ-лідерів очікують, що ШІ-агенти кардинально прискорять постачання програмного забезпечення. Більш того, 72% організацій очікують, що вже протягом наступних двох років ШІ-агенти керуватимуть більшою частиною або навіть усім життєвим циклом розробки (SDLC). Ці цифри чітко показують, що технологія дійсно допомагає вийти на новий рівень.
Ця швидкість — беззаперечна перевага для бізнесу та команд. Водночас вона формує новий інженерний виклик — як масштабувати використання ШІ так, щоб фокус на продуктивності не шкодив архітектурній цілісності системи. Не можна генерувати більше коду, залишаючи старі процеси контролю.
У межах масштабного дослідження від аналітиків GitClear проаналізували понад 150 мільйонів рядків коду у
Цей «когнітивний зсув» уже б’є і по сеньйорах. У нещодавньому рандомізованому контрольованому дослідженні від організації METR (Model Evaluation and Threat Research), яка спеціалізується на оцінці автономності ШІ на складних інженерних та безпекових завданнях, виявилося, що на архітектурно важких тасках досвідчені інженери з ШІ витрачали на 19% більше часу, ніж ті, хто писав усе сам. Адже читати, дебажити та виправляти нелогічний ШІ-код у незнайомій системі часто складніше, ніж написати його з нуля. Крім того, аналітика фіксує стрімке зростання Code Churn — відсотка коду, який доводиться переписувати протягом двох тижнів після релізу, бо він не витримує зіткнення з реальними кейсами.
Як повернути собі контроль
Щоб не перетворитися з інженерів на «операторів ШІ», нам потрібно адаптувати процеси і себе. Важливо розуміти, що відповідальність за результат завжди залишається на реальних людях. Змінилися вимоги щодо швидкості або якості — але дедлайни і бюджет будуть завжди. Я би хотів навести деякі принципи, що допомагають зберігати якість, час розробників, очікування від процесу і гарне самопочуття, коли ви працюєте з ШІ-агентами. Тут важливо сказати, що більшість із порад не має відношення до зусиль створити повні агентські воркфлоу, де мета якраз вивести людину за межі розробки — це окрема задача, яка має свої критерії оцінки.
Зміна парадигми Ownership
Продовжуючи тему відповідальності самих розробників — вона не делегується моделі, IDE чи вендору. Коли ви працюєте з ШІ-агентами, code ownership залишається за вами. Ви, як і раніше, відповідаєте за поведінку, підтримку та технічний вектор розвитку системи. Це означає, що саме ви маєте перетворювати бізнес-вимоги на чіткі задачі та вирішувати, чи дійсно запропонована ШІ імплементація має жити в кодовій базі. Те, що тести пройшли успішно — це необхідна умова, але вже далеко не достатня.
На рівні команди це перетворюється на серйозне архітектурне питання. Уявіть команду з двадцяти інженерів, де кожен одночасно запускає по два-три потоки генерації коду. Хто в такій системі відповідає за дизайн-рішення, які жоден з цих ШІ-агентів не приймав свідомо? Архітектурна цілісність не народжується з промптів. Вона (наразі) вимагає команди, яка бачить картину цілком і активно її захищає. В цьому сенсі — нічого не змінилось з приходом ШІ: документуйте знахідки, спілкуйтесь з командою, налаштовуйте процеси, ескалюйте проблеми і контролюйте результат генерації.
Втома — ворог критичного мислення
Зараз часто говорять, як один розробник може паралельно керувати десятком потоків ШІ-генерації. На практиці більшість інженерів здатна ефективно вести максимум два-три потоки, а коли задача вимагає справжнього архітектурного мислення — ще менше.
ШІ-агенти не втомлюються. А от людина, яка інтегрує їхній результат — ще й як. І це не проблема конкретного розробника, це фізичне обмеження, навколо якого мають будуватися процеси. Якщо організація планує капасіті спринта з розрахунку, що кожен інженер тепер працює на піку багатозадачності, вона неминуче накопичить гігантський борг код-рев’ю.
Головний ліміт — це наше критичне мислення, а не пам’ять ШІ
Моделі ШІ можуть аналізувати мільйони рядків коду. Уявіть ШІ-агента як дуже талановитого сеньйора, який приєднався до вашої команди лише вчора, а коли візьметься за наступну задачу — забуде те, що зробив. Він має доступ до всього репозиторію, але зовсім не знає бізнес-логіки та історії прийняття рішень. Він пише красивий код, впевнено робить висновки, але частина з них обов’язково буде хибною просто через брак контексту. І найгірше те, що ви помітите цю помилку лише тоді, коли щось зламається на продакшені, адже всі згенеровані тести ж були зелені. І ця помилка буде настільки неочевидною, бо ми все ще очікуємо результатів, схожих на результати людини.
Потрібно постійно «вмикати» власне критичне мислення. Чудовий спосіб це практикувати — взяти за правило писати коміт-меседжі власноруч, а не делегувати це штучному інтелекту. Коли ви змушені простими словами пояснити колегам, що саме змінилося в коді і чому, ви перевіряєте самі себе. Якщо ви не можете чітко цього сформулювати — ймовірно, ви насправді не до кінця розумієте, що саме згенерував ШІ. Зловити себе на цьому нерозумінні набагато безпечніше під час написання коміту, ніж розгрібати наслідки.
Вміння писати код — це компонент стійкості системи
Є величезна спокуса просто прийняти згенерований ШІ код, який закриває цілу фічу. Особливо, коли він виглядає правильним, тести світяться зеленим, а дедлайн — на вчора. Проте це ризиковий підхід, який призводить до класичного «ефекту GPS»: навички орієнтування в просторі гіршають після років їзди за навігатором. Деградація невидима рівно до того дня, поки не зникне сигнал, і ви не опинитеся в незнайомій місцевості без карти.
Розуміти структуру системи можна лише через прямий контакт із кодом. Якщо розробники працюють виключно як «рев’ювери» згенерованого ШІ коду, виникає прихована загроза — знання компанії концентруються в інструменті, а не в головах людей. Ця втрата кваліфікації ніяк не відображається на метриках продуктивності. Проте вона вдарить по вас у найгірший момент: коли на продакшені щось зламається так нетипово, що агент виявиться безпорадним.
Плануйте залежно від того, скільки зможете опрацювати, а не згенерувати
Часто радять використовувати великі моделі для архітектури, а менші — для написання коду. Але найважливіший принцип інший: підбирайте розмір задачі та промпт відповідно до вашої власної здатності вдумливо перевірити результат. Невелика модель, що реалізує одну функцію з чіткими контрактами вводу/виводу та прописаними edge cases, дасть чудовий результат, який ви дійсно зможете відрев’ювити.
Керуйте розробкою крок за кроком: спочатку інтерфейси, потім класи, специфічні методи, тести і лише тоді — інтеграція. Це насправді зменшує загальний час роботи, бо позбавляє вас нескінченного циклу «широкий промпт -> частковий фікс -> регресія -> новий промпт». Коли двадцять інженерів генерують код паралельно, загальний об’єм для рев’ю стає колосальним. Архітектурна цілісність зберігається лише тоді, коли ви генеруєте код порціями, зручними для людського сприйняття, а не для пропускної здатності LLM.
Правила проєкту мають бути машиночитними
Стандарти кодування, неймінг, вимоги до тестування, патерни логування, API-контракти та безпекові обмеження — все це було важливо завжди. Але в епоху ШІ-агентів з’явилася друга критична вимога: вони мають бути виражені у форматі, який інструмент може використати безпосередньо під час генерації коду. Документ із структурою бази даних у форматі фото з дошки зробленого кимось в 2005 році, який лежить десь у Confluence і кидається посиланням у Slack, коли хтось питає, — дає сумнівний результат.
Правила мають бути зашиті в IDE, лінтери та системні промпти середовища розробки. Суть інженерної дисципліни не змінилася, змінився спосіб її доставки. Команди, які інвестують у створення машиночитних правил, отримують правильний код вже з першого драфту ШІ, тим самим економлячи години часу на виправленнях під час код-рев’ю.
Економія токенів = легкість рев’ю
Відповідальна розробка за допомогою ШІ вже зменшує кількість непотрібних промптів. Але важливо розуміти: ефективність використання токенів — це проблема легкості рев’ю, а не лише фінансових витрат на API. Чим коротший і чіткіший згенерований контекст, тим більша ймовірність, що інженер (або модель) його дійсно прочитає і зрозуміє.
Якщо ШІ генерує «простирадла» води та зайвих залежностей, ніхто не буде читати їх уважно — їх просто швидко проскролять і змержать. Ліди, які встановлюють суворі стандарти щодо лаконічності та читабельності ШІ-коду, помітять, що якість рев’ю покращиться по всьому проєкту. Важливо звернути увагу на застосунки, які дозволяють цей процес контролювати.
Замість висновків. Нова еволюція ролі інженера
Що потужнішими стають ШІ-агенти, то вищою є ціна інженерної дисципліни. Ці інструменти здатні блискавично генерувати код, перебирати архітектурні варіанти та створювати дуже переконливу ілюзію власної компетентності. І ця ілюзія настільки ж корисна, наскільки й небезпечна. Створення надійних і стійких систем досі тримається на фундаментальних речах: особистій відповідальності, глибокому розумінні, якісному код-рев’ю та здоровому глузді розробника.
Нехай код пише агент. Але володіти системою має команда. Ті техліди, які усвідомлять цю різницю і перебудують процеси вже зараз, поки ШІ ще не став повністю автономним, — це саме ті люди, чий проєкт не перетвориться на непідтримуваний хаос, коли настане епоха повної автоматизації.
А як у ваших командах зараз відбувається рев’ю пул-реквестів, де частку коду згенерував Copilot чи Cursor? Чи відчуваєте ви «ефект GPS» на собі? Діліться думками в коментарях або можете заповнити невеличкий анонімний опитник, який я розробив чисто з цікавості до цієї теми.
38 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів«Ефект GPS» стає руйнівним не тоді, коли ви користуєтесь автоматизацією, а тоді, коли агент визначає маршрут, а ви перетворюєтесь на пасажира на задньому сидінні. У такій моделі ризик втрати розуміння системи справді неминучий.
Але якщо маршрут визначаєте ви, а агент бере на себе виконання всередині заданих вами меж — специфікацій, контрактів, інваріантів, автотестів та архітектурних правил — ситуація кардинально інша.
Тоді «ефект GPS» не атрофує мислення. Навпаки, автоматизація знімає низькорівневу рутину і дозволяє інженеру фокусуватися на тому, що складніше делегувати: системній архітектурі, межах модулів, бізнес-домені, надійності та поведінці системи під навантаженням.
Більше того, досвід роботи з агентами формує нову інтуїцію: ти починаєш заздалегідь бачити сліпі зони моделей, точки накопичення ентропії та маркери того, що система відхиляється від курсу.
Тому ключова компетенція сучасної розробки — не витрачати години на ручне вичитування та рефакторинг кожного рядка за агентом, а вміти спроектувати середовище, в якому автономний агент може рухатися швидко, але не може непомітно виїхати за встановлені межі.
Ну... По-перше, часто системою не володії ніхто, люди можуть звільнятися. Тобто це не новина. По-друге, не визначено що означає «володіння системою». Там намішано (1) розуміти кожен рядок; (2) розуміти арзітектуру та інваріанти; (3) бути відповідальним за результат. Пункт (3) це про організацію. Якщо брати пункт (1), то головне заувеження що це в принципі неможливо, людяний фактор. Так просто натистуни «згоден» ніж розбиратися, коли у тебе дедлайн. В авіації це називається самозаспокоєння від автоматизації, коли людина-наглядач за втоматикою перестає реально перевіряти і просто схвалює.
Лишається лише (2) розуміти арзітектуру та інваріанти. Але тут знову є дрейф, коли ти думаєш, що воно реалізовано по одному, а насправді...
Напевно вихід це скоріше вимагати щоб інваріанти перевіряла сама система, а не людська пильність: тести на архітектуру, контракти, кілька різних незалежних шарів, як дірки в швейцарському сирі, що не збігаються. Тоді дрейф ловиться механічно, і не важливо, чи залишився хтось у команді, хто пам’ятає, як воно мало бути.
Мало що таке ж нудне в житті як код ревью того що згерив аі, десь на рівні споглядання дефрагментації диску чи як сохне фарба.
Таким техлідам і до цього прилітало, що вони сповільнюють розробку «процесами»
Не знаю, що це мають бути за титани, які організовують все по-правильному при нинішніх завищених очікуваннях від технологій ((
юзера не цікавить який там код під капотом і скільки на нього часу та сил витратили
Юзера не цікавить, згоден
А замовнику може бути цікаво, чому нова функціональність додається тижні замість годин (бо хтось там шось колись накодив і агенти чомусь не допомагають це розгрібати). Або що юзер пішов до конкурентів, бо через погану якість коду продукт став працювати гірше (зате релізи частіше і суфікс AI в назві)...
І якщо раніше це було очікувано, то зараз популярна думка, що варто докинути токенів і воно якось само зробиться. Не зробиться
PS Гівнокодили і робили посередні продукти завжди, але LLM дозволяє робити це в рази швидше!
Не завжди — бувають випадки, коли розробники заявляють, що користувач неправий — на прикладі «Сталкера»: там спільнота виправляє те, що налажали розробники гри... На жаль, розробники гри мовчать... навряд чи така зневага дає позитивний результат.
Можна було б у коді динамічно при запуску підібрати потрібну функцію — яка емулює некритичну інструкцію? Тим більше, до оновлення гра працювала!
поозвольтє!1
а як же «всіх замінемо» ?7
паадаждіте... сєкундочку. Отут цікавий момент.
Давайте поговоримо про слопіфікацію продукту.
Не тільки коду, а й продукту, в комплексі з вимогами та юзер експірієнсом.
В мене є такі приклади, але без ШІ, можу описати, якщо цікаво. Чим то закінчилось можете здогадатися з одного разу.
А у вас таке вже було?
-0- будь ласка, не пишіть експертних висновків без конкретних прикладів.
-1- краще розкажіть про свій кейс слопіфікації продукту, якщо маєте. Без деталей, але цікаві нюанси: який бізнес-домен, ціна питання.
Ну, стикався з тим, що вимоги ̶"̶п̶о̶к̶о̶л̶о̶д̶н̶и̶к̶ ̶в̶р̶о̶в̶є̶н̶ь̶ ̶в̶и̶п̶і̶р̶а̶т̶ь̶«̶ «to draw seven red lines, some with green ink, some with red ink, and some transparent, all strictly perpendicular to each other» замість манагерів тепер пишуть агенти ))
А слопіфікований UX вже навкруги. Для корпоративних клієнтів просто проведуть черговий тренінг «як користуватись ̶ц̶і̶є̶ю̶ ̶д̶і̶к̶у̶х̶о̶ю̶ нашим новим продуктом» і все ОК. Решта ж безальтернативно страждатиме, бо слоп став частиною конкурентної гонки (без надії сподіваюсь, що це якось зміниться)
Прикольно.
Кривий UX це капець.
Прикладом є Скайп\Тімз, які M$ спочатку вивів в два паралельні аналогічні продукти зі спільною базою юзерів, для чого системно-довго підрізАв функціонал Скайпа, зводячи його на рівень Тімз.
А потім відключив фронтенд Скайпа, залишивши можливість логінитись в Тімз зі свого акаунту Скайп, воно й зараз можна. Але є нюанс :)
Це доводить, що провести слопіфікацію продукту можливо і без ШІ, який є лише інструментом. Таке сталося з одним з продуктів, який я недовго посапортив. Він просто здох, а я ледь встиг розібратися, і в них закічились гроші. Продукт старий, технологічний, не балалайка якась. Зараз мені зрозуміло, що грошей в них було обмаль ще коли мене наймали — там були нюанси в контракті, які вони потім використали, щоб платити по мінімуму.
Ну от ці капіталістичні гонки за кількістю продажів і швидкістю випуску продукту наближаються до комуністичного «сєгодня в маслє потрєбності нєт»
PS Мені здається, що топікстартер якраз хоче показати, що LLM якщо не зайва надбудова, то вже точно не заміна інженерам і продукт овнерам )) На жаль організаційні рішення не завжди приймають такі мудрі люди, як він
не вижу тут противоречия, если честно
та самая «инжереная дисциплина» — это во многом антипаттерн и промежуточный этап, пока команды не пришли более зрелому техническому процессу
собственно так вроде всегда и было — незаменимым стать гораздо проще в дремучем неподдерживаемом легаси и кучей того-самого дисциплинного оверхеда.
нравится нам это или нет, но та же инженерная культура — это в каком-то смысле и про потенциальную заменяемость людей за счет снижения этого оверхеда
Ревювити стало складно. Коду багато, PRи важко зробити малими. Зробив тулзовіну яка допомагає створювати контракти/харнеси, і підсвічувати зміни дизайну при ревю коду. Кому цікаво може глянути — github.com/vitalik1921/cage
дурна робота. краще витратити час на те, щоб перевірити чи фіча працює чи ні
Описана система розробки ПЗ склалася на базі поточних цін на токени, які навіть близько не покривають витрат. Загалом, ШІ провайдери зараз генерують фінансовий збиток, якщо брати не окремі прибуткові ланки, а повний цикл роботи «голандського штурвалу».
x.com/...tatus/2104805144546140476
Питання: як зміниться існуючий ландшафт розробки ПО, якщо ціни на токени зростуть в3-4 рази?
Напевно ціна продукту складатиметеся в залежності від складових.
В програмуванні зовсім інша критична точка пройдена — довіра, що рішення на базі згенерованого коду (можливо далеко і не найкращий як то написали би руками) але вже достатньо надійні у відповідних застосуваннях. На тому крапка, і скрізь де можливо програмери будуть замінятися машинними рішеннями, а вивільнені ресурси перенаправлятися в тестери, менеджери, і т.д., або в інші галузі.
Це якщо в масах дивитися, якщо не так загально — то звичайно що програмери залишаться (бо знайдуться напрямки у програмуванні де така точка ще не пройдена, принаймні явно, та може й зовсім до того не дійдуть з тим що не так легко дається по причині недоцільності вкладатися в то). Залишаться (imho) в основному в тих піднапрямках де є більш невизначеності чи не настільки все формалізовано — і тому доволі великий внесок має досвід та експертна оцінка на базі того досвіду, але в такій кількості як у часи gold rush програмування коли брали всіх і вся — явно не буде.
В інших галузях (не айті) можливо трансформації також близько чи починаються, але відповідна точка чи біфуркації чи порогу там ще схоже не пройдені, а пройтися спочатку по програмуванню вийшло напевно зручніше-доцільніше-легше по букету різних причин.
.
— То ти тепер будеш менше пити?
— Ні, це ви будете менше їсти!
не будет никаких3-4 раза. продажа токенов уже обученной модели сама по себе маржинальна: обучение оплачено, дальше продаётся инференс. новые фронтирные модели появятся (причем, их обучают не с нуля, а на основе уже обученных), да, будут дороже, но старые никуда не денутся — а для большинства задач разработки их уже хватает с запасом. так что ландшафт разработки ПО уже изменился безвозвратно.
ты почему-то не учитываешь что технологии будут развиваться дальше, а старые модели о них знать не будут => процесс обучения моделей нельзя остановить и просто подзаработать на том что готово. к тому же, конкуренты только и ждут чтобы другие остановились чтобы монополизировать рынок потому что они не остановились и их модель теперь лучше
во сколько раз вырастет цена сложно сказать, особенно учитывая что деньги обесцениваются, но определенно точно она будет продолжать расти
я даю модели набор markdown-файликов с описанием новой библиотеки и она начинает мне писать код с использованием этой библиотеки. современные модели так умеют. для прикладных задач разработки ПО этого достаточно.
для разработки новых белков или чипов пусть обучают/дообучают новые модели, а корпорации потом покупают их инференс. а существующие модели в Typescript или Питон умееют уже достаточно хорошо. мы здесь именно об этом.
это очень близоруко, пройдет год-два-три и модель очень сильно отстанет. а любой серьезный технологический сдвиг и ей сразу конец. даже если предположить что так будет можно (хотя из-за конкурентов невозможно), то как быть со штатом сотрудников? нанимать их обучить модель заново раз в 5 лет, а потом выбрасывать? то что ты пишешь возможно только на ультра короткой дистанции и по факту это сейчас и есть — до выхода новой версии
кто из провайдеров ллм остановится, тот навсегда выйдет из гонки
от, не факт, що архітектура трансформера є фіналом розвитку DL,
а ну, як хтось зробить проривне відкриття, і почне масштабуватись в тому напрямку?
Наприклад, у квантових комп’ютерів може бути потенціал в цій справі.
Зупинити поточне масштабування — ця думка вже лунає, наприклад, «OpenAI призупинила навчання новітніх моделей ai через непередбачувану поведінку ШІ-агентів» Вони, можливо, кажуть неправду ЧОМУ це відбувається.
Версії є різні, наприклад, в них нема стільки грошей, щоб підтримувати цей темп.
чтобы это открытие произошло им кто-то должен начать заниматься. Если предположить что оно произойдет, то все что сейчас связано с ллм загнется, просто появился новая компания, у которой потолок не достигнут как у нынешних провайдеров ллм
Будь ласка, можете повідомити габарити (L-W-H) тумбочки, з якої будуть братися трільйони на продовження фестивалю?
щоб продавати токени, їх треба десь брати, і на це вже витрачені трільйони доларів, а прибуток системи неспівставно менший — вона генерує астрономічні збитки.3-5, і його вже треба апгрейдити, за новими цінами, підводити більш потужне живлення, замінювати комунікації живлення та охолодження на більш потужні- це десятки мільярдів, які будуть брати НЕ з рентабельності бізнесу, а ходити-нити-обіцяти-погрожувати.
Крім навчання ллм, є ще купа витрат: електрика, обслуговування, амортизація обладнання. Вибачте, що гружу вас нецікавими деталями, але тільки обладнання коштує трільйон доларів, служити воно буде років
люблю экспертов с ДОУ, который цифрами меньше триллиона в своей аналитике не оперируют.
смотри, поясняю на пальцах: представь себе завод, который построили под выпуск 10 млн машин в год, но сейчас он выпускает только 100 тыс. каждая машина сама по себе прибыльна, но владелец завода в минусе, потому что завод построить дорого. но спрос на машины есть и растет стремительно, так что с ростом выпуска и завод окупится.
вот лабы так и живут — у них та же экономика масштаба. Антропики называли инвестором маржу на инференсе выше 80% (до расходов на обучение и доли партнёров), у OpenAl на платных продуктах — около 70%. эти цифры в сентябре публиковались, погугли сам.
так что все выравняется, пользовательская база растет стремительно, за те же деньги мы получаем в разы больше, чем было год назад. джинна в бутылку уже не затолкаешь обратно. но скептики, конечно, могут продолжать дрочить литкод, в ожидании, когда их позовут обратно на работу писать код руцями, как отцы наши делали.
просто поцікавтесь цифрами в інтернеті або подивіться в моїх коментах, я там все з пруфами постив.
На метафоричному рівні дискусія не дасть результату. Є у вас якісь аргументи по моєму питанню?
это не пруф, это нонейм.
www.investing.com/...uarter-ft-reports-4898761
по этому вопросу?
ви цікавились що таке «operating income» ?
він враховує ROI ?
він просто процитував звіт Антропік, який ви можете й самостійно знайти
розберіться в питанні, перш ніж розповідати про халявний інференс
я и написал, что 80% — это по сути маржинальность инференса без учета затрат на обучение (постройку завода).
один нонейм критикует инвестиционные перспективы антропика, другой нонейм ждет, что цена на токены вырастет в3-4 раза и все снова будут кодить ручками. сорри, мне неинтересно продолжать. у нас свободная страна, ты имеешь право на свое мнение.
ну приклад з автозаводом у вас такий собі :)) Саме через падiння попиту Volkswagen заявив про закриття декількох заводів нещодавно, а це холдинг який працює вже не один десяток років, і завжди ± був прибутковий.
Думаю саме до цих очікувань апелюють більшість людей які говорять про те, що бізнес то збитковий, і на даний момент все росте тільки на очікуванні високого попиту, і щоб всі платили звичайно.
Тим більше, що суми інвестицій обчислюються в сотнях мільярдів вже. Ну і у будь-якій інвестії має бути адекватний час щоб відбитися, і тут виникає головне питання у «скептиків» — і який це період?
господи, ну ок, не автозавод, а завод по производству айфонов. суть же не в автомобилях, а в принципе экономики предприятия. как ты программистом работаешь, если так плохо с абстрактным мышлением?
огромный спрос УЖЕ есть. для задач software development достаточно моделей уровня полгода назад. современные модели и их развитие нацелены уже на другие отрасли, их тренируют на способность длительной автономной работы, сложность задач, эффективность использования инструментов, точность рассуждений и тд. а knowledge cutoff уже все меньше играет роль.
а зачем ты приводишь аналогии, которые не подкрепляют то что ты говоришь, а наоборот опровергают? электростанция твоя аналогия, только она точно нужна и точно окупится и клиентов становится только больше, а не «электричество заменит людей» и тем самым срежет спрос на себя
электростанция корректная аналогия для экономики инференса, но если мы говорим об экономике всей деятельности лабы (а говорили именно об этом), то аналогия с автозаводом более уместна. ты подменяешь тезис.3-4 раза и дешевле работать как раньше». Как раньше уже не буде.
я не считаю кардинально, что «заменит людей», но то, что AI повысит производительность в одних профессиях и практически убьет другие — факт.
если вновь вернуться к тому, что я изначально комментировал, то software development уже не вернется к прежнему, потому что «токены стали дороже в
тогда нет аналогии
это еще один дестабилизирующий фактор для ллм провайдеров — разрушение ожиданий
не вернется, как и до ллм, никогда ничего не возвращается, в будущем будет не так как в прошлом. это не аргумент в пользу ллм, потому что оно тоже станет прошлым и к нему тоже не вернутся
воно десь так було в2000-му.
Краш доткомів був гучним, але інтернет нікуди не подівся, кабеля, сервери залишились.
Тільки гроші випарувались тоді у гравців. Таке відбувається регулярно, бо якщо гроші виникають з повітря, то вони повинні в ньому-ж і розчинятися.
для дефтек розробки недостаньо