Чому я майже перестав використовувати ШІ

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Мене звати Олександр, я в розробці більше 20 років. Я із «старої школи», але не луддит і не людина яка принципово проти нових інструментів. Я просто помітив що стаю гіршим спеціалістом саме через ШІ. І я зупинився.

Той тиждень

Кілька місяців тому я вивчав нову для себе річ. Не суть важливо що саме, важливо що я спробував зробити це через ШІ — питав, отримував відповіді, пробував те що він пропонує.

І ось ця петля: я кажу «я не спеціаліст в цьому, але мені здається що те як ти пропонуєш це зробити, якось надто тупо, не може бути щоб спеціалісти справді робили це саме так. Ця задача має бути типовою для сфери, не могли ж вони за стільки років, не придумати нічого кращого» — ШІ відповідає «так, твоя інтуїція абсолютно правильна, зазвичай роблять інакше...», «а якого тоді ти...», «вибачте, раніше я припустився помилки...» — і так по колу. Кожні день-два я викидував усе на смітник і починав заново, бо виявляється «так, ти абсолютно правий, робити так у 2026 нонсенс!», чи щось подібне.

І так трохи більше тижня — в смітник.

Потім я відкрив документацію. Просто доку, як робив це більше десятка років до ери ШІ. За два дні все стало на місця. І я відчув те що не відчував давно — той кайф коли щось нарешті розумієш. Не «ШІ пояснив(написав за тебе)», а саме зрозумів сам. Як новачок який вперше побачив що код працює.

Виявляється я скучив за цим відчуттям. І водночас наситився безглуздим базіканням із ШІ. А головне — це було просто ефективніше. Я більше не бачу сенсу відкривати Claude, купувати підписку чи щось подібне для таких задач. Навіщо? Щоб самоствердитись? Дякую, за декілька років існування сучасних ШІ — я вже цим наситився.

ШІ погоджується з тобою, ШІ ігнорує тебе

Архітектурна особливість. Великі мовні моделі не перевіряють істинність. Вони не запускають код. Модель просто шукає серед того, що було в датасетах.

А датасети зібрані з Stack Overflow, Reddit, репозиторіїв GitHub. Вони не передбачають відповіді «я не знаю». Якщо ти не знаєш відповідь на питання, на Stack Overflow — ти просто нічого не пишеш. ШІ цього не розуміє. У ШІ немає такого досвіду.

У моєму випадку я питав «що використати для...», а ШІ часто рекомендував застаріле — бо старих текстів просто більше. Рекомендував неіснуючі речі — або хапав щось з інших контекстів, або описував щось з інших версій. І робив це впевнено та переконливо — бо люди в коментарях Stack Overflow постійно сруться й самостверджуються, майже ніколи не визнаючи що були неправі, навіть коли для спеціаліста очевидно неправі. Саме на цьому і навчалась модель.

Отупіння

Для людини з 20 роками досвіду, «отупіння» це не абстрактна проблема.

Досвід це не знання. Знань у мідла, для конкретної задачі, може бути більше. Досвід, це коли ти дивишся на задачу і вже знаєш де буде боляче, ще до того як написав перший рядок. Це коли замовник каже що хоче одне, а ти чуєш що він просить і розумієш чим це закінчиться. Ти попереджаєш спокійно, один раз. Далі це їхні гроші і їхній вибір. Але вони запам’ятали що ти був правий. Наступного разу питають самі й зберігають гроші та репутацію.

Це і є те за що платять не як виконавцю, а як людині якій довіряють рішення. І саме цю якість я відчував що втрачаю.

В embedded і hardware особливо боляче

Я працюю в тому числі із мікроконтролерами. Тут ШІ не просто марний — він активно шкідливий.

У тренувальній вибірці застарілого коду фізично більше, ніж актуальної документації до свіжих SDK. А про нові чипи й архітектури я взагалі мовчу. ШІ статистично обирає те що зустрічав частіше. Класика коли отримуєш відповідь яка виглядає правильно, але є рішенням десятирічної давнини. А дискретні деталі він взагалі інколи часів советів рекомендує, бо діди на форумах про них колись писали. Європейскі чи американські чипи — теж дуже слабо, він не може відкрити каталог і налаштувати фільтри. Не слідкує за прес-релізами виробників. Він переважно знає лише про китайшину штибу TP4056, яку масово згадують на формуах. Про серію BQ наприклад теж знає, але це прямо треба запитувати. А щоб запитувати — треба вже знати про що питати.

Правильне питання, вже має половину відповіді. Ця істина ще більш актуальна для ШІ.

А ще ШІ не знає залізо, ні таймінги, ні обмеження по пам’яті й купу всього іншого не знає. Він часто пише синтаксично правильний код, який робить важкі операції там де їм не місце. Код скомпілюється — але краще б не компілювався. А ще він галюцинує неіснуючими регістрами, неправильними розпіновками, некоректними послідовностями ініціалізацій, і робить це капець як впевнено. А в реальності навіть між двома варіантами одного чипа — регістри можуть відрізнятись. Проте модель цього не знає.

А ще є блогери-діайвайщики — то окрема історія. Ще один капець. Embedded це непросто, але багато блогерів свідомо роблять вибір на користь простого контенту, замість правильного. Дилетанти пишуть для дилетантів, а реальні технічні статті — то надто складно, забагато букв і забагато інформації на букву. Класичний приклад знайомий багатьом: функція delay() в Arduino. Блокуюча операція. Думаю програмістам не треба пояснювати проблему яка тут виникає. Для будь-чого реального, за межами блимання світлодіодом і хоч трохи складного — непередбачена блокуюча операція це катастрофа. Це знає кожен досвідчений розробник, про це написано в офіційній документації Arduino, про це сваряться на форумах роками. Але туторіалів з delay() в інтернеті мільйони — бо так простіше розказати як блимати світлодіодом. І саме на цих туторіалах переважно навчався ШІ. Тому він і пропонує delay() — впевнено, з поясненням, як «досвідчений фахівець».

А найкращі практики embedded живуть у приватних репозиторіях, окремих профільних статтях і статтях від виробників. Їх одиниці. А ШІ переважно навчався на туторіалах від тих хто пише просто, замість того щоб писати правильно і перших спробах новачків, які на цих туторіалах виросли.

В геймдеві теж чув — дуже боляче, бо інет засраний туторіалами «як зробити гру, за пів години».

Проблема перевірки

Навіть коли ШІ правий, ти не можеш цього знати без перевірки. А перевірка в нетривіальних задачах може коштувати в рази більше зусиль, ніж коштувало б зробити самому. Ти витрачаєш час не на роботу, а на те щоб переконатись що робота зроблена правильно кимось іншим.

І навіть у шаблонних задачах, скопіювати код з аналогічного проєкту — особливої перевірки не потребує. ШІ-генерація потребує завжди. Інструмент додає крок якого раніше не існувало.

Інструмент який мав «замінити» людину, потребує додатковий, складніший етап з людиною.

А для складних задач, як рефакторинг великої кодової бази — ШІ бачить функцію, але не бачить чому вона написана саме так. Він «покращить» але зламає неписаний, але очевидний живому програмісту з досвідом конекст, підвищить ціну подальших доопрацювань. Через технічний борг виникший по причині правок роботи ШІ — уже збанкрутувала не одна компанія. Десь читав навіть звіт про рекомендації компаніям на 2026 рік, із значним впроважденям ШІ — банкрутувати продукт, поки є що банкрутувати.

А хтось довіряє ШІ навіть вести бухгалтерію...

Що я залишив

Я не відмовився від ШІ повністю. Але сильно звузив.

Як пошукова система. Як перекладач де можна додатково вказати контекст. Для роботи з чернетками текстів — це його рідна стихія, але не написання з нуля і не фінальні версії, скоріше для структування сирих думок. Як співрозмовник, але в дуже специфічному сенсі. Я не вірю тому що він каже, це більше схоже на rubber duck debugging — ти не слухаєш качечку, ти думаєш вголос поруч з нею і сам приходиш до відповіді. Я просто ігнорую більшість того що пише ШІ і продовжую говорити щось своє, розмірковуючи.

І здається все, мабуть більше нічого. Якщо щось і забув, то напевно якусь дрібницю.

А для всього де потрібне розуміння — тільки написане або принаймні перевірене людьми.

👍ПодобаєтьсяСподобалось42
До обраногоВ обраному8
LinkedIn

Найкращі коментарі пропустити

Згадав тут, як в 90-ті сцяли кіпятком від того, що на Делфі можна віконечко швидко накидать і клієнту впарить. Говорили про революцію в розробці, RAD і всяке таке. Правда, потім виявилось, що для того, щоб накидать якісну форму на Делфі потрібно багато мороки, а Button1Click розробка не сприяє якості і ясності продукту.

тоже 20+ лет в разработке (из них 10+ лет embedded).
с выводами скорее не согласен. надо просто понимать ограничения технологии и просчитывать, что можно делегировать и выиграть в итоге по времени, а что будет пустой тратой сил и токенов. всегда есть куча рутины, с которой агенты вполне себе справляются.
например, это мега тул по рефакторингу и относительно дешевому анализу по его целесообразности. это мега тул по анализу работы той или иной части кода. зачастую это довольно эффективная хрень по заполнению уже готовых API. это не лишняя штука в плане code review.

Завжди була мрія щоб син був програмістом і де-факто він в 15 років вже їм став (участь в опенсорс-розробці і т.д.), але коли я бачу нову статтю про те, як хтось за 2 години навайбкодив щось і цим пишається на стільки, що забацав статтю (яку теж писав чат) — опускаються руки... Це знецінення професії до нуля. Але я розумію, що це мої «дєдушкіни брєдні» і молоде покоління вже якось розрулить цю хрінь. Просто потрібно виживати в новій реальності.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Зробив відкриття: якби ЛЛМ моделі бачили якимось чином, що я змінив у коді, написаному їми для мене, і нізащо, ні в якому разі, ні при яких умовах не торкалися зроблених мною змін — це б мені з_економило тотальну кількість годин праці.
Мабуть і вам теж.
Давайте створимо петицію про це, підпишемо всім ДОУ і відправимо всім гігантам індустрії?

Тут ось людина писала, що Claude (через браузер) а також Claude CLI (Terminal) вміє акуратно змінювати код.

Claude має одну властивість, яку я ціную більше за все: він змінює рівно те, що ти просив. Якщо я кажу «виправ цю функцію», він виправляє цю функцію. Не «а ще я оптимізував ось тут і тут і вирішив видалити тут».

dou.ua/forums/topic/59476

P.S. Він використовував платну підписку Claude Pro. Не знаю, чи можна використовувати CLI безкоштовно.
P.P.S. Ще, у коментарях, там радять спробувати Kiro CLI.

Я уже відписував іншим, що як виявилось, всі говорять про ШІ, але всі говорять про дуже різний ШІ, тому і враженя/цінності інші. А так — можна таке зробити саме собою. Мова звісно йтиме не про реальну заборону, як думає більшість хто не усвідомлює як працює ШІ, а про вірогідність що він це зробить. Але загалом це працює добре.

я со «старой школы» тоже, еще в в досе на турбо с++ юзал и обработчики прерываний для разных чипов писал. ИИ дичь для конкретных задач критичных к реалтайму типа ембед или ядра ОС, его задача быстро решать бизнес кейсы, потому что бизнес согласен платить бабло чтоб быстрее расти. В разработку LLM инвестируются огромные деньги, скоро Антропик выйдет на IPO, акции взлетят и имеет шанс попасть в S&P 500
Эта хрень обучается на большом массиве данных и ее просто нужно заставить правильно работать. У меня куча успешных кейсов где LLM генерировала правильные пайплайны CI, фиксили рутинные километры юнит тестов и прочее, что избавило меня от копания в тоннах доков.
Когда вижу что код дерьмо и выглядит как типичный нерефакторенный слоп, я заставляю переделывать это спагетти на код ревью

Допис виглядає поверхневим. Складається враження, що автор не до кінця розібрався із практичним призначенням ШІ або просто не мав доступу до якісних моделей для вирішення реальних завдань.

Наведу простий приклад: мені потрібно було провести аудит понад 300 репозиторіїв у Bitbucket для одного з проєктів. Завдання включало збір статистики: кількість комітів по роках, дата останньої активності, розподіл файлів за типами, обсяг коду (LOC), стек технологій тощо.

За допомогою ШІ я створив рішення за кілька кроків. Написав промпти для генерації шел-скрипта, який через Bitbucket API викачував репозиторії та запускав необхідні парсери для аналізу. ШІ сам підібрав оптимальні інструменти та бібліотеки, які вже були в системі. На все пішло близько 2 годин замість запланованих 3–5 днів.

Результат: виявив 150 абсолютно «мертвих» репозиторіїв, а сам скрипт тепер використаємо на інші проєкти, та забудемо про нього. Ось так ШІ працює як прикладний інструмент для автоматизації.

Як тільки ви намагаєтеся змусити ШІ повністю замінити себе — це гарантований провал. В IT реальний профіт від нейромереж з’являється лише тоді, коли їх використовують як інструмент автоматизації рутини. Це єдиний збалансований підхід, який дає результат.

Зараз навколо цього забагато хайпу. Спочатку всі кричали про те, який ШІ крутий і революційний, а зараз перекинулися на інший бік — розказують, який він поганий. Обидва підходи відірвані від реальності.

не мав доступу до якісних моделей для вирішення реальних завдань.

Какие качественные модели если самое крутое, чем пользовался автор, это

Базова підписка коштує всього 20 доларів.

:-)

на основі коментарів я зрозумів доволі просту річ — хоча ми всі говоримо про ші, ми говоримо про дуже різний ші, з різних кейсів. І мова не тільки про домен задач. Ви праві, але і багато з тих хто посперечався б — теж праві. Просто мова йде про різні кейси.

LLM модельки для мене цікаві як співрозмовники у яких на все своя точка зору, яка здебільшого збігається із загальновикористовуваною.
Що до написання коду, то може простіше його вирощувати?
Код це ж інформаційний кристал. Простежте процес кристалізації, зрозумійте як створювати умови для вирощування потрібних форм і все. Поміщуєте зародок у пітательную срєду і воно саме утворить всі необхідні зв’язки і стане повноцінною річчю у самій собі.
Напростіший приклад: додали нову властивість об’єкту, необхідно додати сетер і гетер. Це автоматичне рішення, яке виходить з зародка «нова властивість» тобто це ріст, тобто це процесс формоутворення, тобто це про крісталізацію.

Є такий вираз — всі аналогії брешуть.

Класичний приклад знайомий багатьом: функція delay() в Arduino. Блокуюча операція.

Да, есть такая проблема. Например, в UI тестах он тоже любит лепить sleep (500).
Лечится скиллами, в которых прописываешь примеры хорошего и плохого кода. Буквально: In case of <smth> DO <хороший код> and NEVER DO <плохой код>. Можно подолбаться самому, можно найти уже готовые примеры skills и адаптировать для себя.
Например, нашёл я отличный скилл для Playwright. Всё супер, одна проблема: написан на ts, я на на Java пишу ))
Окей. Натравил Claude на этот скилл, попросил переписать его же для Java. Просмотрел потом, чтоб не нафигачил антипаттерны в примеры хорошего кода. До кучи дописал «NEVER guess locators. ALWAYS run Playwright MCP when you need to fix the locators in the test». Ща юзаю — качество генерируемого кода улучшилось в разы. Если раньше приходилось по 2..3 раза просить исправить треш, сейчас в основном с 1-го раза пишет хорошие тесты.
Туда же: оч рекомендую добавить superpowers плагин. Из полезного там есть 2 штуки:
1. Нормальное планирование. Вместо того, чтоб нестись писать код, как только увидит 1-ю букву задачи, а потом писать «ой, что-то я не подумал» — агент составляет детальный план имплементации. Если ему что-то непонятно — спросит (иногда спрашивает прям много и реально полезные вещи, которые забываешь упомянуть в задаче).
2. Systematic-debugging. Офигенно полезный скилл. Заставляет агента делать root cause analysis вместо того, чтоб фиксить что в электронную голову взбредёт. И только после завершения анализа со всеми пруфами он идёт и фиксит.

Цілком згоден. Він не вміє писати добрий код. Використовувати його може лише фахівець — для того, щоб швидко отримати допомогу. Якщо працюєш з багатьма інструментами, можеш щось забути. Умовно: яка функція в PHP дозволить знайти у рядку символ, який порт відповідає за стан COM-порту тощо. А код треба писати лише самостійно. Тобто, для мене особисто, він — щось на зразок просунутого гугла. Чисто довідник.

Вони не запускають код

це буля цытата афтара. також щось про 2026 рік. також Клауде. Панове перевірте, може 2026р Клауде всежтаки запускає код.

а так — забагато букав

Мабуть і плати десь паралельно паяє...
Він може і код запустити, і ракетою керувати за наявності відповідного скіла. Не виривайте із контексту.

Ось про якого штибу «не запуск» йдеться у статті.
claude.ai/...​1c-41e1-8028-e5ea6e6ba196

Згоден, це повна херня. Коли ти сам пишеш код, і його пишуть люди, то ти потроху вивчаєш кодову базу і проект, як все працює, які звязки, і звідки «ростуть ноги» у випадку фейлу, теж знайти легше.
Але коли ти ревьюєш код, який написав АйЯй (на маркетологовському), ти теж щось таке запам’ятовуєш. Але потім ***к... і АйЯй перехуярив все, і все вже не так.
І ти сидиш і думаєш... «та їбись воно конем», тицяєш Approve і пішло воно все... на...

Надо сказать хоть LLM типа Opus особо не говорит «нет», но последние месяцы он часто стал задавать уточняющие вопросы пачками, и это путь в верном направлении.

а у меня наоборот перестал, это вероятно зависит от того как ты пишешь, если есть двусмысленности, то он и уточняет

ему нужно явно говорить опросить тебя. есть хороший скилл , рекомендую попробовать

спасибо, но у меня не тот случай где я могу применить этот скилл, если вкратце то, наверное, это можно описать как эксперименты в области маркетинга, в котором я, к слову, ничего не понимаю. поэтому уточняющие вопросы для меня скорее минус, потому что я не знаю ответов и когда это происходит мне приходится писать что-то вроде «я не знаю, делай чтобы было хорошо»

я вообще другой смысл в сообщение вкладывал: если писать не поток сознания от сердца, а структурировано с избытком инфы о важной для тебя части, то шанс на диалог будет низким и мне это нравится — ведь я и так описал важное с избытком, а то что не описал не имеет для меня никакого значения. для программирования по работе такие диалоги, скорее, желательны (если вообще не мастхев), но я писал совсем не об этом

то что не описал не имеет для меня никакого значения

Если там грабли не закопаны.
Тут недавно ИИ рекомендовал в хай лоаде перенаправлять аналитический трафик на OLTP базу, если OLAP база легла. Типа чтобы сохранить user experience.

використовую правило, яке забороняє ші генерувати код, не задавши уточнюючих питань і не узгодивши усі деталі

Чому я майже перестав використовувати ШІ

есть подозрение, что просто потому что можешь себе позволить
потому что твой перформанс не оценивается, потому что по какой-то причине не переживаешь про хендс-он опыт при смене работы

с таким же успехом кто-то раньше мог позволить себе не интересоваться всякими этими новомодными фреймворками или клаудами, а кто-то нет

и это так-то неплохо: в каком-то смысле я такому даже завидую

Завжди була мрія щоб син був програмістом і де-факто він в 15 років вже їм став (участь в опенсорс-розробці і т.д.), але коли я бачу нову статтю про те, як хтось за 2 години навайбкодив щось і цим пишається на стільки, що забацав статтю (яку теж писав чат) — опускаються руки... Це знецінення професії до нуля. Але я розумію, що це мої «дєдушкіни брєдні» і молоде покоління вже якось розрулить цю хрінь. Просто потрібно виживати в новій реальності.

Та не розрулить. Я викладаю як хобі, у десять років для них «погуглити» = «почитати що джеміні в шапці написав». На мою думку пройде сепарація на різні рівні згодом. Отримаємо високооплачуваних інженерів проти купи тих хто «тільки з ШІ». Це станеться не зараз, а станеться з тим самим часом, коли ШІ покоління почнуть шукати роботу.

Отримаємо високооплачуваних інженерів проти купи тих хто «тільки з ШІ».

Оплата набагато більше залежить від попит/пропозиція ніж від скілів людини.
Тому якщо буде «купа з АІ», то ЗП рости не буде.

На початку нульових $2к це була нереальна ЗП для програміста, хоча в Україні сейли і менеджери поза ІТ мали такі ЗП.

В 2020+ $2к це була нижня межа міда, хороші джуни стільки мали.
А 5+ років відсидіти на умовному епамі це означало мінімум 4к, тупо пиляючи круди і формочки в ангулярі)

Саме так. Все як ви і написали. Саме тому що одних буде дуже багато у порівнянні з іншими.

Так само в 90х батьки хотіли, щоб діти стали юристами чи міжнародниками

нууу.... так то воно так, але до появи чатів програмування давало 100% цікаву професію, умовно дофіга грошей та майже повну свободу пересування по світу. Зараз я бачу як все це знищується і звісно вже не впевнений в вірності вибору... але мій піздюк всім цим цікавиться і піде в забугорний універ на Computer Sience чи AI. А я буду мріяти про те, що «вайбкодери у чистому вигляді» вимруть і ринок всеж таки захоче тих, хто хоч трохи інженер. Але от прямо зараз виглядає так, шо інженерство до сраки, а вміння оркеструвати оці всі довбані чати — саме те шо треба :)
P.S. Cподіваюсь шо мій чат не прочитає цей мій висєр, бо потім скаже шоб я сам код писав якщо такий вумний...

Можна сподіватися, що високорівнева архітектура виживе. Я написав про неї оглядову книжку, але не знаю, як тепер це промотити.

У вас дуже приємний сайт, якщо є трафік то бахніть adsense.

Є десь до 5 кліків на день від гугла. Ще хтось, мабуть, заходить хто його раніше бачив.
А так — проблема, що на сайт майже ніхто не посилається, тому індексер вважає його неавторитетним, і показує в пошуку на 2-3 сторінці.

Я зайшов поклікав — дійно приємний. Але всеж нішевий.

але до появи чатів програмування давало 100% цікаву професію, умовно дофіга грошей та майже повну свободу пересування по світу.

А після появи ллм, що змінилось?
Цікаві задачі зникли? ЛЛМ норм справляється з типовими задачами, а не з цікавими
Грошей стало менше? Для людей, що вирішують цікаві задачі. Та навіть для тих хто робить сайти-візитівки наче ставка не впала.
Свободу пересування точно ллм забрали, а не економічна рецесія (+ у нас війна)?

Я мав на увазі те, що програмісти мають працювати з будь-якої точки земного шару, інші спеціальності в цьому обмежені.
P.S. Про ЛЛМ та ставки не буду сперечатись, бо щось мені підказує що ми будемо по кругу те саме повторювати))))

Я мав на увазі те, що програмісти мають працювати з будь-якої точки земного шару, інші спеціальності в цьому обмежені.

Але ж це знову не має відношення до ллм. Бектуофіс — це не про ШІ, а про те, що треба, щоб люди самі позвільнялись, бо роздутий хедкаунт з ковіду.

Після LLM треба починати реально приносити велює а не писати круди

Дивився вчора на ютюбі плач одного ІТшника, який рік роботу не може знайти. Чувак вчився на юриста, але роботу знайти не міг, нікому юристи більше не потрібні. Під час ковіда вирішив свічнутись в ІТ, пропрацював кілька років, АІ, layoff, рік ігнору.

Чувак стабільно запригує в поїзд, з якого спригують.

Ну я вже 3 роки без роботи, але не знаю, куди тепер запригувати)

нікому юристи більше не потрібні.

от взагалі нікому не потрібні, мертва професія — щось типа конюха ))

I щe економістами, куди ж без них. Такий шалений попит був на цю спеціальність, у різних варіаціях — міжнародна економіка, економіка підприємства, облік та аудит... кого не запитаю серед однолітків у ті роки — всі на економіці, і гордилися цим неймовірно.

Мисліть масштабніше. Уявіть СЕО, який роками будував стартап, збирав команду, пилив якийсь продукт. А якісь чуваки навайбкодили схожий чи навіть кращий продукт / сервіс, чи інший клас продуктів чи сервісів, переключаючи увагу потенційних клієнтів. Цими чуваками можете бути ви.

Проблема только в том что это сказка и так не бывает, бо продуктоцентричных компаний не существует или мы бы жили совсем в другом мире

а ще масштабніше — такі чуваки вже є і без вайбкодингу саме їх ви вже не вже

А якісь чуваки навайбкодили схожий чи навіть кращий продукт / сервіс

І потім вони зрозуміли що написати саас то лише найлегший єтап, далі починаються продажі, маркетинг, підтримка, скейлінг, китайскі хакери що криптують все що можна, найм людей(не обовязково айті), бухгалтерія, податки...Ти відкрий редіт і починай усих цих солопринерів.

далі починаються

т̶а̶к̶ ̶ц̶е̶ ̶і̶ ̶є̶ ̶у̶с̶п̶і̶х̶
стануть сіо або продадуть сіо

Та ніхто не купляє код, кому він нах впав? Це і до ші було так, куплють клієнтську базу, кеш флоу... навіть топові технології здебільшого заробляють не явно, а через цілодобову пітримку, ентерпрайзні фічі та інше.
Код купляють у галер, інвестори та фаундери, але не тому що в коді є цінність, а в тому що в них вже є бізнес ідея, котрма може стати цінніюсть при умові що її продадуть кінечним кастомерам, поєднають із командою, подружать з регуляціями та податками, трафіком...Тобто ані ідея, ані код самі по собі, чи вдвох разом, не мають цінності.

а те що

далі починаються

хіба можливе/потрібне без клієнтської бази?

Wiz → Google ($32B)
Scale AI ↔ Meta ($14.8B)
io → OpenAI ($6.5B)
Windsurf → OpenAI (~$3B)
Moveworks → ServiceNow ($2.85B)
Manus → Meta (>$2B)
Character.AI → Google (talent/licensing)
Inflection AI → Microsoft (talent/licensing)
Adept AI → Amazon (talent/licensing)
Seek AI → IBM

І це мільярдні покупки, і ті, яких купили. а скільки подібних сервісів, стартапів з мільйонними оборотами чи тих, кого не купили. Навіть антропік можна до цього типу стартпаів віднести, який у 2021 мав лише 7 чоловік, а зараз мало не найбільш перспективніша компанія яка має шанси обскакати по капіталізації і прибуткам біг тех.

З’явилося купа стартапів за останні кілька років які доросли до мільярдної капіталізації які прямо чи косвено пов’язані з АІ

Звісно створити != продати, ніхто і не обіцяв що продати легко. Но АІшка, якраз позволяє сфокусуватися на «продати» частину, взявши на себе «створити».

Зауважу, капіталізація != прибуток.

капіталізація == активи + IP + клієнтська база + майбутній прибуток

капіталізація ==

Можно сократить до простого — ожидаемая в данный момент прибыль в горизонте примерно 5 лет.

Можна й так. В принципі це про будь-яку інвестицію так можна сказати.

осталось дело за малым — втюхать кому-то слоп за несколько миллиардов 🤦‍♂️

Як це відміняє те що я написав, шо написати мвп легше ніж продати його? А те що є мвп не значить що є кліенти. Чи ти просто знову пхаєш «аі» «імейзінг» не читаючи куди та кому відповідаєш?

Ні, я просто написав що АІ позволяє швидше пилити проекти і створювати стартапи. Я не писав що всі ти проекти обов’язково злетять а стартап не закриється в перший рік. Це ти вже щось своє додумав, і почав сперечатися з тим, чого я не писав.

Буквально якщо вчора треба було потратити кілька місяців в гаражі щоб випустити якийсь нікому непотрібний туду ліст, то зараз за ці кілька місяців при правильному підході можна запилити сервіс який уронить акції якоїсь умовної фігми. Вчора би за такий сервіс навіть не взялися знаючи скільки там роботи. А зараз беруться.

АІ позволяє швидше пилити проекти і створювати стартапи

у тебя искаженное понимание как это работает, чтобы привлечь многомиллионные инвестиции не нужен жирный мвп. для этого нужно совсем другое — не техническое. до инвестиций зп разраба это подъемная сумма, после привлечения инвестиций зп разрабов это копейки, которые можно не считать

зараз за ці кілька місяців при правильному підході можна запилити сервіс який уронить акції якоїсь умовної фігми

нельзя, это миф. попробуй сам, если не веришь. точнее сервис запилить можно, но продать не выйдет и уронить акции фигмы. это основная проблема. нужен не продукт, а авторитет, если его нет, то ничего не будет, а если есть, то мвп можно чисто символический и все получится. увы и ах, но личные связи богачей > чем любые действия красноглазиков вроде нас с тобой

нафіга тобі інвестиції? інвестиції потрібні якщо цілишся на багатомільйонний ринок, чи якщо треба масштабувати бізнес.

А так, навайбкодив за пару тижнів, прикрутив якийсь страйп, який бере всі фін. транзакції на себе, закупив рекламу на 10к доларів — і вперед. Не взлетіло — пробуєш щось нове. Взлетіло — розвиваєш, допилюєш, будуєш команду, шукаєш інвесторів щоб масштабуватися х10, х100.

Раніше це було неможливо, треба були інвестиції щоб навіть mvp запилити. Або потратити самому місяці а не тижні. А зараз можливо. В цьому суть мого меседжа, а не те, що ви з ботом додумуєте.

І да, всякі фігми, адобе та інший SAAS напрялися, тому що у одного Васі із 100 вийде, і він взлетить. А АІшка сильно збільшила абсолютну кількість таких Василів, і відповідно потенційно успішних Василів також збільшилась, чисто статистично.

А так, навайбкодив за пару тижнів, прикрутив якийсь страйп, який бере всі фін. транзакції на себе, закупив рекламу на 10к доларів — і вперед. Не взлетіло — пробуєш щось нове

с таким подходом будешь всегда пробовать что-то новое, бо оно так не работает

Раніше це було неможливо, треба були інвестиції щоб навіть mvp запилити. Або потратити самому місяці а не тижні. А зараз можливо. В цьому суть мого меседжа, а не те, що ви з ботом додумуєте.

ничего не изменилось, продукт не первостепенный как и раньше

І да, всякі фігми, адобе та інший SAAS напрялися, тому що у одного Васі із 100 вийде, і він взлетить

не задвался вопросом почему этот Василий всегда оказывается не технарем, а очень непростым человеком с немалой известностью до стартапа?

А АІшка сильно збільшила абсолютну кількість таких Василів, і відповідно потенційно успішних Василів також збільшилась, чисто статистично.

ии ничего не поменял, как и раньше сделать продукт самое простое, я согласен что это стало быстрее, только когда он готов он все еще никому не нужен

Ну камон, половина стартапів так створювалась, 20-літнім ноунеймом. У 30-літнього сінйора з немалою фінансовою подушкою шансів куди більше. Чи ти за стартапи тільки рівня майкрософта / гугла визнаєш?

Так, звісно для успіху треба більше софт скіли, підвішений язик, мотивація, уява, ніж хард скіли. Ну так вот, АІшка ці хард скіли заміняє більше, ніж софт скіли. І у чувака, з гарними ідеями, у якого не було інвестицій і команди для mvp, з АІшкою у нього куди-більше простору для маневрів.

Ну камон, половина стартапів так створювалась, 20-літнім ноунеймом. У 30-літнього сінйора з немалою фінансовою подушкою шансів куди більше

это очень спорное заявление

Чи ти за стартапи тільки рівня майкрософта / гугла визнаєш?

ты же сам привел в пример стартапы, которые за миллиарды продались, зачем мне говорить за остальное тогда?

Ну так вот, АІшка ці хард скіли заміняє більше, ніж софт скіли

ну кому чего не хватает, ллм во всех сферах показывает стабильные 4/10

І у чувака, з гарними ідеями, у якого не було інвестицій і команди для mvp, з АІшкою у нього куди-більше простору для маневрів.

не будет, просто сократишь немного времени на мвп, но его и так не обязательно до ума доводить до получения инвестиций

Я 15 років будую свої маленькі продукти в соло-режимі (+ дружина контент). З однієї сторони чат почав допомогати мені, але я підозрюю що не дивлячись на взятку в 20 долярієв ця скотиняка допомогає не лише мені... Так що я звісно намагаюсь увести клієнтів у інших, але найбльш цінним було б не втратити своїх :)

коли я бачу нову статтю про те, як хтось за 2 години навайбкодив щось і цим пишається на стільки, що забацав статтю (яку теж писав чат) — опускаються руки...
Це знецінення професії до нуля.

Професії чи ремесла (крафт)?

Щодо знецінення професії не зрозуміло де ви його побачили. У вас як у професіонала з’явився ще один інструмент. Який ви можете застосовувати, щоб спростити собі рутинні завдання. А можете плакатись в інтернеті, що він не працює з коробки так як ви собі нафантазували (як це зробив ТС).

Раніше не було вайбкодерів. Але були вайтішники, що після 2 місяців курсів по фронтенду позорили професію та ремесло. До них були формошльопи, які знецінювали ремесло, бо не вміли в багатопотоковість та алгоритми.
А ще раніше дід Спольскі волав, що джава, а насправді навчання на джаві вбило справжніх інженерів, і відкрило в шлях в професію тим, кого відсіяли б на першому році навчання курси по сі та лісп.
Ремесло знецінюються постійно, бо знаходяться шляхи спрощення речей, які раніше було робити складно.

Щодо професії, то все ще не ясно як це її знецінює. ЗП не падають. Падає попит, але ж усі бачать, що ШІ тут лише ширма.

Я не встигаю за вашими доводами... Майже зі всіма не згоден, але це норм, в кожного своя реальність.

Як пошукова система. Як перекладач де можна додатково вказати контекст. Для роботи з чернетками текстів — це його рідна стихія, але не написання з нуля і не фінальні версії, скоріше для структування сирих думок. Як співрозмовник, але в дуже специфічному сенсі. Я не вірю тому що він каже, це більше схоже на rubber duck debugging — ти не слухаєш качечку, ти думаєш вголос поруч з нею і сам приходиш до відповіді. Я просто ігнорую більшість того що пише ШІ і продовжую говорити щось своє, розмірковуючи.

А от з цим мабуть плюсану.
Сам теж прийшов до такого, і кого не спитаю з колег, у всіх теж так

> він не може відкрити каталог і налаштувати фільтри

Також уточню, хоч і на етапі навчання він вчиться на всьому підряд. Але на етапі використання ви маєте можливість налаштувати контекст, включно з каталогом. І тоді вірогідність вдалої відповіді буде набагато краща

Мушу уточнити, що

1. Зараз LLMки вчать в тому числі запускаючи їх код. Тобто беруть задачку, LLMка генерує код, той код запускають, LLMка отримує результати. Зараз вчать не лише на stackoverflow і останні прям великі моделі (опус наприклад) генерують код набагато краще чим колись

2. Моделі постійно кажуть «так точно, я впевнений, жодних сумнівів», бо їхній датасет «отрують» умисно. Коли кілька років назад всі постійно сміялись як chatGpt постійно після «перевір себе» писав «ой, вибачте, помилився», то LLMкам для навчання спеціально почали згодовувати дуже дуже багато діалогів де відповідь «так, я впевнений». Тобто впевнений тон — це не завдяки навчанню на stack overflow, а завдяки свідомому отруюванню датасету самими ж творцями того датасету

1. Зараз LLMки вчать в тому числі запускаючи їх код. Тобто беруть задачку, LLMка генерує код, той код запускають, LLMка отримує результати. Зараз вчать не лише на stackoverflow і останні прям великі моделі (опус наприклад) генерують код набагато краще чим колись

такое чувство что слово «обучение» ты воспринимаешь буквально

Більш того, я практикую екзамени для них! ;)

1. Так, генерять код і потім їх же загоняють аргументувати код. Є сенс.
2. Усі ми з цим спіткалися. Як висновок, я підняв стару забуту тему про експертні системи і написав кілька статей про ці системи і доказовість рішень
dou.ua/forums/topic/59793
dou.ua/forums/topic/59861
і будуть ще, бо це проблема яку в нашому часі треба вирішувати

В статтях проблема в дуже великому об’ємі інформації без якогось очевидного узагальнення чи висновку. Зрештою, те ж можна вийняти з ЛЛМ, мабуть. Але ШІ ще й може порадити, який саме варіант використовувати в якому випадку.

Так, я згоден, великий вийшов об’єм, я намагався зменшити, але вийшло так. Можливо й тому, що коли тобі якась тема подобаєтсья, то хочеться багато що про це розповісти.
Кожна стаття має розділ «Висновок».
Можна вийняти з LLM, можна аналізувати наукові джерела. І за порадами звісно є сенс звертатися, і треба з цим експериментувати. А можна нічого не писати, не робити статей.

Можна писати, можна не писати. За власним досвідом — воно не допомагає кар’єрі, скоріше — навпаки.

От десь так як описано автором, використовую ШІ в наукових дослідженнях.

Від тебе не треба писати код. Від тебе потрібно розуміти і читати код, роблячи якісне ревью.

Це значно більше роботи, ніж писати код.

Чому я майже перестав використовувати ШІ

Бо в тебе нема грошей

треба вже знати про що питати.

ох ніфіга ж собі, шоб шось спитати в інформаційної системи, треба про це шось знати. А знаєш, що ще працює по такій схемі? Бібліотека б***ь, архів, там так само, щоб отримати потрібну тобі інформацію, треба знати про її існування, а в різних секретних бібліотеках, ти ще й допуски повинен мати.

А найкращі практики embedded живуть у приватних репозиторіях, окремих профільних статтях і статтях від виробників.

Всі практики в ембедеді гівно і костилі, бо без гівна і костилів ти цю срань не запустиш.

Я дуже здивований, що це має стільки лайків.

Тому що ти не єдиний хто страждає на емебедед. Тут коли хтось розказує про непрацюючий ШІ, то з високою долею вірогідності буде або ембедед, або С++, або прости господи, якийсь lisp.

Та ні, цеб я якраз зрозумів, мене здивувало що в заголовку людина пише «Бо в тебе немає грошей», і це підтримують. Ну це як мінімум... якась звехність, м’яко кажучи.

Яка зверхність? Щоб потужно і зручно вайбкодить, тобі треба гроші, багато грошей. Щоб написати компілятор С, який зміг зібрати ядро лінукса і нічого іншого, було витрачено 50 тисяч баксів на токени, всьо, сучасна айтішка доступна тільки тим, у кого є гроші, великі, і він готовий ці гроші спалити на сумнівний результат. А всім іншим вайбкод не доступний.

Я думав ви тролите, але тепер ще в більшому шоці що ви серйозні.
Базова підписка коштує всього 20 доларів.

за 20 доларів можна тільки лизнуть, так само, як і за 200. Норм вайбкод енжоєри, по 5000 місяць платять, щоб хоть якось між лімітами існувати. Ти готовий викидати 5000 баксів в місяць на вайбкод, заробляючи 3200? А без норм лімітів, щось велике написати неможливо.

Ви таки точно тролите, бо тоді повертаємось до питання — а нахіба воно з такими витратами? Подібні витрати, зав’язані на проєкт, якщо що взагалі від «багатства» не залежать, їх оплачує замовник.

Они не имеют смысла если человек фигнёй в АИшке мается, но если эти деньги потрачены на создание чего-то, что помогает в работе, то данная сумма оправдана.

Базова підписка коштує всього 20 доларів.

Именно это выражение выдаёт в тебе нуба, который ещё не освоил инструмент. Но уже пишет заметки, что инструмент не работает.

Ліспи досить непогано кладуться на використання з ШІ. Ну як мінімум racket/scheme і кложура.

Згадав тут, як в 90-ті сцяли кіпятком від того, що на Делфі можна віконечко швидко накидать і клієнту впарить. Говорили про революцію в розробці, RAD і всяке таке. Правда, потім виявилось, що для того, щоб накидать якісну форму на Делфі потрібно багато мороки, а Button1Click розробка не сприяє якості і ясності продукту.

Але, здається, код на делфі був більш передбачуваним (ніж навайбкожений), бо не існувало двох способів вставити кнопку ))

Якщо робити швидко, він був передбачувано-гівнявий. Щоб код був годним, потрібно було нешвидко.
Власне з ШІ так і зараз.

код на обжект паскалі був нормальний, в основному завдяки тому, що на паскалях навіть гівнокод читаємий. Всі приколи до делфі стосувались приколів в стилі Button21, то що всім було пофіг на неймінг, на структуру, на перемішування гуя і бізнес-логіки, кароч звичайний софт початку 21 століття, просто на делфі це робилося швидко і просто, а на плюсах той самий говнокод робився роками. Сішники кста на делфі і кидались гімном, вони на всіх кидаються, але тоді це був делфі, потім це були веб разраби, зараз це раст, хоча сішники його самі і зробили.

Якщо брати інструментальну складову, то я постійно мав проблеми з кодуваннями, відмінними від віндових, відображенням модифікованих данних, поплившим екраном на інших шрифтах/моніторах (в борлан не знали про менеджери геометрії) та VCS. Ну і те, що ви написали, причому це проблема, що породжена середовищем. Писати не гівнокод, звісно можна було і борланд щось намагався в цьому напрямку робити, але спокуса швидкого гівнокоду завжди перемагала.

спокуса швидкого гівнокоду завжди перемагала.

І буде далі перемагати, швидко і дешево, завжди краще за якісно, довго і дорого.

А потім проект валиться, бо підпорки перестають тримати побудоване на гнилій основі.

Як показує досвід, контора яка написала гівнософт валиться швидше, за цей самий гівнософт. На прикладі того ж делфі, різні скада системи досі працюють, а от компаній вендорів, що їх накалякали вже і в живих немає.

І таке є

Звісно болітиме, якщо витратити купу часу на вивчення плюсів, а потім виявиться, що можна писати на інших інструментах швидше, надійніше та простіше.

Правда, потім виявилось, що для того, щоб накидать якісну форму на Делфі потрібно багато мороки

, а накидать качественную форму без визуального редактора ещё больше мороки, поэтому с тех пор формы никто в текстовом редакторе не лепит :-)

Трохи більше мороки було на тіклі та похідних, зате gui не пливло на екрані, відмінному від екрану розробника. Концептуально тікль був найкращим способом робити gui з того, що я бачив. Трохи морочливішим за тікль був swing.
Ні на жабі, ні на тіклі не було дитячих проблем з кодуванням символів, базами данних чи з плаваючим гуйом

WxWidgets мав погану переносимість між лінуксами: потрібно було, щоб співпадали версії власне wx, GTK, на який він біндився та, в моєму випадку, wxPython. Тому я з ним тільки трохи почав гратися, воно у мене не запрацювало і нічого в прод я на ньому так і не зробив. От своєї думки і не маю.

Говорили про революцію в розробці, RAD і всяке таке.

Стоп, стоп, і що, цього не сталося? Те що сінйори на MFC/VCL і С++ builder робили тижнями, якийсь джун міг накидати на делфі за пару днів. Так, якість коду у джуна була так собі, но на MFC/VCL він взагалі нічого не зміг зробити.

Правда, потім виявилось, що для того, щоб накидать якісну форму на Делфі потрібно багато мороки, а Button1Click розробка не сприяє якості і ясності продукту.

І тим не менше, якісний продукт все-одно робився на порядок швидше ніж на С++ і MFC/VCL. І мороки там, на порядок менше, порівняно з MFC/VCL. З появою делфі, а потім .NET, MFC швидко вимер, залишився лише в легасі проектах які було дорого переписувати.

Були альтернативи у вигляді того ж тікля та джави. В моєму випадку, python+ біндінги на тікль дали прорив у розробці.
Python не провокував на гівнокод та дозволяв робити dsl під задачу, а тікль дозволяв просто генерувати гуі базуючись на dsl.
А бонусом було те, що все це працювало на linux, з якого я тягнув піUnix- way на вінду.

Ліл, та ганьбись же менше, блазню. VCL — це і є делфі,компоненти і візуальний редактор були ідентичними.

І близько не був такий ікспірієнс як з делфі

тим не менш, де той делфі зараз?

замінився на .net і WinForms, який зробив формошльопство ще простішим

Та не замінився він, залишився там де і був. Віжуал бейсік дотнет уже здохнути встиг і залишитись, як стабільний реліз без планів на оновлення, а делфі стабільно обновляється три рази на рік, і додає сучасні фічі. Всім би так вмирати, як делфі. Саме смішне, що рад студія оновлюється під нові можливості платформи віндовс, швидше ніж це робить майкрософт для своїх інструментів. На делфі даж веб виходить сучасніший, за майкрософтовський. Стабільно все погано з мобільними застосунками, але maui у майкрософта також працює через костилі.

З нулями вакансій на всю Україну? Принаймні так джині каже.
Та, десь воно існує, підтримка якихось проєктів або «консерватори», але пацієт скоріше мертвий, ніж живий.

Бачу у вас тут раст в профілі — от реально крута для своїх задач річ, але ну точно не делфі.

Якщо все міряти по вакансіям в Україні, то всі технології мертві окрім дотнета и жаваскріпта.

Ну так не міряйте Україною, ситуація то глобально не зміниться — у вас статистиці всього більше стане, а не щось одне різко виросте у рейтингу.

Он гітхабівська (світова) статистика навіть у 10% проєктів не включає його. Опитування показуть щось менше 2%. Без сумніву, як і на будь-яку мову, на якій колись давно наклепали купу застосунків для бізнесу, тепер оте все треба підтримувати — є і відповідний попит на підтримку, але не на розробку нового.

Але робити щось нове на делфі, у 2026? Ну це прямо мають бути дуже серйозні причини. Є такі?

Нарешті хтось наважився це сказати! Люто плюсую.

За це говорять усі ) Говорять, але вайбкодять на фул кількість токенів)

тоже 20+ лет в разработке (из них 10+ лет embedded).
с выводами скорее не согласен. надо просто понимать ограничения технологии и просчитывать, что можно делегировать и выиграть в итоге по времени, а что будет пустой тратой сил и токенов. всегда есть куча рутины, с которой агенты вполне себе справляются.
например, это мега тул по рефакторингу и относительно дешевому анализу по его целесообразности. это мега тул по анализу работы той или иной части кода. зачастую это довольно эффективная хрень по заполнению уже готовых API. это не лишняя штука в плане code review.

1 месяц+ в разработке💪🏻. Соглашусь с тем, что ИИ-ассистентам нужно знать, что делегировать, рутина их все — это факт. А так они большие умнички, если бы не ИИ, я бы и не создала на Twine свой первый психологический интерактив. Отлично дали жизнь моей идее-наблюдениям. Сведу на минимум консультации).

А так умовний

первый психологический интерактивпервый психологический интерактив

Створили не тільки ви, а ще крім вас натовп інших людей, і всі вони +/- схожі. І ви звісно бубочка і молодець, але якщо раніше ви мали зрозумілий, складний, але всеж зрозумілий шлях — тепер у вас натовп конкурентів і хз що з тим робити, без кучі маркетивногових вкладень, щоб не потонути серез інших.

Створили не тільки ви, а ще крім вас натовп інших людей, і всі вони +/- схожі.

Ви що, не бачите що це ШІ пише? У неї всі пости перші пару речень щось близько до теми і далі реклама.

Типова проблема коли хоть і юзають агента але без флоу та скілів команд...потім виходить що менеджиш одного агента як тупого джуна і по декілька циклів в одному і тому самому чаті проптами, пилиш фічу із правками. Вони тут погандо працюють і доволі низька ефективність, хоча для попси та бойлерплейту може бути дуже гарним.

ШІ розкриває себе коли ти працюєш із ним як архітектор\тімлід — спеки, документація, епіки сторі та флоу від збору вимог до викнонаня, код ревью (по документації) та тестуванню.
Тобто такий собі міні архітект і тімлід, тоді можна сильно в код навіть не занурюватись але глибоко занурюватись в документацію та артефакти SDLC.
Також важливо створити захищене оточення — коли ти створєш безпечні сандбокси для додатків де можна надати йому повний доступ і не паритись що він зламає, банальні правила сесуріті — тіпа не тримати сеснитів токени та кредів до секьюрних енвів щоб він їх навіть не бачив...Вобщем знову підхід тімліда що думає чи можна давати новачку креди чи доступ до сенситів речей чи ні.
В таких випадках ШІ дає гарний буст але і жере багато токенів, на 20 баксовом тарифі далеко не поїдеш. Такі реалії.

Вивчати це та юзати це чи ні, ваше вибір ;-)

А скільки це буде коштувати в токенах?

На 100 баксовому тарифі буде реально достатньо щоб місити код, якщо не працювати в стилі «проаналізуй усі 100500 сервісів і знайди багу із копіпаста_із_джири».

Більш погоджуюсь ніж навпаки.
Існує горизонт складності нижче якого штучка-інтелект дає буст. Над горизонтом буст від’ємний.
Для кожного сета (програміст, домен, таска, штучка) горизонт різний.
Хто отримав х10, той копирсається 10 метрів нижче рівня океану.
Виживуть ті, хто навчиться відчувати цей горизонт нирками.

Ніби пост 2024 року. Ці проблеми присутні ЛЛМкам, причому частина старим ЛЛМкам

Агенти, агент інжінірінг, контекст ініжінірінг, вокрфлоу інжінірінг дозволяє обходити їх, головне знати обмеження ЛЛМок і вміти їх обходити цими інструментами і підходами.

Токени, токени й ше раз токени. Всі ці надбудови й цикли не вирішують старих проблем настільки, щоб прибрати контроль людини. Але роблять це дуже дорогим.

Саме банальне що я працюю з розробкою ЩІ і розумію чого тут не вистачає. Та всі розуміють — спеціалізованого донавчання під продукт. Але ціна/час знову таки роблять це нерентабельним

настільки, щоб прибрати контроль людини.

Так прибирання контролю людини ніхто і не вимагає, головне щоб ця людина могла робити більше і швидше. Ну і в деяких задачах таки позволяє прибрати, і кількість таких задач з кожним місяцем росте.

Але роблять це дуже дорогим.

Дорожче, но все-одно на порядки дешевше людини

Та всі розуміють — спеціалізованого донавчання під продукт

Не вистачає, но жити можна, обходиться контекст інжінірінгом

Не можу погодитись, але і не сперечатимусь.
Проте мені цікаво у яких кейсах з LLM, на вашу думку, можна прибрати контроль людини?

Розгрібання кастомер тікетів, людину залишити для складних кейсів

Написання тестів (взагалі майже не заглядаю туди, но у мене чіткі скіли і правила де і які тести писати)

Деякий кодинг (якщо модуль ізольований від системи і його не треба часто підтримувати, то в принципі пофіг що там, головне що працює, можна забити на перевірку коду)

Код ревью в плані регресії, багів, секьюріті, перфоманса — це все АІшка зробить краще 90% сінйорів. Но, людина ще потрібна для перевірки архітектури, дизайну, інтерфейсів, інтеграції різних модулів. Не тому що АІшка не може, а тому що це все суб’єктивно і АІшка навіть зі скілами і правилами може не попасти в конвеншини і бачення ідеального коду окремої людини, проекту, команди.

АІшка тут це налаштований агентський стек і токени-токени-токени, а не ЛЛМка. Ну і все упирається в токени і бюджет. Кількість і складність багатьох задач, які можна вирішити без людей, упирається в кількість токенів, які ти можеш потратити.

Один банк в США на цьому вже дуже сильно нагнули — два роки якщо пам’ять не зраджує люди не могли повідомити про баг в системі, який не давав їм отримати виплати. А повідомити не могли — бо ШІ розгрібав їх тікети.

З усім іншим, як і раніше — не погоджуюсь. У тому числі й з тим зло агенський стек у тому вигляді, якому він масово існує зараз, це не ллмка. Більш складно організована, але всеж за специфічним виключеням — це все в базі зазвичай та сама LLM.

Закидаєш в LLM великий контекст і задачу і на виході отримуєш галюцинації жорсткий недетермінізм і галюцинації з вірогідністю 80%

Закидаєш в умовний дефолтний клодкод велику задачу, недетермінізм зменшується до 40%

Робиш планування, розбиваєш задачу на під задачі, і запускаєш окрему клодовську сесію на задачу, і недетермінізм зеншується до 20%

Добавляєш скіли, хуки, сабагентів, робиш нормальний claude.md і недетермінізм зненшується до 10%

Добавляєш верифікаційний цикл, коли один агент щось робить, а інший перевіряє, і так для кожної підздачі, поки не задовільнить вимогам поставленої задачі — недетермінізм падає до 1-5%

І там і там ЛЛМ, но результат, як бачиш, кардинально інший.

PS Цифри з неба взяв, все залежить від задачі, налаштувань і знань, но смисл і порядки, я думаю зрозумілий.

PSPS Якщо у тебе результат між голою ЛЛМ і налаштованим агентом (зі скілами, хуками, саб агентами, правилами) однаковий, то у тебе проблеми зі скілами (твоїми скілами, не агентськими).

Окей, і в результаті хто перевіряжє чи задача виконана вірно після агентів?

Самі ж агенти. При умові що у тебе є чітко поставлена задача з чіткими очікуваннями. Потім можна попросити агентів проревьювити — коректність, баги, регресію, перфоманс, секьюріті вони перевіряють на ура, можна довіритись на 99%. Не довіряєш? Запускаєш кілька раз різними агентами і моделями, скільки токенів не жалко.

Тобі залишається лише перевірити дизайн, чи співпадає з твоїм баченням ідеального коду і дизайну.

Я працюю в тому числі із мікроконтролерами. Тут ШІ не просто марний — він активно шкідливий.

не знаю, постійно використовую у тестуванні чи реверс інжинірингу

Великі мовні моделі не перевіряють істинність. Вони не запускають код.

Тобто?
В мене запускає написаний код, запускає браузер і бекенд, тестує зміни, і повідомить мені що готово коли все готово і працює.

grill-me скіл це взагалі топ для збору і уточнення вимог.

Хтось мав це сказати. Співчуваю 😀

Архітектурна особливість. Великі мовні моделі не перевіряють істинність. Вони не запускають код. Модель просто шукає серед того, що було в датасетах.

Дурня якась. Що заважає дати агенту доступ до девайса і запускати та перевіряти код? Це якийсь позаминулорічний стиль роботи.

Припустимо ми пішли цим шляхом.
1. Для того щоб агент перевіряв, щоб після не треба було перевіряти чи правильно перевірив агент — треба написати тести, роботоздатність яких перевірить людина.
2. Ніколи не бачив теста який би покривав 100% ситуацій. Тест завжди доповнює людина, яка хочаб один раз подивиться (програміст який це писав, тестувальник) очами чи це працює, а далі тест просто фіксує чи не відвалилась вже працююча фіча. Й то не завжди спрацьовує, бо відвалитись може по різному.

Які я очевидні проблеми бачу?
1. Буде дуже багато циклів додаткових перевірок, бо зазвичай ШІ переписує код, а не виправляє. Кожну нову його ітерацію треба буде перевіряти, виявляти. І на відміну від живої людини, треба ще перевіряти значно ретельніше. Це буде дорого.

2. Уявімо баг не був виявлений вчасно й з’явилась значна кодова база поверх — і це теж буде дуже дорого виправити, у порівнянні з тим що це робить людина.

Тобто суть не в тому що це неможливо впринципі. Суть в тому що це дуже дорого.

Також це буде доволі довго, бо реальний девайс працює в реальному часі. На відміну від міркувань ШІ — реальний девайс буде виконувати операцію «чекай дебаунс 50мкс» власне зі швидкістю 50мкс. Кожна ітерація буде тривати [міркуваня ШІ + операції на реальному девайсі], в реальному часі, котрий може бути доволі тривалим. І це зазвичай терпимо, але ШІ таких ітерацій робить значно більше людини.

В це я ще мовчу якщо реального девайса ще немає... виготовляти по девайсу на кожну фантазію ШІ?

я думаю під «девайсом» мався на увазі програмний ємулятор, а не фізичний пристрій, бо ціна помилки буде дорогою...

Ну дивіться.
1. Припустімо я використаю емулятор. Такі є і вони використовуються.
2. Припустімо я зроблю нейронку на генетичних алгоритмах наприклад, для генерації через емулятор. Такі теж є і це дуже крута технологія — я її всіми руками плюсую.

Питання, а нахіба мені у цій інфраструктурі ллм? Дайте мені чіткий інтерфейс, а не словесний інтерфейс, який умовний батон крутитиме поперек, замість вздовж, через неідеальність промта. А потім ще вибачається коли це помітиш. Нахіба мені його вибаченя, коли у другій ітерації він знову якось «крутиме по діагоналі», і три дні просто намагаєшся промт написати, замість роботи.

Я хочу передбачуване виконання задачі, а не «магію» коли виходить «як виходить».

Бо формалізувати задачу дуже важко. По суті — це її запрограмувати.
А формалізувати задачу без багів в формалізації — зазвичай неможливо. Тому ракети падають, а з супутниками зв’язок губиться, хоч там усе формалізовано.

Ну там частіше «про щось не подумали, щось завтикали», але погоджусь.

Якшо цікаво, є пару чатиків:
t.me/embeddedkyiv ембедед, але здебільшого не про ШІ, хоча часом обговорювалося
t.me/swarchua архітектура, котра часто переповзає в ШІ чи менеджмент

Олександре, я з дуже схожих проблем дійшов до висновку, що потрібен не просто «кращий промпт» і не ще один чат із ШІ, а власна експертна система для інженерного R&D. Над цим зараз активно працюю.

Для нас проблема не тільки в тому, що ШІ галюцинує. Нам зрозуміло що це тому, що ШІ (як технічний сервіс) не має нормального шару перевірених джерел, документації, errata, register maps, SDK release notes, обмежень по пам’яті/таймінгах, і нема на це впливу людського досвіду. В embedded/hardware це показово критично, але не виключно там — для усіх користувачів хмарна модель легко тягне з відкритих джерел Інтернету старі мануали, можливо нові але частіше застарілі (перевірені!) API, неіснуючі регістри мікроконтролерів, або змішує різні версії SDK. Ще гірше ситуація коли у тебе внутрішній продукт — і залізо лише вчора з конвеєра, і документація на нього може бути ще не повністю готова, публічних знань про це нема.

Я якраз пишу на ДОУ серію статей про експертні системи для R&D: чому чат хмарного AI не дорівнює корпоративній експертній системі, коли ШІ-рекомендація може бути доказом, і чому корпоративна пам’ять має бути актуальною, «живою». Сподіваюсь, вам буде цікаво прочитати мої статті, залишити експертні коментарі з власного досвіду.

Ще гірше ситуація коли у тебе внутрішній продукт — і залізо лише вчора з конвеєра, і документація на нього може бути ще не повністю готова, публічних знань про це нема.

А корпоративний ШІ не підключений до внутрішньої документації?

Тут проста відповідь не вийде. Бо відповідь залежить від того як в «корпорації» обробляють дані, де зберігають, і як формують знання (людські і електронні).
Припущу так — в малій-середній компанії (ну до 300 інженері в середньому) де є централізоване сховище інженерних документів (різної внутрішньої форми), де гомогенна інформаційна система, корпоративний ШІ напевно прийнятно швидко опанує оновлення. Знов таки якщо Knowledge Acquisition System ефективно налаштована.
У великій компанії, транснаціональній, багато офісів в різних геолокаціях, де якось інтегровані раніше придбані компанії з їх особливими автоматизованими системами, то є проблема, від якої виникають згадані наслідки.

Ну ШІ рекламують саме для таких задач — інтегрувати та аналізувати дані з багатьох джерел

Рекламувати можна й надписи на парканах — проблеми від того не зникають автоматично. Я вам надаю відповідь, утворену проблемами, з якими я борюся. Тому обережно припускаю, що десь це може гарно спрацювати, як хтось рекламує. А десь — не працює так, «маємо те, що ми маємо». Хтось зінтегрував власні джерела, а хтось ні — чарівної палочки тут нема, «треба просто брати і робити цей проект» як каже один мій колега.

Нокія та Ксерокс так і робили. А ще — ті будівельники космічних кораблів, котрі були до Ілона Маска.

Це фактично використання ШІ як пошукового агента. Всеодно потім треба дивитись що саме він знайшов. Але я від такої пошукової системи не відмовивсяб.

Думаю, має бути варіант налаштувати іншого агента для перевірки фактів. Або третього для перевірки реальних налаштувань заліза на платі відповідно до документу.

В принципі, ніби саме такі пошукові системи рекламує Антропік anthropic.skilljar.com/...​oduction-to-claude-cowork

Немає сенсу. Поверх цього всеодно треба ставити людину, яка перевірятиме чи правильно перевіряє ШІ. А для перевірки налаштувань немає сенсу задіювати ШІ.

То проблема ж була в тому, що перемішується стара та нова документація?

Ось народ зробив щоб підтягяти нову medium.com/...​-claude-code-eb14c9fd654f

А щоб перевірити, що воно правильно — треба тестовий фреймворк. Якщо у вас залізо — треба тестовий фреймворк для заліза, котрий перевірить кожен тип шини. Все одно вам треба будуть ці тести для виробництва плат на фабриці.

Якщо ШІ невірно зібрав документацію — чи в самій документації є баги — заваляться тести заліза. Якщо тести пройшли — то можна йому дозволити щось кодити на базі цих доків, і не боятися, що звідкілясь вилізуть старі регістри з минулої ревізії борди.

Шини? ох... шини... не розглядайте це як «задачу коду». Наприклад, як щодо ЕМІ? Я маю на увазі самопродуковані ЕМІ, а не зовнішні.

Вони викликаються тим, що ШІ написав якийсь код, спираючись на невірний даташіт?

ЕМІ? Вони викликані тим що існує така штука як поле Максвела, яке спрощують до деяких простих електричних правил. Це спрощує первинне прототипування, але потребує тестів, бо в реальності воно працює трохи не так.

Якщо прямо дуже просто — швидкісна шина продукуватиме паразитний вплив на сусідні вузли. І це не програмна проблема.

В той час як людина сприється на більш варіативну, об’ємну й швидку спайкову мережу в голові, і спочатку думає, міряє, декомпозує, усвідомлює, а лише потім робить новий прототип — ШІ як більш примітивна мережа, менше думає і більше використовує грубий прямий перебір, зі зворотнім відгуком. Без сумніву він здобуде досвід і з часом стане краще, але хто за це платитиме?

То у вас проблему з ШІ для прототипування плат чи для написання коду?

Якщо ми кажемо про «код для ембедет», якщо це вже готовий продукт і хтось заморочивася — так, інколи там задачі чисто по коду потім йдуть.

Але в загальному, в ембедет — хард і софт це нерознривні речі. Вони не існують як коремі задачі. Є домен задачі — наприклад прикрутити камеру, а тут виявляєтсья що вбудованої пам’яті мало, а умовний (наприклад) PSRAM не завезли і думаєш що з цим робити.

Але в загальному, в ембедет — хард і софт це нерознривні речі.

Тоді питання, що ви звете ембедедом. Наприклад, я писав для радіотелефонів, а потім навіть робив телефонію для WiFi роутерів. Це — ембедед?

При тому в радіотелефонній базі, наприклад, був bare metal, і більше 3 сторінок коду на 16-бітному DSP. Така кількість коду не може бути залізо-залежною — там купа рівнів абстракції. І кілька томів стандарту, котрі треба заімплементити.

Схожа ситуація в автомотіві, але в квадраті. Народ каже про гігабайти коду. Це — ембедед чи ні?

Ну от давайте на супер примітивному прикладі, от прямо щоб взагалі функціонал був на рівні плінтуса — прошивка для ліхтарика це ембедет чи ні?

А проблема мерехтіння прототипа ліхтарика на камеру, це до кого питаня треба направити, до ембедета чи ні?

А виправляється це кодом чи кодом+хард, чи тільки хардом?

Прошивка ліхтарика — ембедед.
За проблему мерехтіння не чув.

А в роутерах біжить лінукс. Лінукс — це ембедед? Роутер — це ембедед?

Почекайте. Ми ще з ліхтариком не розібрались.

Мерехтіння ліхтарика на камері з’являється через ШІМ керування. Пояснювати що таке ШІМ з точки зору фізики і чому виникає мерехтіння? Якшо ні, то от ви наприклад ембедет в цьому продукті, маємо цей прототип, ще не продукт. Як нам цю проблему вирішити?

Якшо ні, то от ви наприклад ембедет в цьому продукті, маємо цей прототип, ще не продукт. Як нам цю проблему вирішити?

Змінити налаштування чіпа, котрі виставляють частоту модуляції. Вивести назовні інтерфейс для керування частотою, щоб вона не перетиналася з частотою камери юзера, якою б ця камера не була. При цьому ліхтарик стане втричі дорожчим, і почне протікати. Тому це робити не потрібно.

А тепер розповідайте, чи роутер з лінуксом є ембедед пристроєм.

Навіть з дуже високою частотою, всеодно іноді може виникати мерехтіння. Бо проблемаж не в частоті, а не узгодженості, збільшеня частоти лише міняє вірогідність неузгодженості. І, як ви правильно сказали — можливо більша частота збільшила ціну (нефакт).

Пане ембедет, що робитимемо?

Я ж розписав — вивести інтерфейс для керування частотою назовні. Що збільшить ціну виробу, і змінить цільовий сегмент ринку. Відповідно, треба буде нову маркетингову кампанію, пане. Відповідно, ваша «проблема мерехтіння на камеру» ламає весь проект, котрий менеджмент собі в голові продумав.

А тепер, пане, давайте повернемося до практики. Ось мій пристрій, з моєю прошивкою keenetic.com/en/keenetic-linear

А де ваші пристрої?

Пане ембедет із реалізованими проєктами. Тут якийсь Олександр з ДОУ, каже що ембедет без хочаб бзового розуміння заліза — дуже обмежений ембедет.

Питає чи не простіше булоб зробити апаратне згладжування, Каже що зміна у собівартості менше 10 гривень, а проблема зникає повністю.

Пане керівник дослідницького відділу без реалізованих проектів! Прошу розказати, як ви реалізуєте в залізі щось хоч трохи складне, на зразок стандарту телефонії www.etsi.org/...​0/ts_10252703v010601p.pdf

Пане ембедет. Ми досі не вирішили робочу задачу яку ми вам поставили. Відео зняті при світлі вашого ліхтарика все ще мерехтять. Робота не виконана. Ви не будете міняти тему, щоб не робити свою роботу. Якщо не подобаєтсья — можете звільнитись і цю задачу я виконаю сам.

Пане начальник дослідницького відділу!
Прошу, займайтеся ліхтариками, котрі вмієте робити, і не лізьте в телефонію та складніший ембедед, про котрий боїтеся розмовляти.

Пане ембедет, ви спочатку елементарну задачу виконайте, потім розказуйте про щось складне десь там.

Вельмишанований пан начальник!

Мені не треба виконувати елементарні задачі з електроніки, щоб писати код для вбудованих пристроїв. І навіть щоб розробляти архітектуру цього коду. І навіть щоб цю архітектуру публікувати.

А пан начальник не може навести жодного свого проекту або публікації. І не може розказати, як би він імплементив стандарт для радіотелефонів.

Тому пропоную пану начальнику дослідницького відділу надалі займатися дослідженнями ліхтариків, в котрих ніхто не заперечує його компетенцію.

Пане ембедет, в рамках домену цієї задачі — мені немає значеня як ви виконуєте задачу — хоч кодом, хоч бубном, хоч ще як. Якщо задача вирішена — немає значеня як ви це зробили. Але задача не виконана. Ви спеціаліст який викликавсяна цю задачу в рамках обговореня. Можете пояснити чому виникла проблема?

Ви спеціаліст який викликавсяна цю задачу в рамках обговореня.

Я не викликався робити те, що не вмію.
А ви, пане начальнику, боїтеся навіть відкрити стандарт телефонії, драфт котрого я імплементував 15 років тому.

Зрозуміло пане ембедед. Раз відмовляєтесь, значить доведеться це комусь іншому поручити.

Доручайте. Спеціалізація праці підвищує продуктивність.

Пан нарешті прокоментує, як він зробить телефонію (NG DECT) в залізі?

Пане, я просто хочу пояснити. Ви прекрасний спеціаліст. Я сподіваюсь теж непоганий спеціаліст у своїй сфері (м’яка роботехніка). Але у нас просто різний досвід.

Пане начальник, ось з цього вашого твердження почалося:

Але в загальному, в ембедет — хард і софт це нерознривні речі. Вони не існують як коремі задачі.

Далі ви вирішили питати мене про залізо, котре я не заявляв що знаю. То ж давайте я попитаю вас трохи про софт, котрий ви стверджуєте, що знаєте — бо ж воно «нерозривні речі» з залізом.

Наприклад, ви ж робили bare metal системи, мабуть? Ось трохи питань з практичного програмування для заліза (лише прошу не підглядати в ЧатЖПТ):
— Ви робили unity build? В яких випадках?
— Вам доводилося зменшувати пам’ять (RAM) чіпа в налаштуваннях лінкера? Навіщо?
— Ви писали власний протокол для доступу через USB до регістрів та пам’яті спеціалізованого процесора (наприклад, DSP)? Скільки в такому протоколі команд та яких?

Та, мабуть я був занадто категоричний, але ж і ви погодтесь, занадто критичні були щодо коду, на чому я вас і підловив.

В класичному сенсі на голому залізі я не програмую, були певні дуже специфічні задачі які можна так назвати, але там така специфіка, що буде дуже довго пояснювати чому я не вважаю це тим самим bare metal, про який кажете ви.

У всьому іншому — давайте не будемо займатись ментальною гімнастикою. Вмійте бачити межі.

Навіть з дуже високою частотою, всеодно іноді може виникати мерехтіння.

І нафіга там взагалі ваша частота на світлодіоді? Просто buck DC-DC з керуванням вихідним струмом через опорну напругу, яку знімієш з інтегратора після ШІМ. Коли почались блекаути і бариги офігіли, я на колінці ламп таких наплодив, точніше прокачав китайські. З «вартості» там копійчаний mt3406, зате високий ККД, відносна стабілізованість світлового потоку, ніякого мерехтіння і «аналогове» керування яскравістю.

Ідея робоча. Хоча яб всетаки фільтр поставив.

Яскравість регулюють ШІМ, бо 1) світловіддача нелінійно залежить від струму, 2) спектр люмінофору нелінійно залежить від струму, на меншій яскравості він менш ефективний і спектр стає холоднішим, 3) DC-DC перетворювачі нестабільно працюють, коли вся вихідна потужність сумірна з амплітудою їх пульсацій, отой самий coil while блоків живлення, відеокарт і всього такого це воно.

Ну нехай собі там залежить. Людське око взагалі нелінійно сприймає яскравість, того для ШІМ і роблять матрицю з логарифмічною функцією, щоб з % яскравості перевести. Яка різниця яка там буде залежність?

спектр люмінофору нелінійно залежить від струму

І від температури теж. Ті проценти от прямо дуже важливі для ліхтарика.

DC-DC перетворювачі нестабільно працюють

Працювати на low-load з двома PFM та PWM режимами його призначення, там 1.5МГц, ну і це все ще ліхтарик. В будь-якому випадку нічого там не свистить, навіть якщо з 400мА скидувати до ~0мА.

В мене зараз ліхтарик свистить в режимі зниженої яскравості

Так його драйвер 99% там через ШИМ на виході, а не встановлення константного вихідного струму, і працює. Тим більш навряд чи на 1,5МГц. Фіг знає нащо виробники роблять мікросхеми імпульсних LED драйверів, а потім замість виходу компаратору для підстройки струму ліплять просто вихід для gate, який модулює вихід драйвера. Наче той компаратор там так багато місця на кристалі займає.

А от оце, яб якраз програмно вирішив.

IPS дисплей в якості ліхтарика). Іноді також допомагає виставити максимальну яскравість LED.

Чому я майже перестав використовувати ШІ

[Кричить:] Скілл ішью!

Стратигічно ШІ не дуже змінився за рік для моїх сценаріїв shbohdan.github.io/...​/2025/copilot-experience
Великої економії часу не буде, але буде економія часу на кодінг (може навіть х10). Проте більше часу треба буде витрачати на те, що раніше робив бізнес аналітик. Фактично ми приходимо до переродження програмістів у те, що колись називалось системний аналітик.

Але якщо рік назад у ШІ був рівень «джуна розпіздяя», то зараз це рівень «нормального джуна здатного на ресерч». Тобто кількість галюцинацій стала значно меншою, при тому пошук інформації та аналіз проекту значно краще.

Щодо бізнес задач, то знайшлось рішення — план мод (є в курсорі і наче в копайлоті теж):

  1. Спочатку просите скласти план виконання задачі. Задачу все ще краще описувати подетальніше. Ще можна попросити зробити опис ворквлоу в проекті на основі тестів і тд.
  2. Тако ж доведеться давати уточнення до плану.
  3. Потім на основі плану та допоміжної інформації реалізувати задачу.
При цьому план мод — це ще й спосіб дисциплінувати себе, аналогічно тестам в ТДД.

Аналогічно вирішується описана проблема з Аудріно: ви додаєте «скіли» — фактично текстовий опис типових проблем, документацію і тд. Тобто вам треба буде «навчати» ЛЛМ, але це технічна, а не концептуальна, проблема.

Богдане, є дослідженя яке описує когнітивний ефект: програмісти пишуть код з ШІ повільніе, але їм здається що вони значно прискорились. Десь була стаття про це на ДОУ навіть.

Тому питання, яким чином було оцінено що ви пишите код швидше?

Тому питання, яким чином було оцінено що ви пишите код швидше?

Дуже просто:
Задача (типова нудна бізнес логіка) оцінена в 1-2 дні, аналогічна задачі, яка виконувалась 2+ дні раніше, була виконана сумарно за 0.5 дня. З цих 4 години — 3+ зайняла верифікація тестів і валідація рішення.
Сам «кодінг» (включно з генерацією юніт та інтеграційних тестів) зайняв ~10 хв. Знаючи себе я б фізично не надрукував би той об’єм коду на 10 хв.
Алгоритмічні задачі аналогічно, типовий обхід дерева і тд, який на співбесідах люди пишуть 20-40 хв, в продакшен умовах, враховуючи необхідність інтеграції в кодову базу + тести, може затягнутись на 1-2 години — менше хвилини генерації + 10-20 хв на валідацію рішення.

Але ще раз:

Великої економії часу не буде, але буде економія часу на кодінг (може навіть х10).

Загальний час виконання задачі (з бізнес аналізом, декомпозицією, рев’ю і тд) суттєво не змінюється в середньому. Але для нудних типових задач, таких як зроби мені КРУД, навіть по цій метриці є пришвидшення.
Час на кодінг — я описав вище.

GitClear каже що якраз у такому сценаріях і виникає проблема часу.

1. Якщо це базова академічна задача штибу «обхід дерева», яке зазвичай ніхто не пише бо є готові функції для цього — то ШІ справиться просто.
2. Якщо це задача створеня бутстрепа — скопіювати код із аналогічного проєту ефективніше.
3. Якщо це проект з великою кодовою базою — проблеми інколи досягаються такого рівня, що це зупиняє продукт.

Якщо це базова академічна задача штибу «обхід дерева», яке зазвичай ніхто не пише бо є готові функції для цього

Теоретично так. На практиці, ви будете довше шукати ту лібу, розбиратись як її прикрутити до вашої задачі, а ще у вас можуть бути вимоги по юридичній перевірці нових бібліотек.
Бейслайн я вам задав — вам треба це все зробити швидше ніж на 1 хв.

Це не теоретично. Це GitClear. GitClear це дуже серйозна аналітика активності програмістів та оцінінка їх продуктивності та продуктивності команд. І GitClear каже що, за виключеням певних кейсів — ШІ знвчно погішує продуктивність програмістів.

А на практиці — пошук нової ліби не скасовує перевірки її відповідності й актуальнсті. Якраз подібний кейс у дописі й розглядається.

Алгоритмічні задачі

А вони хіба бувають?

А вони хіба бувають?

Я ж описав. Обходи дерева, пошуки найкоротшого шляху, обходи регіонів матриць і тд як не дивно трапляються. Це при тому, що я зараз — тайпскрипт макака.

макака ок, а чому ти додав тайпскрипт, типу пайтон чи джава не макака? Я взагалі не дивуюсь, що АІ краще будь якої макаки.

буде економія часу на кодінг

А яку частину часу у вашому процесі розробки займав/займає саме кодинг?
Бо і «з підручників» і з власного досвіду воно співмірно з набором тексту, якщо не враховувати меми про «як назвати змінну» ))
Плюс багато типових рішень генерувалось напівавтоматично ще за царя Гороха (або копіпастилось з попереднього проєкту ггг)

В том то й суть що копіпастилось. І ти завжди знаєш що свме ти копіпастив, і як воно працювало.

Чого було більше сказати складно. Залізо/софт — воно не те щоб у відриві одне від одного існує в моїй роботі. Але мабуть всеж заліза трохи більше.

То питання було до пана, в якого приріст по швидкості кодингу «може навіть х10»
І скоріше в контексті типових кроків в розробці: дизайн/планування/кодинг/дебаг/різні етапи тестування.

Просто щоб розуміти скільки це «х10» в абсолютних величинах. Бо я краще потрачу дві години замість 10хв, але буду розуміти що і як відбувається )) Типу, якщо на задачу тратиться 20 годин 10хв або 22 години, то якось не критично

Вибачайте, заплутався у дереві коментарів.

/grill-me та /grill-me-with-docs від github.com/mattpocock/skills
Дають кращий результат за plan mode :)

Це називається «Адаптація». Неякісний код — це результат невірного параметризованого промту. Так це не AGI — але ШІ наразі це потужний інструмент. Бізнес швидко звикає до MVP за 5 хвилин роботи LLM модель.

Є трохи різниця в результатах:
— якщо AWS падає, то воно саме через годину підіймається, і усі клієнти щасливі, що ШІ фічі нарешті зарелізили в хмарного провайдера.
— якщо залізка падає і втрачає доступ до мережі — то її треба нести до сервіс-центру, або до смітника. А цих залізок в полі мільйони — і вгадайте, як виглядає викочування бажного апдейта на залізо.

Як звикає, так і відвикне. Технічний борг приходить, неякісні MVP.
Це коли ти один можеш клепати MVP за п’ять хвилин — круто. А коли всі — твоя презентація інвестору/покупцю вже нічим не виділяється посеред інших.

тут правий, вони просто всі однакові будуть ваші MVP за 5 хв, а значить нікому не потрібні

MVP — це впершу чергу за бізнес потребу. Крутість то вже справа рефакторінгу.

Скоріше переписування з нуля.

Неякісний код — це результат невірного параметризованого промту.

автор пише що якісного коду нереально добитися, бо AІ не знає контексту — хардвару, бест практик. а навчений на гівногоді якого більшість в відкритих джерелах.
і коли через N ітерацій вдається досягти прийнятного результату то виявляється що простіше розібратися і написати самому. а розібратися самому це завжди необхідний крок через вже озвучену проблему

UPD: це як найняти фронтендщика на розробку бойового дрона. яким би ви не були керівником і які б «правильні» задачі не давали. фронтендщик не зробить цю задачу як це очікувалося від профільного спеца з досвідом

Але ж є купа ембедерських контор, котрі могли б зібратися й один раз навчити бест практікам.

Алеж це всі контори отримають цей продукт. У чому профіт для бізнеса?

В тому, що завтра не прийде Ілон Маск і не зробить те ж, але в 10 разів дешевше.

Маєте на увазі що він депінгуватиме ціну? Велком.

Ні, в нього код писатиметься суттєво дешевше, нові фічі робитимуться швидше, і буде легко інтегруватися нове залізо.

Е.. ні. Бо Наразі ШІ потребує купу прикладів для будь-чого нового. Якщо зараз вийде умовна «нова фіча для JS», то ШІ ще дуже довго не зможе її адекватно використовувати.

От під старе залізо — так. Але під старе залізо і так питань особливих не було раніше.

ШІ потребує прикладів в скілах чи в кодовій базі. І якщо велика контора ці скіли з прикладами надасть, і віддебажить — то й проблем не буде.

Ви ж ще не програмуєте нове залізо на С++26?

Ви уявляєте кількість необхідних прикладів?

Щодо питання, конктерно я, якщо мова про щось велике, наприклад робот собака, часто зараз почав застосовуати Rust. Мабуть це можна віднести до чогось з незначною кількістю прикладів.

Я уявляю кількість коду, наприклад, в автомотіві. Це — десятки чи сотні мільйонів рядків. Там достатньо матеріалу. Звичайно, не на С++26.

Процес недовіри до AI це нормальний етап сприйняття технології. Через деякий час , думка зміниться. А щодо пояснення з фронтедом — це на разі не зовсім так, справа в розумінні архітектури та трішки скілах.

На мою думку, ми не етапи недовіри, а таки навпаки — етапі надмірних очікувань від технології.

Немає надмірних очікувань. AI замінить кодінг але не весь, як мови програмування замінили ассемблер. Це теж відбулось не відразу. 90% коду і до AI було шлаком — тому для бізнесу різниці немає людина чи AI. Ті 10% що вимагають людину будуть скорочуватись а не зростати, відповідно з ринку що скорочується треба втікати.

При цьому всьому завжди є манагери які будуть робити неадекватні оцінки. Є люди які спробують ті 10% що залишились закрити AI, і це все призведе локально до піздеца, але глобальний тренд це не змінить

Почекайте, але ж що асемблер, що мови програмування мали однозначну і 100% передбачувану дію, у відповідь на будь-який варіант інструкції. Хіба ШІ такі?

істина десь посередині я на 60 відсотків згоден з автором

Підписатись на коментарі