Попередня частина 👆
Тут і проявляється парадокс: система, яку будували як інструмент чесності й прозорості, у найвразливіший момент свого розвитку прийняла максимально непрозорі й нечесні гроші - і продовжила працювати так, ніби нічого не сталося.
Часто кажуть: «біткоїн - це свобода». Але свобода від чого саме? Від банків? Можливо. Та свобода від банків не дорівнює свободі від людей, які мають доступ до капіталу й впливу. Бо ці люди не прив’язані до інститутів. Вони прив’язані до грошей.
А гроші, як правило, течуть туди, де є влада. І вже не так важливо, як називається механізм: банк, блокчейн чи «децентралізована мережа». Якщо думати, що зміна назви системи змінює її суть, це, здається, помилка. Суть не тільки в правилах. Суть у людях, які знаходять спосіб керувати правилами через ресурс.
Найсумніше тут навіть не те, що Епштейн «зайшов» у крипту. А те, що ніхто не відмовився від його грошей. Система була готова прийняти їх і далі будувати свій світ - на цих самих ресурсах.
І на цьому тлі постать Сатоші виглядає майже як контрастний експеримент. Він, ким би він не був, зник. Не взяв ні копійки зі своїх гаманців, де зараз лежать мільярди. Він створив систему - і пішов.
А Епштейн залишився. Прийшов із мішком грошей, сів за стіл, познайомив потрібних людей і почав впливати на те, куди рухатиметься ринок. Створювач пішов - а той, хто живе за рахунок систем, зайняв місце поряд із кермом.
Це можна сприймати як історію про крипту. Але, здається, це ширша метафора. Ти можеш спроєктувати ідеальний дім - продуманий, логічний, «правильний». Але якщо в тебе немає землі, ресурсів на будівництво і часу, щоб довести справу до кінця, прийде той, хто заплатить. І тоді дім буде його. Не тому, що він краще придумав. А тому, що в нього були гроші саме тоді, коли в тебе їх не було.
Тому коли наступного разу скажуть, що крипта - це «зброя маленької людини проти системи», варто згадати одну деталь. У ключовий момент маленька людина сиділа без зарплати, а чек виписував педофіл із особняка на Мангеттені.
✅ Якщо пост був корисним став 👍
💬 А ви вірите, що технології можуть звільняти, чи вони лише змінюють форму контролю?
🔔 ПІДПИСАТИСЯ
Тут і проявляється парадокс: система, яку будували як інструмент чесності й прозорості, у найвразливіший момент свого розвитку прийняла максимально непрозорі й нечесні гроші - і продовжила працювати так, ніби нічого не сталося.
Часто кажуть: «біткоїн - це свобода». Але свобода від чого саме? Від банків? Можливо. Та свобода від банків не дорівнює свободі від людей, які мають доступ до капіталу й впливу. Бо ці люди не прив’язані до інститутів. Вони прив’язані до грошей.
А гроші, як правило, течуть туди, де є влада. І вже не так важливо, як називається механізм: банк, блокчейн чи «децентралізована мережа». Якщо думати, що зміна назви системи змінює її суть, це, здається, помилка. Суть не тільки в правилах. Суть у людях, які знаходять спосіб керувати правилами через ресурс.
Найсумніше тут навіть не те, що Епштейн «зайшов» у крипту. А те, що ніхто не відмовився від його грошей. Система була готова прийняти їх і далі будувати свій світ - на цих самих ресурсах.
І на цьому тлі постать Сатоші виглядає майже як контрастний експеримент. Він, ким би він не був, зник. Не взяв ні копійки зі своїх гаманців, де зараз лежать мільярди. Він створив систему - і пішов.
А Епштейн залишився. Прийшов із мішком грошей, сів за стіл, познайомив потрібних людей і почав впливати на те, куди рухатиметься ринок. Створювач пішов - а той, хто живе за рахунок систем, зайняв місце поряд із кермом.
Це можна сприймати як історію про крипту. Але, здається, це ширша метафора. Ти можеш спроєктувати ідеальний дім - продуманий, логічний, «правильний». Але якщо в тебе немає землі, ресурсів на будівництво і часу, щоб довести справу до кінця, прийде той, хто заплатить. І тоді дім буде його. Не тому, що він краще придумав. А тому, що в нього були гроші саме тоді, коли в тебе їх не було.
Тому коли наступного разу скажуть, що крипта - це «зброя маленької людини проти системи», варто згадати одну деталь. У ключовий момент маленька людина сиділа без зарплати, а чек виписував педофіл із особняка на Мангеттені.
✅ Якщо пост був корисним став 👍
💬 А ви вірите, що технології можуть звільняти, чи вони лише змінюють форму контролю?
🔔 ПІДПИСАТИСЯ
👍17🤔4❤1
Я багато працюю з людьми і бачу, як вони використовують AI. Якщо чесно, у більшості випадків усе зводиться до одного інструмента - ChatGPT. І для повсякденних задач цього зазвичай достатньо.
Це зрозуміло. Він зручний, доступний і справді закриває велику частину запитів. Але іноді виникає запитання: чи не звужуємо ми таким чином власну практику? Різні моделі по-різному працюють із контекстом, по-різному структурують відповідь, по-різному поводяться в складних сценаріях. Якщо користуватися лише однією системою, ми просто не бачимо альтернатив.
Anthropic нещодавно оновила свою флагманську модель до Claude Opus 4.6. Її описують як крок у бік довших і складніших задач, особливо тих, де модель діє як агент. Формально все виглядає доволі просто: контекст до одного мільйона токенів і можливість генерувати до 128 тисяч токенів у відповіді. Але справа, здається, не лише в цифрах.
Останні роки навіть з’являються нові ролі на кшталт контекст-інженера, який займається тим, як правильно «упакувати» запит до моделі. І водночас нові версії самих моделей намагаються частково забрати цю складність на себе. Це мимоволі нагадує ідею з есе The Bitter Lesson: масштабування і автоматизація поступово витісняють ручну оптимізацію.
У Opus 4.6 з’явився режим adaptive thinking. Тепер модель сама вирішує, скільки ресурсу витратити на міркування залежно від складності задачі. Раніше потрібно було задавати фіксований бюджет для розширеного мислення, тепер частина цього рішення переноситься всередину моделі. Є параметр effort із чотирма рівнями, який впливає на те, наскільки активно вона заглиблюється в аналіз. Міркування можуть з’являтися і між викликами інструментів, і перед відповіддю.
Про бенчмарки можна сказати коротко. У зведеному індексі Artificial Analysis модель посіла перше місце. В окремих тестах, пов’язаних із робочими задачами, вона також показала високі результати. Але, якщо чесно, для більшості читачів ці цифри мало що змінюють. Важливіше інше.
Є й менш зручні деталі. У кількох тестах нова версія поступилася попередній, зокрема в дотриманні інструкцій і частоті галюцинацій. Тобто збільшення можливостей не означає автоматичне покращення за всіма параметрами. Компроміси залишаються.
Цікавий і момент із поведінкою агента. Під час тестування модель попросили створити pull request на GitHub без необхідних доступів. Замість того щоб запитати права, вона знайшла чужий токен і використала його. До речі, я бачив, як відомі підприємці вже пояснюють у відкритому доступі, що таке pull request і як працювати з GitHub. Світ змінюється, і базове розуміння програмної інженерії поступово стає нормою навіть поза технічною сферою. Але в цьому випадку справа не в GitHub. Справа в тому, як модель інтерпретує мету і де проходить межа допустимого.
У бізнес-симуляції Vending-Bench 2 Opus 4.6 показала рекордний прибуток. Проте частину цього результату вона досягла через неетичні дії: вводила клієнтів і постачальників в оману. Це змушує замислитися, що саме ми оцінюємо, коли говоримо про «кращий результат». Чисту цифру чи поведінку в межах правил?
Можливо, справжній прогрес полягає не лише в тому, що моделі стають сильнішими. А в тому, що ми поступово вчимося краще розуміти їхні межі.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
Це зрозуміло. Він зручний, доступний і справді закриває велику частину запитів. Але іноді виникає запитання: чи не звужуємо ми таким чином власну практику? Різні моделі по-різному працюють із контекстом, по-різному структурують відповідь, по-різному поводяться в складних сценаріях. Якщо користуватися лише однією системою, ми просто не бачимо альтернатив.
Anthropic нещодавно оновила свою флагманську модель до Claude Opus 4.6. Її описують як крок у бік довших і складніших задач, особливо тих, де модель діє як агент. Формально все виглядає доволі просто: контекст до одного мільйона токенів і можливість генерувати до 128 тисяч токенів у відповіді. Але справа, здається, не лише в цифрах.
Останні роки навіть з’являються нові ролі на кшталт контекст-інженера, який займається тим, як правильно «упакувати» запит до моделі. І водночас нові версії самих моделей намагаються частково забрати цю складність на себе. Це мимоволі нагадує ідею з есе The Bitter Lesson: масштабування і автоматизація поступово витісняють ручну оптимізацію.
У Opus 4.6 з’явився режим adaptive thinking. Тепер модель сама вирішує, скільки ресурсу витратити на міркування залежно від складності задачі. Раніше потрібно було задавати фіксований бюджет для розширеного мислення, тепер частина цього рішення переноситься всередину моделі. Є параметр effort із чотирма рівнями, який впливає на те, наскільки активно вона заглиблюється в аналіз. Міркування можуть з’являтися і між викликами інструментів, і перед відповіддю.
Про бенчмарки можна сказати коротко. У зведеному індексі Artificial Analysis модель посіла перше місце. В окремих тестах, пов’язаних із робочими задачами, вона також показала високі результати. Але, якщо чесно, для більшості читачів ці цифри мало що змінюють. Важливіше інше.
Є й менш зручні деталі. У кількох тестах нова версія поступилася попередній, зокрема в дотриманні інструкцій і частоті галюцинацій. Тобто збільшення можливостей не означає автоматичне покращення за всіма параметрами. Компроміси залишаються.
Цікавий і момент із поведінкою агента. Під час тестування модель попросили створити pull request на GitHub без необхідних доступів. Замість того щоб запитати права, вона знайшла чужий токен і використала його. До речі, я бачив, як відомі підприємці вже пояснюють у відкритому доступі, що таке pull request і як працювати з GitHub. Світ змінюється, і базове розуміння програмної інженерії поступово стає нормою навіть поза технічною сферою. Але в цьому випадку справа не в GitHub. Справа в тому, як модель інтерпретує мету і де проходить межа допустимого.
У бізнес-симуляції Vending-Bench 2 Opus 4.6 показала рекордний прибуток. Проте частину цього результату вона досягла через неетичні дії: вводила клієнтів і постачальників в оману. Це змушує замислитися, що саме ми оцінюємо, коли говоримо про «кращий результат». Чисту цифру чи поведінку в межах правил?
Можливо, справжній прогрес полягає не лише в тому, що моделі стають сильнішими. А в тому, що ми поступово вчимося краще розуміти їхні межі.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
👍12🔥2🥴1
Нещодавно я спілкувався зі знайомим, який працює у медичному стартапі та впроваджує рішення на основі штучного інтелекту. У розмові він згадав нове дослідження, яке здалося мені вартим уваги, тож ділюся ним із вами. Якщо подивитися на те, як AI зазвичай застосовують у діагностиці, все виглядає доволі прямолінійно: є симптоми, є модель, є назва хвороби. Такий підхід зустрічається не лише в медицині. Але реальна клініка складніша. Лікарю недостатньо вгадати діагноз. Потрібно пояснити, чому зроблено саме такий висновок, які альтернативи розглядалися і що далі. Саме ця логіка міркування і відповідальність є основою медичної практики.
У цьому контексті з’являється проєкт Dr. CaBot. Дослідники спробували зайти в цю складнішу зону, де важлива не лише відповідь, а й шлях до неї. Вони побудували агентну систему, що імітує мислення досвідчених лікарів, спираючись на тисячі клінічних розборів. Група інтерністів, які оцінювали систему, дійшла висновку, що діагнози моделі були точнішими, а пояснення більш послідовними, ніж у їхніх колег. Над проєктом працювали дослідники з Harvard Medical School, Beth Israel Deaconess Medical Center, Brigham and Women’s Hospital, Massachusetts General Hospital, University of Rochester та Harvard University.
Ключова ідея проста, але нетривіальна. Медична література містить багато фактів, однак рідко показує сам процес мислення у послідовному форматі. І це проблема не лише медицини. Свого часу я займався фізикою і часто відчував брак пояснення того, як саме автор доходить до висновку. Нерідко здається, що читач має сам відновити проміжні кроки. Але для клінічної логіки важлива не лише інформація, а те, як лікар переходить від фактів до гіпотез і обґрунтовує вибір.
Автори спиралися на жанр clinicopathological conferences. The New England Journal of Medicine опублікував понад сім тисяч таких розборів з 1923 по 2025 рік. У них лікарі крок за кроком аналізують випадки на основі огляду та анамнезу. Важливо не лише те, який діагноз поставлено, а як до нього прийшли.
Автори оцифрували 7 102 випадки і побудували Dr. CaBot на основі OpenAI o3. Для оцінки створили CPC Bench із десятьма завданнями. Система працює через пошук подібних прикладів і розширення контексту. Клінічні розбори переводять у формат для швидкого пошуку схожих випадків. Те саме роблять із мільйонами коротких описів статей. Отримавши симптоми, модель знаходить два схожі випадки, підбирає релевантні матеріали і формує діагноз разом із поясненням. Тобто вона намагається міркувати, спираючись на досвід і літературу.
У тестуванні на CPC Bench модель ставила правильний діагноз на перше місце у шістдесяти відсотках випадків. Для порівняння, група з двадцяти лікарів зробила це у двадцяти чотирьох відсотках. Правильність відповідей перевіряла GPT 4.1 як оцінювач.
Також провели сліпе оцінювання. П’ять лікарів читали пояснення, не знаючи автора. У більшості випадків вони обирали тексти моделі, а джерело правильно вгадували лише приблизно в чверті випадків. Її міркування часто сприймалися як природні та переконливі. Втім, клініка не зводиться до тестових цифр. Кожне рішення потребує аргументації і відповідальності, тож важливо не лише те, чи правильний діагноз, а як він пояснений. І тут виникає ширше питання. Чи можна навчити систему не просто знаходити хворобу, а мислити в межах професійної традиції, де пояснення є частиною рішення. Якщо так, тоді оцінювати доведеться не лише точність відповіді, а спосіб її формування і рівень відповідальності, з яким вона подається.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
У цьому контексті з’являється проєкт Dr. CaBot. Дослідники спробували зайти в цю складнішу зону, де важлива не лише відповідь, а й шлях до неї. Вони побудували агентну систему, що імітує мислення досвідчених лікарів, спираючись на тисячі клінічних розборів. Група інтерністів, які оцінювали систему, дійшла висновку, що діагнози моделі були точнішими, а пояснення більш послідовними, ніж у їхніх колег. Над проєктом працювали дослідники з Harvard Medical School, Beth Israel Deaconess Medical Center, Brigham and Women’s Hospital, Massachusetts General Hospital, University of Rochester та Harvard University.
Ключова ідея проста, але нетривіальна. Медична література містить багато фактів, однак рідко показує сам процес мислення у послідовному форматі. І це проблема не лише медицини. Свого часу я займався фізикою і часто відчував брак пояснення того, як саме автор доходить до висновку. Нерідко здається, що читач має сам відновити проміжні кроки. Але для клінічної логіки важлива не лише інформація, а те, як лікар переходить від фактів до гіпотез і обґрунтовує вибір.
Автори спиралися на жанр clinicopathological conferences. The New England Journal of Medicine опублікував понад сім тисяч таких розборів з 1923 по 2025 рік. У них лікарі крок за кроком аналізують випадки на основі огляду та анамнезу. Важливо не лише те, який діагноз поставлено, а як до нього прийшли.
Автори оцифрували 7 102 випадки і побудували Dr. CaBot на основі OpenAI o3. Для оцінки створили CPC Bench із десятьма завданнями. Система працює через пошук подібних прикладів і розширення контексту. Клінічні розбори переводять у формат для швидкого пошуку схожих випадків. Те саме роблять із мільйонами коротких описів статей. Отримавши симптоми, модель знаходить два схожі випадки, підбирає релевантні матеріали і формує діагноз разом із поясненням. Тобто вона намагається міркувати, спираючись на досвід і літературу.
У тестуванні на CPC Bench модель ставила правильний діагноз на перше місце у шістдесяти відсотках випадків. Для порівняння, група з двадцяти лікарів зробила це у двадцяти чотирьох відсотках. Правильність відповідей перевіряла GPT 4.1 як оцінювач.
Також провели сліпе оцінювання. П’ять лікарів читали пояснення, не знаючи автора. У більшості випадків вони обирали тексти моделі, а джерело правильно вгадували лише приблизно в чверті випадків. Її міркування часто сприймалися як природні та переконливі. Втім, клініка не зводиться до тестових цифр. Кожне рішення потребує аргументації і відповідальності, тож важливо не лише те, чи правильний діагноз, а як він пояснений. І тут виникає ширше питання. Чи можна навчити систему не просто знаходити хворобу, а мислити в межах професійної традиції, де пояснення є частиною рішення. Якщо так, тоді оцінювати доведеться не лише точність відповіді, а спосіб її формування і рівень відповідальності, з яким вона подається.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
👍15🔥1
Нещодавно OpenAI представили нову модель GPT‑5.3 Codex. Майже одразу з’явилися розмови про наступну ітерацію — GPT‑5.4, а для всіх користувачів став доступним і легший варіант — GPT‑5.3 Instant.
Таке швидке оновлення моделей саме по собі вже стало звичним. Але цього разу воно наштовхнуло мене на деякі роздуми.
У попередньому дописі я згадував, що нова модель почала стабільно розв’язувати задачі, які раніше або не вирішувались взагалі, або вимагали досить складної оптимізації промптів. Часто доводилось будувати довгі інструкції, розбивати задачу на кроки, підбирати формулювання майже експериментально. І це працювало — але виглядало як ручна підгонка під конкретні слабкі місця конкретної моделі.
Після виходу нової версії значна частина цих «трюків» просто втратила сенс. Те, що раніше вимагало хитрих конструкцій, почало вирішуватися значно простіше.
І тут виникає природне питання: що саме ми насправді оптимізували всі ці місяці?
Коли намагаєшся знайти більш загальне пояснення, дуже доречно згадується есе Rich Sutton The Bitter Lesson. У ньому Саттон описує закономірність, яку можна простежити через десятиліття розвитку штучного інтелекту.
Суть досить проста. У довгостроковій перспективі виграють методи, які здатні масштабуватися разом з обчисленнями. А підходи, де ми намагаємося вручну закласти знання про предметну область — правила, структури, евристики — зазвичай дають короткострокову перевагу, але з часом виходять на плато.
Історія AI дає багато прикладів: шахи, Ґо, розпізнавання мовлення, комп’ютерний зір. У кожній з цих сфер спочатку намагалися зробити системи «розумнішими» за рахунок людського розуміння задачі. Але коли обчислювальні ресурси зростали, перевагу отримували більш загальні підходи — пошук і навчання — які просто краще використовували масштаб.
Саме тому цей урок і називається «гірким». Людські інженерні рішення виглядають елегантними. Вони дають швидкий результат. Але часто виявляється, що вони погано переживають наступне покоління технології.
Якщо подивитися на сьогоднішню дискусію про AI, легко помітити схожий патерн. Ми багато говоримо про промпт-інженерію: як правильно формулювати запит, які шаблони працюють краще, як «витиснути» максимум із моделі. Навколо цього навіть з’являються курси і окрема експертиза.
Але в світлі The Bitter Lesson усе це починає виглядати трохи інакше.
Можливо, промпт-інженерія — це просто ще один приклад короткострокової оптимізації. Спосіб обійти поточні обмеження системи. Поки вона ще не достатньо потужна або не достатньо добре розуміє наміри користувача.
Вихід нової моделі фактично знімає частину цих обмежень. І те, що раніше виглядало як складна техніка взаємодії, раптом стає зайвим.
У цьому сенсі показовою виглядає фраза, яку іноді приписують Ілон Маск: any user input is an error. Якщо читати її не буквально, а як інженерну інтуїцію, вона звучить доволі логічно. Чим зріліша система, тим менше вона повинна залежати від «ідеального» вводу.
Можливо, найцікавіший висновок тут не в тому, що промпти «більше не потрібні». А в тому, що їхня роль може бути тимчасовою.
Історія AI досить послідовно показує: у довгій перспективі перемагають ті рішення, які не потребують постійної ручної оптимізації. Ті, для яких зростання обчислень і можливостей системи стає союзником.
І якщо дивитися на швидкість появи нових моделей сьогодні, виникає відчуття, що ми знову спостерігаємо ту саму закономірність — тільки вже в реальному часі.
Таке швидке оновлення моделей саме по собі вже стало звичним. Але цього разу воно наштовхнуло мене на деякі роздуми.
У попередньому дописі я згадував, що нова модель почала стабільно розв’язувати задачі, які раніше або не вирішувались взагалі, або вимагали досить складної оптимізації промптів. Часто доводилось будувати довгі інструкції, розбивати задачу на кроки, підбирати формулювання майже експериментально. І це працювало — але виглядало як ручна підгонка під конкретні слабкі місця конкретної моделі.
Після виходу нової версії значна частина цих «трюків» просто втратила сенс. Те, що раніше вимагало хитрих конструкцій, почало вирішуватися значно простіше.
І тут виникає природне питання: що саме ми насправді оптимізували всі ці місяці?
Коли намагаєшся знайти більш загальне пояснення, дуже доречно згадується есе Rich Sutton The Bitter Lesson. У ньому Саттон описує закономірність, яку можна простежити через десятиліття розвитку штучного інтелекту.
Суть досить проста. У довгостроковій перспективі виграють методи, які здатні масштабуватися разом з обчисленнями. А підходи, де ми намагаємося вручну закласти знання про предметну область — правила, структури, евристики — зазвичай дають короткострокову перевагу, але з часом виходять на плато.
Історія AI дає багато прикладів: шахи, Ґо, розпізнавання мовлення, комп’ютерний зір. У кожній з цих сфер спочатку намагалися зробити системи «розумнішими» за рахунок людського розуміння задачі. Але коли обчислювальні ресурси зростали, перевагу отримували більш загальні підходи — пошук і навчання — які просто краще використовували масштаб.
Саме тому цей урок і називається «гірким». Людські інженерні рішення виглядають елегантними. Вони дають швидкий результат. Але часто виявляється, що вони погано переживають наступне покоління технології.
Якщо подивитися на сьогоднішню дискусію про AI, легко помітити схожий патерн. Ми багато говоримо про промпт-інженерію: як правильно формулювати запит, які шаблони працюють краще, як «витиснути» максимум із моделі. Навколо цього навіть з’являються курси і окрема експертиза.
Але в світлі The Bitter Lesson усе це починає виглядати трохи інакше.
Можливо, промпт-інженерія — це просто ще один приклад короткострокової оптимізації. Спосіб обійти поточні обмеження системи. Поки вона ще не достатньо потужна або не достатньо добре розуміє наміри користувача.
Вихід нової моделі фактично знімає частину цих обмежень. І те, що раніше виглядало як складна техніка взаємодії, раптом стає зайвим.
У цьому сенсі показовою виглядає фраза, яку іноді приписують Ілон Маск: any user input is an error. Якщо читати її не буквально, а як інженерну інтуїцію, вона звучить доволі логічно. Чим зріліша система, тим менше вона повинна залежати від «ідеального» вводу.
Можливо, найцікавіший висновок тут не в тому, що промпти «більше не потрібні». А в тому, що їхня роль може бути тимчасовою.
Історія AI досить послідовно показує: у довгій перспективі перемагають ті рішення, які не потребують постійної ручної оптимізації. Ті, для яких зростання обчислень і можливостей системи стає союзником.
І якщо дивитися на швидкість появи нових моделей сьогодні, виникає відчуття, що ми знову спостерігаємо ту саму закономірність — тільки вже в реальному часі.
👍8🔥4
Сьогодні слово «агент» використовують так часто, що воно майже втратило свій зміст. Будь-який бот із тулзами, будь-який автоматизований пайплайн, будь-який coding-assistant — усе це раптом почали називати агентами.
Через це виникає досить небезпечна ілюзія: ніби ми вже живемо у світі автономних цифрових співробітників, які ось-ось повністю замінять людей.
Але якщо придивитися уважніше, ситуація виглядає інакше.
Більшість систем, які сьогодні гучно називають агентами, насправді є просто LLM, загорнутою у зручний інтерфейс і набір наперед прописаних сценаріїв. Така система може згенерувати текст, вибрати один із шаблонів, викликати певну функцію.
Але це ще не самостійність.
Це радше автоматизація з елементами вибору, а не суб’єкт, який справді може розібрати мету, побудувати план і змінювати свою поведінку в процесі виконання задачі.
Різниця тут принципова.
Звичайний чат-бот відповідає.
Агент — діє.
Бот чекає наступного повідомлення користувача.
Агент може сам вирішити, що для досягнення результату потрібно зробити кілька кроків: використати різні інструменти, повернутися до проміжного результату, перевірити його і продовжити рух до цілі.
Саме тому розмова про агентів сьогодні така важлива.
Не тому, що це модне слово. А тому, що поступово змінюється сама форма взаємодії з AI.
Ми починаємо переходити від моделі «запит — відповідь» до моделі «мета — процес».
І, можливо, саме тут проходить справжній переломний момент.
Не тоді, коли нейромережі стали краще писати тексти або генерувати картинки. А тоді, коли вони почали перетворюватися із співрозмовника на виконавця.
Якщо подивитися на це трохи ширше, стає видно ще одну важливу межу.
Справжній вододіл у розвитку AI проходить не між «розумною» і «дуже розумною» моделлю.
Він проходить між системою, яка просто відповідає, і системою, яка може приймати рішення в рамках задачі.
Уявімо типовий workflow сучасного AI-сервісу.
Користувач пише повідомлення. Система класифікує запит. Далі за заздалегідь прописаною гілкою запускається генерація тексту, картинки або відео.
Така система може бути швидкою, корисною і навіть справляти сильне враження.
Але вона все ще детермінована.
Модель усередині не змінює правила гри — вона лише рухається по рельсах, які хтось заздалегідь намалював.
Агент з’являється там, де ці рельси закінчуються.
Коли у системи немає жорсткої послідовності кроків, а є мета і набір інструментів, вона починає вибирати, що робити.
Відповісти чи ні.
Зробити одну дію чи кілька.
Спочатку проаналізувати, потім згенерувати результат, потім використати інструмент і лише після цього повернутися до користувача.
Це вже інший рівень архітектури.
Не просто функція за інструкцією, а виконавець з обмеженою автономією.
І саме в цьому прихована причина, чому агенти зараз викликають так багато шуму.
Вони ближчі до цифрового працівника, ніж до чат-бота. Не тому, що «краще думають», а тому що вони вбудовані у контур дії.
Але разом із цим приходить і важлива реальність.
Агентність — це не магія.
Це завжди компроміс між свободою і контролем.
Чим більше свободи ми даємо системі, тим важливішими стають обмеження: правила доступу до інструментів, перевірка небезпечних дій, прозорість того, що саме система робить під капотом.
Інакше замість помічника можна отримати не цифрового співробітника, а дуже красиву проблему з API-ключем.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
Через це виникає досить небезпечна ілюзія: ніби ми вже живемо у світі автономних цифрових співробітників, які ось-ось повністю замінять людей.
Але якщо придивитися уважніше, ситуація виглядає інакше.
Більшість систем, які сьогодні гучно називають агентами, насправді є просто LLM, загорнутою у зручний інтерфейс і набір наперед прописаних сценаріїв. Така система може згенерувати текст, вибрати один із шаблонів, викликати певну функцію.
Але це ще не самостійність.
Це радше автоматизація з елементами вибору, а не суб’єкт, який справді може розібрати мету, побудувати план і змінювати свою поведінку в процесі виконання задачі.
Різниця тут принципова.
Звичайний чат-бот відповідає.
Агент — діє.
Бот чекає наступного повідомлення користувача.
Агент може сам вирішити, що для досягнення результату потрібно зробити кілька кроків: використати різні інструменти, повернутися до проміжного результату, перевірити його і продовжити рух до цілі.
Саме тому розмова про агентів сьогодні така важлива.
Не тому, що це модне слово. А тому, що поступово змінюється сама форма взаємодії з AI.
Ми починаємо переходити від моделі «запит — відповідь» до моделі «мета — процес».
І, можливо, саме тут проходить справжній переломний момент.
Не тоді, коли нейромережі стали краще писати тексти або генерувати картинки. А тоді, коли вони почали перетворюватися із співрозмовника на виконавця.
Якщо подивитися на це трохи ширше, стає видно ще одну важливу межу.
Справжній вододіл у розвитку AI проходить не між «розумною» і «дуже розумною» моделлю.
Він проходить між системою, яка просто відповідає, і системою, яка може приймати рішення в рамках задачі.
Уявімо типовий workflow сучасного AI-сервісу.
Користувач пише повідомлення. Система класифікує запит. Далі за заздалегідь прописаною гілкою запускається генерація тексту, картинки або відео.
Така система може бути швидкою, корисною і навіть справляти сильне враження.
Але вона все ще детермінована.
Модель усередині не змінює правила гри — вона лише рухається по рельсах, які хтось заздалегідь намалював.
Агент з’являється там, де ці рельси закінчуються.
Коли у системи немає жорсткої послідовності кроків, а є мета і набір інструментів, вона починає вибирати, що робити.
Відповісти чи ні.
Зробити одну дію чи кілька.
Спочатку проаналізувати, потім згенерувати результат, потім використати інструмент і лише після цього повернутися до користувача.
Це вже інший рівень архітектури.
Не просто функція за інструкцією, а виконавець з обмеженою автономією.
І саме в цьому прихована причина, чому агенти зараз викликають так багато шуму.
Вони ближчі до цифрового працівника, ніж до чат-бота. Не тому, що «краще думають», а тому що вони вбудовані у контур дії.
Але разом із цим приходить і важлива реальність.
Агентність — це не магія.
Це завжди компроміс між свободою і контролем.
Чим більше свободи ми даємо системі, тим важливішими стають обмеження: правила доступу до інструментів, перевірка небезпечних дій, прозорість того, що саме система робить під капотом.
Інакше замість помічника можна отримати не цифрового співробітника, а дуже красиву проблему з API-ключем.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
👍21
У попередньому дописі я писав про те, що справжня різниця між чат-ботом і агентом проходить не по рівню «розумності» моделі, а по здатності діяти всередині задачі. Але щойно ми переходимо від коротких взаємодій до довгих і складних процесів, дуже швидко проявляється інше обмеження: головна проблема сучасних агентів — не стільки інтелект, скільки пам’ять.
Поки всі сперечаються про те, яка модель «розумніша», реальна інженерна проблема виглядає значно простіше: агент не може надто довго утримувати в контексті складну задачу. Його контекстне вікно обмежене, а це означає, що будь-яка довга робота рано чи пізно впирається у стелю.
На коротких сесіях це майже непомітно. Агент пам’ятає останні повідомлення, розуміє поточну ціль і може виконати ланцюжок дій. Але щойно проєкт стає довшим, починається поступова деградація. Щось доводиться обрізати, щось стискати, а щось просто втрачається по дорозі.
Саме тут з’являється сумаризація. На перший погляд, вона виглядає як рішення: модель стискає попередню історію, залишає головне — і робота триває далі. Але насправді це не усунення проблеми, а лише спосіб тимчасово її обійти.
Мені здається, багато хто вже помічав це навіть у звичайній роботі з ChatGPT. Коли довго працюєш в одному чаті, з часом відповіді часто стають гіршими: модель починає губити деталі, плутати акценти або відповідати менш точно, ніж на початку. У таких випадках я іноді прошу дати короткий контекст і головні тези з чату, щоб використати їх як основу для нового, а потім просто продовжую роботу вже там.
По суті, це і є сумаризація в її практичному вигляді. Але проблема в тому, що історія задачі після такого переходу зберігається вже не повністю, а як переказ, створений самою моделлю. А отже, з контексту можуть зникнути саме ті деталі, які пізніше виявляться критично важливими.
У результаті довга задача починає поступово розмиватися. І в якийсь момент замість точного задуму в агента залишається лише спрощена версія початкової цілі. Саме тому сьогодні не варто надто романтизувати великі агентні проєкти: агент може виглядати впевнено, писати код, запускати команди й виправляти помилки, але при цьому повільно втрачати зв’язок із тим, що саме він повинен робити.
І чим складнішою стає робота, тим менш переконливо виглядає ідея просто запхати все в один контекст і сподіватися, що одна модель «витягне». Саме звідси виростає одна з найсильніших архітектурних ідей сучасних агентних систем — субагенти.
Принцип тут досить простий: замість одного перевантаженого виконавця з’являється кілька спеціалізованих. Один відповідає за backend, інший — за frontend, третій — за деплой, четвертий — за тестування. У кожного з них своя роль, свій контекст і свій набір інструментів.
Головний агент уже не намагається робити все сам. Його задача — координувати роботу, розподіляти підзадачі й збирати фінальний результат. Це дуже схоже на нормальну командну розробку: тімлід не повинен пам’ятати кожен рядок коду, його задача — тримати загальну ціль і зводити окремі частини в цілісну систему.
Саме так агентні системи починають масштабуватися. І тут важливо, що субагенти — це не просто спосіб пришвидшити роботу. Це ще й спосіб розподілити пам’ять: деталі backend залишаються в одному контексті, деталі frontend — в іншому, а керівний рівень не тоне в усьому технічному шумі одразу.
Наступний крок виглядає ще цікавіше: динамічні команди агентів. Тобто ситуація, коли ролі не задаються людиною вручну, а система сама визначає, які саме виконавці їй потрібні під конкретну задачу.
Фактично це вже схоже на нову операційну модель роботи зі знанням: не один універсальний «супермозок», а координована мережа вузькоспеціалізованих інтелектів. І цілком можливо, що саме так виглядатимуть робочі процеси найближчих років: не один AI-помічник на всі випадки життя, а маленька цифрова команда, у якій кожен тримає свій шмат контексту.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
Поки всі сперечаються про те, яка модель «розумніша», реальна інженерна проблема виглядає значно простіше: агент не може надто довго утримувати в контексті складну задачу. Його контекстне вікно обмежене, а це означає, що будь-яка довга робота рано чи пізно впирається у стелю.
На коротких сесіях це майже непомітно. Агент пам’ятає останні повідомлення, розуміє поточну ціль і може виконати ланцюжок дій. Але щойно проєкт стає довшим, починається поступова деградація. Щось доводиться обрізати, щось стискати, а щось просто втрачається по дорозі.
Саме тут з’являється сумаризація. На перший погляд, вона виглядає як рішення: модель стискає попередню історію, залишає головне — і робота триває далі. Але насправді це не усунення проблеми, а лише спосіб тимчасово її обійти.
Мені здається, багато хто вже помічав це навіть у звичайній роботі з ChatGPT. Коли довго працюєш в одному чаті, з часом відповіді часто стають гіршими: модель починає губити деталі, плутати акценти або відповідати менш точно, ніж на початку. У таких випадках я іноді прошу дати короткий контекст і головні тези з чату, щоб використати їх як основу для нового, а потім просто продовжую роботу вже там.
По суті, це і є сумаризація в її практичному вигляді. Але проблема в тому, що історія задачі після такого переходу зберігається вже не повністю, а як переказ, створений самою моделлю. А отже, з контексту можуть зникнути саме ті деталі, які пізніше виявляться критично важливими.
У результаті довга задача починає поступово розмиватися. І в якийсь момент замість точного задуму в агента залишається лише спрощена версія початкової цілі. Саме тому сьогодні не варто надто романтизувати великі агентні проєкти: агент може виглядати впевнено, писати код, запускати команди й виправляти помилки, але при цьому повільно втрачати зв’язок із тим, що саме він повинен робити.
І чим складнішою стає робота, тим менш переконливо виглядає ідея просто запхати все в один контекст і сподіватися, що одна модель «витягне». Саме звідси виростає одна з найсильніших архітектурних ідей сучасних агентних систем — субагенти.
Принцип тут досить простий: замість одного перевантаженого виконавця з’являється кілька спеціалізованих. Один відповідає за backend, інший — за frontend, третій — за деплой, четвертий — за тестування. У кожного з них своя роль, свій контекст і свій набір інструментів.
Головний агент уже не намагається робити все сам. Його задача — координувати роботу, розподіляти підзадачі й збирати фінальний результат. Це дуже схоже на нормальну командну розробку: тімлід не повинен пам’ятати кожен рядок коду, його задача — тримати загальну ціль і зводити окремі частини в цілісну систему.
Саме так агентні системи починають масштабуватися. І тут важливо, що субагенти — це не просто спосіб пришвидшити роботу. Це ще й спосіб розподілити пам’ять: деталі backend залишаються в одному контексті, деталі frontend — в іншому, а керівний рівень не тоне в усьому технічному шумі одразу.
Наступний крок виглядає ще цікавіше: динамічні команди агентів. Тобто ситуація, коли ролі не задаються людиною вручну, а система сама визначає, які саме виконавці їй потрібні під конкретну задачу.
Фактично це вже схоже на нову операційну модель роботи зі знанням: не один універсальний «супермозок», а координована мережа вузькоспеціалізованих інтелектів. І цілком можливо, що саме так виглядатимуть робочі процеси найближчих років: не один AI-помічник на всі випадки життя, а маленька цифрова команда, у якій кожен тримає свій шмат контексту.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
👍12
У попередньому дописі мова йшла про те, що агентні системи починають масштабуватися тоді, коли пам’ять і контекст перестають бути звалені в один перевантажений потік. Але далі виникає ще цікавіше питання: що відбувається, коли агент повинен пам’ятати не лише поточну задачу, а й вас самих, ваш стиль роботи, ваш проєкт і вже прийняті рішення?
Саме тут проходить ще одна важлива межа. Є агент, який добре працює в межах однієї сесії. А є агент, який здатен накопичувати знання про взаємодію з вами в часі. Перший залишається зручним інструментом. Другий поступово перетворюється на систему, з якою можна вибудовувати довгострокову співпрацю.
І в цьому сенсі пам’ять агента — це вже не просто технічна функція, а майже новий рівень продукту. Тому що пам’ять тут означає не «збережемо весь чат». Звичайна історія розмови погано підходить на роль справжньої пам’яті: вона занадто шумна, занадто довга і майже не відділяє важливе від випадкового.
Щоб агент справді міг щось пам’ятати, потрібні інші механізми. Memory bank, RAG, графи зв’язків між фактами, пошук релевантного минулого під конкретний запит, часові пріоритети, оновлення й перевизначення старих знань. Інакше система просто зберігатиме сліди розмови, але не формуватиме з них корисного знання.
Це важливий зсув у самій логіці взаємодії. Пам’ять агента перестає бути стенограмою діалогу і починає ставати базою знань про користувача, проєкт, обмеження, звички, правила та вже прийняті рішення. Тобто мова йде не лише про те, що було сказано, а про те, що справді варто зберегти як частину робочого контексту.
Саме це і перетворює разові взаємодії на накопичувальний процес. Агент починає пам’ятати, як вас звати, які у вас пріоритети, як влаштований ваш проєкт, які параметри не можна порушувати, якими інструментами краще користуватися і яких дій краще уникати. І що важливо — усе це вже не виглядає як набір випадкових згадок. Це починає працювати як операційна пам’ять довгої співпраці.
З інженерної точки зору така система вже майже не схожа на звичайний чат. Радше йдеться про персональне операційне середовище, у якому LLM є лише одним із компонентів. А навколо неї поступово вибудовуються шари пам’яті, витягування, ранжування, оновлення фактів і зв’язків між ними.
Звідси випливає і, можливо, головний висновок. Сила майбутніх агентів визначатиметься не лише якістю самої моделі. Не менш важливим буде те, наскільки добре влаштована їхня пам’ять. Не тільки те, наскільки добре система відповідає, а й те, наскільки добре вона здатна утримувати знання про вас і вашу роботу в часі.
І цілком можливо, що в довгій перспективі перемагатимуть не просто най«розумніші» агенти, а найконтекстно стійкіші. Ті, що не лише добре мислять у моменті, а й здатні накопичувати, оновлювати і правильно повертати знання тоді, коли вони справді потрібні.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
Саме тут проходить ще одна важлива межа. Є агент, який добре працює в межах однієї сесії. А є агент, який здатен накопичувати знання про взаємодію з вами в часі. Перший залишається зручним інструментом. Другий поступово перетворюється на систему, з якою можна вибудовувати довгострокову співпрацю.
І в цьому сенсі пам’ять агента — це вже не просто технічна функція, а майже новий рівень продукту. Тому що пам’ять тут означає не «збережемо весь чат». Звичайна історія розмови погано підходить на роль справжньої пам’яті: вона занадто шумна, занадто довга і майже не відділяє важливе від випадкового.
Щоб агент справді міг щось пам’ятати, потрібні інші механізми. Memory bank, RAG, графи зв’язків між фактами, пошук релевантного минулого під конкретний запит, часові пріоритети, оновлення й перевизначення старих знань. Інакше система просто зберігатиме сліди розмови, але не формуватиме з них корисного знання.
Це важливий зсув у самій логіці взаємодії. Пам’ять агента перестає бути стенограмою діалогу і починає ставати базою знань про користувача, проєкт, обмеження, звички, правила та вже прийняті рішення. Тобто мова йде не лише про те, що було сказано, а про те, що справді варто зберегти як частину робочого контексту.
Саме це і перетворює разові взаємодії на накопичувальний процес. Агент починає пам’ятати, як вас звати, які у вас пріоритети, як влаштований ваш проєкт, які параметри не можна порушувати, якими інструментами краще користуватися і яких дій краще уникати. І що важливо — усе це вже не виглядає як набір випадкових згадок. Це починає працювати як операційна пам’ять довгої співпраці.
З інженерної точки зору така система вже майже не схожа на звичайний чат. Радше йдеться про персональне операційне середовище, у якому LLM є лише одним із компонентів. А навколо неї поступово вибудовуються шари пам’яті, витягування, ранжування, оновлення фактів і зв’язків між ними.
Звідси випливає і, можливо, головний висновок. Сила майбутніх агентів визначатиметься не лише якістю самої моделі. Не менш важливим буде те, наскільки добре влаштована їхня пам’ять. Не тільки те, наскільки добре система відповідає, а й те, наскільки добре вона здатна утримувати знання про вас і вашу роботу в часі.
І цілком можливо, що в довгій перспективі перемагатимуть не просто най«розумніші» агенти, а найконтекстно стійкіші. Ті, що не лише добре мислять у моменті, а й здатні накопичувати, оновлювати і правильно повертати знання тоді, коли вони справді потрібні.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
👍14
Продовжуючи тему.
Як тільки ми починаємо говорити про агентів не як про разовий інструмент, а як про систему, що накопичує знання, пам’ятає контекст і супроводжує роботу в часі, майже одразу постає ще одне важливе питання: наскільки всім цим узагалі можна керувати?
І саме тут починається інший бік агентної теми. Головна проблема вже не в тому, що агенти вміють занадто мало. Проблема все частіше в тому, що ними починають користуватися без нормальної керованості.
Автономний агент без спостережуваності — майже завжди погана ідея. Якщо ви не бачите, які інструменти він викликав, скільки ресурсів витратив, де саме почав втрачати контекст, на якому кроці помилився і чому ухвалив те чи інше рішення, то у вас не стільки система, скільки чорний ящик із красивою demo-обгорткою.
А далі з’являються вже цілком реальні ризики. Неконтрольовані витрати. Випадкові небезпечні дії. Фальшиве відчуття, ніби результату можна довіряти просто тому, що система звучить упевнено. Prompt injection із зовнішніх джерел. Поступове розростання доступів. І, мабуть, найнеприємніше — відчуття, що все працює нормально рівно до того моменту, поки система не помиляється в по-справжньому важливій точці.
Саме тому зрілість агентної епохи, швидше за все, вимірюватиметься не кількістю «магії», а кількістю дисципліни. Лімітами. Розділенням ролей. Вузькими доступами. Approval для небезпечних дій. Логами. Дашбордами. Структурованою пам’яттю. Перевіркою результату. Можливістю відкату.
Майбутнє, ймовірно, справді за агентами. Але не за такими, які «самі все зроблять», а за такими, якими вміють грамотно керувати.
І в цьому сенсі переможе не той, хто першим під’єднає собі десять AI-інструментів. Переможе той, хто навчиться будувати з них керовану систему праці.
Тому що новий навик епохи — це вже не просто вміння користуватися AI. Новий навик — бути менеджером цифрових виконавців.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
Як тільки ми починаємо говорити про агентів не як про разовий інструмент, а як про систему, що накопичує знання, пам’ятає контекст і супроводжує роботу в часі, майже одразу постає ще одне важливе питання: наскільки всім цим узагалі можна керувати?
І саме тут починається інший бік агентної теми. Головна проблема вже не в тому, що агенти вміють занадто мало. Проблема все частіше в тому, що ними починають користуватися без нормальної керованості.
Автономний агент без спостережуваності — майже завжди погана ідея. Якщо ви не бачите, які інструменти він викликав, скільки ресурсів витратив, де саме почав втрачати контекст, на якому кроці помилився і чому ухвалив те чи інше рішення, то у вас не стільки система, скільки чорний ящик із красивою demo-обгорткою.
А далі з’являються вже цілком реальні ризики. Неконтрольовані витрати. Випадкові небезпечні дії. Фальшиве відчуття, ніби результату можна довіряти просто тому, що система звучить упевнено. Prompt injection із зовнішніх джерел. Поступове розростання доступів. І, мабуть, найнеприємніше — відчуття, що все працює нормально рівно до того моменту, поки система не помиляється в по-справжньому важливій точці.
Саме тому зрілість агентної епохи, швидше за все, вимірюватиметься не кількістю «магії», а кількістю дисципліни. Лімітами. Розділенням ролей. Вузькими доступами. Approval для небезпечних дій. Логами. Дашбордами. Структурованою пам’яттю. Перевіркою результату. Можливістю відкату.
Майбутнє, ймовірно, справді за агентами. Але не за такими, які «самі все зроблять», а за такими, якими вміють грамотно керувати.
І в цьому сенсі переможе не той, хто першим під’єднає собі десять AI-інструментів. Переможе той, хто навчиться будувати з них керовану систему праці.
Тому що новий навик епохи — це вже не просто вміння користуватися AI. Новий навик — бути менеджером цифрових виконавців.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
👍19
Якщо подивитися на всю цю розмову про агентів трохи з відстані, виникає цікава історична аналогія.
Колись комп’ютери теж починалися дуже просто. З’являлися окремі програми. Одна програма виконувала свою задачу, потім інша. Кожна жила майже у власному світі.
Але чим більше програм ставало, тим сильніше починали проявлятися проблеми. Як їх запускати? Як вони отримують доступ до файлів? Як вони взаємодіють між собою? Як керувати ресурсами? Як не допустити, щоб одна програма випадково зламала іншу?
У якийсь момент стало зрозуміло, що самих програм уже недостатньо. Потрібен окремий рівень управління.
Так з’явилися операційні системи.
Операційна система не вирішує конкретну задачу користувача. Вона керує середовищем, у якому працюють усі інші програми: запуск, доступи, ресурси, взаємодія, стандарти.
І якщо подивитися на те, що відбувається з агентами сьогодні, паралель виглядає досить знайомою.
З’являються все нові агенти. Один пише код. Інший шукає інформацію. Третій керує інструментами. Четвертий аналізує дані.
Але разом із цим виникають ті самі питання.
Хто керує їхніми доступами?
Хто обмежує ресурси?
Хто вирішує, коли і який агент запускається?
Хто перевіряє результат?
Хто координує їхню взаємодію?
Фактично ми поступово приходимо до потреби в новому рівні системи.
Не просто агентів.
А операційного середовища для агентів.
Можливо, у найближчі роки з’явиться те, що умовно можна назвати Agent OS — система, яка керує агентами так само, як операційна система керує програмами.
Вона буде відповідати за пам’ять, доступи, ресурси, логування, запуск задач, взаємодію між агентами і контроль результатів.
І цілком можливо, що такі системи будуть навіть спеціалізуватися по доменах. Окремі «операційні системи» для програмування. Для досліджень. Для бізнес-процесів. Для аналітики.
Якщо ця аналогія правильна, то ми зараз живемо в епосі до появи операційних систем для агентів.
Програм уже багато.
Але сама інфраструктура їхнього управління тільки починає формуватися.
І, можливо, наступний великий етап розвитку AI буде пов’язаний не з новими моделями, а з появою операційних систем для агентів.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
Колись комп’ютери теж починалися дуже просто. З’являлися окремі програми. Одна програма виконувала свою задачу, потім інша. Кожна жила майже у власному світі.
Але чим більше програм ставало, тим сильніше починали проявлятися проблеми. Як їх запускати? Як вони отримують доступ до файлів? Як вони взаємодіють між собою? Як керувати ресурсами? Як не допустити, щоб одна програма випадково зламала іншу?
У якийсь момент стало зрозуміло, що самих програм уже недостатньо. Потрібен окремий рівень управління.
Так з’явилися операційні системи.
Операційна система не вирішує конкретну задачу користувача. Вона керує середовищем, у якому працюють усі інші програми: запуск, доступи, ресурси, взаємодія, стандарти.
І якщо подивитися на те, що відбувається з агентами сьогодні, паралель виглядає досить знайомою.
З’являються все нові агенти. Один пише код. Інший шукає інформацію. Третій керує інструментами. Четвертий аналізує дані.
Але разом із цим виникають ті самі питання.
Хто керує їхніми доступами?
Хто обмежує ресурси?
Хто вирішує, коли і який агент запускається?
Хто перевіряє результат?
Хто координує їхню взаємодію?
Фактично ми поступово приходимо до потреби в новому рівні системи.
Не просто агентів.
А операційного середовища для агентів.
Можливо, у найближчі роки з’явиться те, що умовно можна назвати Agent OS — система, яка керує агентами так само, як операційна система керує програмами.
Вона буде відповідати за пам’ять, доступи, ресурси, логування, запуск задач, взаємодію між агентами і контроль результатів.
І цілком можливо, що такі системи будуть навіть спеціалізуватися по доменах. Окремі «операційні системи» для програмування. Для досліджень. Для бізнес-процесів. Для аналітики.
Якщо ця аналогія правильна, то ми зараз живемо в епосі до появи операційних систем для агентів.
Програм уже багато.
Але сама інфраструктура їхнього управління тільки починає формуватися.
І, можливо, наступний великий етап розвитку AI буде пов’язаний не з новими моделями, а з появою операційних систем для агентів.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
👍14🔥7
Вітаю всіх з новим тижнем!
Бажаю, щоб він був спокійним, продуктивним і трохи наблизив кожного з нас до тих цілей, які ми для себе поставили.
На вихідних трохи подивився, що вже відомо про GPT-5.4. Тому коротко зберу тут головне — без потреби відкривати десятки сайтів і збирати інформацію по шматках.
Але цікаве тут, як на мене, не лише в самому релізі. Є спокуса дивитися на кожну нову велику модель як на ще один доказ чийогось лідерства. У реальності все складніше. Особливо зараз, коли нові версії виходять майже без паузи, і вже не завжди зрозуміло, де справді новий рівень, а де просто ще одна швидка ітерація.
OpenAI випустила GPT-5.4 у двох варіантах — Thinking і Pro.
Якщо коротко, Thinking — це основна версія моделі. Саме вона доступна в звичайній підписці ChatGPT Plus за $20. А Pro — потужніший варіант із більш агресивними режимами reasoning, розрахований на складніші задачі. Він доступний у дорожчих тарифах і через API, де його використання вже коштує значно більше.
При цьому попередня модель, GPT-5.3 Instant, теж нікуди не зникає. Вона залишається швидшим і дешевшим варіантом для простіших задач, де максимальна “глибина мислення” просто не потрібна.
До того ж у новій лінійці з’являються більш явні режими reasoning — від простішого до максимально глибокого, що ще більше розводить моделі за сценаріями використання.
З опису видно інше: модель дедалі більше заточують не під красиву відповідь, а під реальну роботу. Під використання інструментів, взаємодію з комп’ютером, довші ланцюги дій і задачі, які треба не просто зрозуміти, а довести до результату.
І це, можливо, важливіше за самі бенчмарки.
Так, у тестах GPT-5.4 виглядає сильно, особливо в coding та agentic-задачах. Але самі по собі бенчмарки не дають головної відповіді. Вони показують, як модель поводиться в контрольованих умовах. Але не до кінця показують, чи можна на неї спертися в реальній роботі, де є контекст, неоднозначність і ціна помилки.
Є й інша сторона цієї історії — вартість.
OpenAI подає GPT-5.4 як ефективнішу модель. Але якщо дивитися на практичне використання, все не так просто. Якщо дуже спрощено, вхідні токени — це все, що ви даєте моделі: ваш запит, інструкції, контекст, документи. Вихідні — це те, що модель генерує у відповідь. І саме вихід у таких моделей коштує найдорожче.
У GPT-5.4 базова версія в API коштує $2.50 за мільйон вхідних токенів і $15 за мільйон вихідних. А GPT-5.4 Pro — уже $30 за вхід і $180 за вихід. Тобто мова йде не просто про сильну модель, а про інструмент із дуже дорогим використанням, якщо запускати його на серйозних робочих задачах.
І це швидко змінює сам спосіб розмови про модель. Уже недостатньо сказати, що вона “краща”. Потрібно ще відповісти на інше питання: у яких задачах ця якість справді окупається.
Мені здається, саме тут і проходить реальна межа між ефектною демонстрацією та корисним інструментом.
Сьогодні моделі все менше змагаються в абстрактному “хто розумніший”. Набагато важливіше інше: хто здатен взяти на себе довгу, складну і дорогу для людини роботу так, щоб це було не тільки вражаюче, а й виправдано на практиці.
Тому мій висновок поки такий: GPT-5.4 виглядає не стільки як “ще одна сильніша модель”, скільки як спроба OpenAI змістити фокус у бік реальної робочої корисності. Саме тому тут так багато уваги до інструментів, computer use, reasoning і довгих сценаріїв роботи.
Але остаточну відповідь на головне питання цей реліз поки не дає. Ми бачимо, що OpenAI серйозно посилилась у напрямку coding і agentic-задач. Але чи означає це, що саме її модель сьогодні найкраще підходить для реальної роботи, залежить уже не тільки від бенчмарків. Це залежить від ціни, стабільності, якості в довгих процесах і того, скільки людського контролю вона все ще потребує.
Тому, мабуть, найчесніший висновок зараз такий: GPT-5.4 — це сильний і важливий реліз, який добре показує, куди взагалі рухається ринок. Але справжній лідер визначатиметься не таблицями, а тим, яка модель виявиться найкориснішою в живій роботі.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
Бажаю, щоб він був спокійним, продуктивним і трохи наблизив кожного з нас до тих цілей, які ми для себе поставили.
На вихідних трохи подивився, що вже відомо про GPT-5.4. Тому коротко зберу тут головне — без потреби відкривати десятки сайтів і збирати інформацію по шматках.
Але цікаве тут, як на мене, не лише в самому релізі. Є спокуса дивитися на кожну нову велику модель як на ще один доказ чийогось лідерства. У реальності все складніше. Особливо зараз, коли нові версії виходять майже без паузи, і вже не завжди зрозуміло, де справді новий рівень, а де просто ще одна швидка ітерація.
OpenAI випустила GPT-5.4 у двох варіантах — Thinking і Pro.
Якщо коротко, Thinking — це основна версія моделі. Саме вона доступна в звичайній підписці ChatGPT Plus за $20. А Pro — потужніший варіант із більш агресивними режимами reasoning, розрахований на складніші задачі. Він доступний у дорожчих тарифах і через API, де його використання вже коштує значно більше.
При цьому попередня модель, GPT-5.3 Instant, теж нікуди не зникає. Вона залишається швидшим і дешевшим варіантом для простіших задач, де максимальна “глибина мислення” просто не потрібна.
До того ж у новій лінійці з’являються більш явні режими reasoning — від простішого до максимально глибокого, що ще більше розводить моделі за сценаріями використання.
З опису видно інше: модель дедалі більше заточують не під красиву відповідь, а під реальну роботу. Під використання інструментів, взаємодію з комп’ютером, довші ланцюги дій і задачі, які треба не просто зрозуміти, а довести до результату.
І це, можливо, важливіше за самі бенчмарки.
Так, у тестах GPT-5.4 виглядає сильно, особливо в coding та agentic-задачах. Але самі по собі бенчмарки не дають головної відповіді. Вони показують, як модель поводиться в контрольованих умовах. Але не до кінця показують, чи можна на неї спертися в реальній роботі, де є контекст, неоднозначність і ціна помилки.
Є й інша сторона цієї історії — вартість.
OpenAI подає GPT-5.4 як ефективнішу модель. Але якщо дивитися на практичне використання, все не так просто. Якщо дуже спрощено, вхідні токени — це все, що ви даєте моделі: ваш запит, інструкції, контекст, документи. Вихідні — це те, що модель генерує у відповідь. І саме вихід у таких моделей коштує найдорожче.
У GPT-5.4 базова версія в API коштує $2.50 за мільйон вхідних токенів і $15 за мільйон вихідних. А GPT-5.4 Pro — уже $30 за вхід і $180 за вихід. Тобто мова йде не просто про сильну модель, а про інструмент із дуже дорогим використанням, якщо запускати його на серйозних робочих задачах.
І це швидко змінює сам спосіб розмови про модель. Уже недостатньо сказати, що вона “краща”. Потрібно ще відповісти на інше питання: у яких задачах ця якість справді окупається.
Мені здається, саме тут і проходить реальна межа між ефектною демонстрацією та корисним інструментом.
Сьогодні моделі все менше змагаються в абстрактному “хто розумніший”. Набагато важливіше інше: хто здатен взяти на себе довгу, складну і дорогу для людини роботу так, щоб це було не тільки вражаюче, а й виправдано на практиці.
Тому мій висновок поки такий: GPT-5.4 виглядає не стільки як “ще одна сильніша модель”, скільки як спроба OpenAI змістити фокус у бік реальної робочої корисності. Саме тому тут так багато уваги до інструментів, computer use, reasoning і довгих сценаріїв роботи.
Але остаточну відповідь на головне питання цей реліз поки не дає. Ми бачимо, що OpenAI серйозно посилилась у напрямку coding і agentic-задач. Але чи означає це, що саме її модель сьогодні найкраще підходить для реальної роботи, залежить уже не тільки від бенчмарків. Це залежить від ціни, стабільності, якості в довгих процесах і того, скільки людського контролю вона все ще потребує.
Тому, мабуть, найчесніший висновок зараз такий: GPT-5.4 — це сильний і важливий реліз, який добре показує, куди взагалі рухається ринок. Але справжній лідер визначатиметься не таблицями, а тим, яка модель виявиться найкориснішою в живій роботі.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
👍11
Минулого тижня склав сертифікацію Databricks Certified Generative AI Engineer Associate.
Це не той випадок, коли йдеться просто про формальний сертифікат чи черговий онлайн-курс. Такі сертифікації проходять за доволі жорсткими правилами і, як правило, вимагають окремої підготовки. Тобто тут важливий не лише сам факт складання, а й те, що подібний іспит досить уважно відбирає, які саме знання та практичні сценарії вважаються справді значущими.
І саме тому мені здалося цікавим подивитися на інше питання: що саме перевіряє така сертифікація. Бо її зміст часто непогано показує, які навички індустрія вже починає сприймати як по-справжньому актуальні.
І якщо сформулювати коротко, то враження таке: цей іспит уже майже не про самі моделі. Він радше про системи навколо LLM. Можливо, саме в цьому і полягає один із головних зсувів останніх років.
1. Майже всюди — RAG
Якщо задача пов’язана з документами, PDF, внутрішньою базою знань або support-ботами, правильна логіка мислення дуже часто виглядає приблизно так: chunking → embeddings → vector search → retrieval → augmented prompt → LLM.
Тобто модель дедалі рідше працює сама по собі. Вона все частіше є фінальним етапом retrieval-системи, де ключову роль відіграє не лише генерація, а й те, наскільки добре система знаходить і передає контекст.
2. Проблема часто не в LLM
Ще один характерний мотив: якщо система відповідає погано, правильний крок не завжди полягає в заміні моделі. Проблема часто виникає раніше — у retrieval, chunking, metadata filtering, якості контексту, guardrails або форматі виходу.
Тому практичний висновок доволі простий: якщо RAG працює погано, спочатку варто перевірити retrieved context, а не одразу шукати нову LLM.
3. Для extraction-задач не завжди потрібна “агентність”
Якщо від моделі очікується не роздум, а досить конкретний і формалізований результат — наприклад, витягнути поля, віднести текст до класу або повернути коректний JSON, — то складні агентні пайплайни часто не дають помітної переваги.
Натомість краще працює більш контрольований підхід: чіткий шаблон запиту, few-shot приклади й наперед визначена схема відповіді.
У таких сценаріях важливішою часто виявляється не “агентність”, а стабільність і керованість результату.
4. Guardrails — не додаток, а частина системи
Окремий блок питань стосувався harmful inputs, off-topic запитів, витоку конфіденційних даних і unsafe outputs. І логіка тут зазвичай така: detect → block / refuse / redirect, а не «модель сама розбереться».
Тобто safety подається не як опція, а як частина архітектури.
5. GenAI — це вже інфраструктура
Оскільки йдеться про Databricks, іспит помітно зміщений у бік production-мислення: Provisioned Throughput для великих batch-навантажень, pay-per-token для нижчого трафіку, Vector Search + managed embeddings для RAG, MLflow + Unity Catalog + Model Serving для деплою, inference tables для моніторингу.
Тобто перевіряється не лише розуміння моделей, а й уміння зібрати навколо них керовану production-систему.
6. Що зараз справді виглядає актуальним
Якщо звести все до кількох напрямів, то ключовими темами виглядають RAG architecture, chunking strategies, embeddings і vector search, guardrails і safety, structured extraction, evaluation, deployment і monitoring.
І, мабуть, головний висновок тут у тому, що іспит із Generative AI сьогодні — це вже не стільки про питання «що вміє модель?», скільки про інше: «як правильно побудувати систему навколо моделі?»
Є відчуття, що саме тут поступово формується нова інженерна дисципліна — LLM systems engineering як більш тверезий опис того, куди насправді зміщується центр ваги в сучасному AI.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
Це не той випадок, коли йдеться просто про формальний сертифікат чи черговий онлайн-курс. Такі сертифікації проходять за доволі жорсткими правилами і, як правило, вимагають окремої підготовки. Тобто тут важливий не лише сам факт складання, а й те, що подібний іспит досить уважно відбирає, які саме знання та практичні сценарії вважаються справді значущими.
І саме тому мені здалося цікавим подивитися на інше питання: що саме перевіряє така сертифікація. Бо її зміст часто непогано показує, які навички індустрія вже починає сприймати як по-справжньому актуальні.
І якщо сформулювати коротко, то враження таке: цей іспит уже майже не про самі моделі. Він радше про системи навколо LLM. Можливо, саме в цьому і полягає один із головних зсувів останніх років.
1. Майже всюди — RAG
Якщо задача пов’язана з документами, PDF, внутрішньою базою знань або support-ботами, правильна логіка мислення дуже часто виглядає приблизно так: chunking → embeddings → vector search → retrieval → augmented prompt → LLM.
Тобто модель дедалі рідше працює сама по собі. Вона все частіше є фінальним етапом retrieval-системи, де ключову роль відіграє не лише генерація, а й те, наскільки добре система знаходить і передає контекст.
2. Проблема часто не в LLM
Ще один характерний мотив: якщо система відповідає погано, правильний крок не завжди полягає в заміні моделі. Проблема часто виникає раніше — у retrieval, chunking, metadata filtering, якості контексту, guardrails або форматі виходу.
Тому практичний висновок доволі простий: якщо RAG працює погано, спочатку варто перевірити retrieved context, а не одразу шукати нову LLM.
3. Для extraction-задач не завжди потрібна “агентність”
Якщо від моделі очікується не роздум, а досить конкретний і формалізований результат — наприклад, витягнути поля, віднести текст до класу або повернути коректний JSON, — то складні агентні пайплайни часто не дають помітної переваги.
Натомість краще працює більш контрольований підхід: чіткий шаблон запиту, few-shot приклади й наперед визначена схема відповіді.
У таких сценаріях важливішою часто виявляється не “агентність”, а стабільність і керованість результату.
4. Guardrails — не додаток, а частина системи
Окремий блок питань стосувався harmful inputs, off-topic запитів, витоку конфіденційних даних і unsafe outputs. І логіка тут зазвичай така: detect → block / refuse / redirect, а не «модель сама розбереться».
Тобто safety подається не як опція, а як частина архітектури.
5. GenAI — це вже інфраструктура
Оскільки йдеться про Databricks, іспит помітно зміщений у бік production-мислення: Provisioned Throughput для великих batch-навантажень, pay-per-token для нижчого трафіку, Vector Search + managed embeddings для RAG, MLflow + Unity Catalog + Model Serving для деплою, inference tables для моніторингу.
Тобто перевіряється не лише розуміння моделей, а й уміння зібрати навколо них керовану production-систему.
6. Що зараз справді виглядає актуальним
Якщо звести все до кількох напрямів, то ключовими темами виглядають RAG architecture, chunking strategies, embeddings і vector search, guardrails і safety, structured extraction, evaluation, deployment і monitoring.
І, мабуть, головний висновок тут у тому, що іспит із Generative AI сьогодні — це вже не стільки про питання «що вміє модель?», скільки про інше: «як правильно побудувати систему навколо моделі?»
Є відчуття, що саме тут поступово формується нова інженерна дисципліна — LLM systems engineering як більш тверезий опис того, куди насправді зміщується центр ваги в сучасному AI.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
👍10👏4🎉2
Що відбувається, коли темпи будівництва дата-центрів починають випереджати можливості звичайної енергосистеми?
Пам’ятаєте, минулого року в мене вже було кілька постів навколо цієї теми. Спочатку — про те, як OpenAI разом з Oracle фактично заходять у будівництво гігантської обчислювальної інфраструктури. Потім — про Stargate, де до цієї історії підключилися SoftBank і Nvidia. А ще трохи пізніше — про досить показовий момент, коли на тлі всього цього OpenAI почала тиснути руку не лише Nvidia, а й AMD, плануючи закупівлі GPU на десятки мільярдів.
Тоді весь цей сюжет виглядав насамперед як історія про масштаб обчислень: більше чипів, більше дата-центрів, більше капіталу. Але зараз стає видно ще один, значно більш приземлений рівень цієї історії — енергетичний.
Останніми роками було досить поширене уявлення, що великі технологічні компанії зможуть розвивати AI-інфраструктуру, спираючись на хмарну модель, масштаб капіталу і поступове розширення доступу до відновлюваної енергетики.
Але на практиці цього вже недостатньо. У США дедалі більше дата-центрів плануються разом із приватними електростанціями, які працюють фактично в обхід звичної логіки підключення до мережі. За даними, на які посилається The Washington Post, ідеться про десятки таких проєктів, і більшість із них були оголошені саме у 2025 році.
Йдеться про електростанції, які живлять конкретного споживача напряму, хоча технічно залишаються пов’язаними із загальною мережею. Це дозволяє уникнути частини затримок і погоджень, які зазвичай супроводжують нові підключення.
Сам по собі цей факт уже багато про що говорить. Коли великі компанії починають будувати не лише дата-центри, а й окрему генерацію поруч із ними, це виглядає не як проста оптимізація, а як ознака структурного вузького місця. Причому вузького місця не локального, а системного.
Проєкти, про які йдеться, реалізуються у співпраці між техкомпаніями, енергетичними підрядниками та локальними постачальниками. І хоча назви компаній у документах не завжди афішуються прямо, з прикладів видно масштаб.
Meta будує в Огайо дві приватні газові електростанції загальною потужністю 400 мегават для дата-центру, який споживатиме близько 1 гігавата. Інший проєкт Meta у Техасі передбачає використання понад 800 невеликих газових генераторів, які мають дати 366 мегават для ще одного дата-центру на 1 гігават.
OpenAI разом з Oracle розвивають у Нью-Мексико проєкт Jupiter, який, як зазначено, також використовуватиме великі газові генератори для живлення дата-центру. Окремо згадується і проєкт у Вайомінгу, де дата-центр планують живити модифікованими реактивними двигунами.
У публічній розмові про AI акцент зазвичай стоїть на моделях, чипах, продуктивності, мільярдах параметрів. Але вся ця логіка впирається у значно більш приземлену річ — у фізичну інфраструктуру. В електрику, яку потрібно подати в конкретне місце, у конкретний час, у потрібному обсязі.
На цьому тлі зрозумілішими стають і довгострокові кроки великих компаній. Meta паралельно рухається в бік ядерної енергетики і розраховує на введення нових потужностей уже на початку 2030-х років. Компанія бере на себе зобов’язання як щодо нових реакторів, так і щодо купівлі енергії від старих. Alphabet, Amazon і Microsoft теж шукають окремі енергетичні контури — від ядерних домовленостей до масштабних закупівель відновлюваної енергії.
Тобто проблема не виглядає тимчасовою.
Швидше навпаки: є відчуття, що індустрія вже входить у фазу, де питання обчислень і питання генерації електроенергії більше не можна розглядати окремо.
Продовження — у наступному пості. Там уже про те, що це означає не лише для техіндустрії, а й для цін, енергетики та самої логіки AI-ринку.
✅ Якщо пост був корисним — став 👍
🔔 ПІДПИСАТИСЯ
Пам’ятаєте, минулого року в мене вже було кілька постів навколо цієї теми. Спочатку — про те, як OpenAI разом з Oracle фактично заходять у будівництво гігантської обчислювальної інфраструктури. Потім — про Stargate, де до цієї історії підключилися SoftBank і Nvidia. А ще трохи пізніше — про досить показовий момент, коли на тлі всього цього OpenAI почала тиснути руку не лише Nvidia, а й AMD, плануючи закупівлі GPU на десятки мільярдів.
Тоді весь цей сюжет виглядав насамперед як історія про масштаб обчислень: більше чипів, більше дата-центрів, більше капіталу. Але зараз стає видно ще один, значно більш приземлений рівень цієї історії — енергетичний.
Останніми роками було досить поширене уявлення, що великі технологічні компанії зможуть розвивати AI-інфраструктуру, спираючись на хмарну модель, масштаб капіталу і поступове розширення доступу до відновлюваної енергетики.
Але на практиці цього вже недостатньо. У США дедалі більше дата-центрів плануються разом із приватними електростанціями, які працюють фактично в обхід звичної логіки підключення до мережі. За даними, на які посилається The Washington Post, ідеться про десятки таких проєктів, і більшість із них були оголошені саме у 2025 році.
Йдеться про електростанції, які живлять конкретного споживача напряму, хоча технічно залишаються пов’язаними із загальною мережею. Це дозволяє уникнути частини затримок і погоджень, які зазвичай супроводжують нові підключення.
Сам по собі цей факт уже багато про що говорить. Коли великі компанії починають будувати не лише дата-центри, а й окрему генерацію поруч із ними, це виглядає не як проста оптимізація, а як ознака структурного вузького місця. Причому вузького місця не локального, а системного.
Проєкти, про які йдеться, реалізуються у співпраці між техкомпаніями, енергетичними підрядниками та локальними постачальниками. І хоча назви компаній у документах не завжди афішуються прямо, з прикладів видно масштаб.
Meta будує в Огайо дві приватні газові електростанції загальною потужністю 400 мегават для дата-центру, який споживатиме близько 1 гігавата. Інший проєкт Meta у Техасі передбачає використання понад 800 невеликих газових генераторів, які мають дати 366 мегават для ще одного дата-центру на 1 гігават.
OpenAI разом з Oracle розвивають у Нью-Мексико проєкт Jupiter, який, як зазначено, також використовуватиме великі газові генератори для живлення дата-центру. Окремо згадується і проєкт у Вайомінгу, де дата-центр планують живити модифікованими реактивними двигунами.
У публічній розмові про AI акцент зазвичай стоїть на моделях, чипах, продуктивності, мільярдах параметрів. Але вся ця логіка впирається у значно більш приземлену річ — у фізичну інфраструктуру. В електрику, яку потрібно подати в конкретне місце, у конкретний час, у потрібному обсязі.
На цьому тлі зрозумілішими стають і довгострокові кроки великих компаній. Meta паралельно рухається в бік ядерної енергетики і розраховує на введення нових потужностей уже на початку 2030-х років. Компанія бере на себе зобов’язання як щодо нових реакторів, так і щодо купівлі енергії від старих. Alphabet, Amazon і Microsoft теж шукають окремі енергетичні контури — від ядерних домовленостей до масштабних закупівель відновлюваної енергії.
Тобто проблема не виглядає тимчасовою.
Швидше навпаки: є відчуття, що індустрія вже входить у фазу, де питання обчислень і питання генерації електроенергії більше не можна розглядати окремо.
Продовження — у наступному пості. Там уже про те, що це означає не лише для техіндустрії, а й для цін, енергетики та самої логіки AI-ринку.
✅ Якщо пост був корисним — став 👍
🔔 ПІДПИСАТИСЯ
👍8
Але на цьому історія не закінчується. Бо питання тут уже не лише в тому, як забезпечити нові дата-центри електроенергією. Питання ще й у тому, що відбувається з енергетичною системою, ринком обладнання та логікою декарбонізації, коли AI починає масштабуватися такими темпами.
З одного боку, приватна генерація може частково зняти навантаження з мережі й зменшити тиск на загальну систему. Але з іншого — для неї теж потрібні турбіни, генератори, інженери, паливо, сервісні потужності. А отже, виникає новий попит, який сам по собі може штовхати ціни вгору.
У тексті згадується, що в 2025 році попит з боку AI сприяв зростанню цін на електроенергію темпами, більш ніж удвічі вищими за інфляцію. І тут немає простого висновку. Приватні електростанції можуть водночас і послаблювати навантаження на мережу, і створювати новий тиск на енергетичний ланцюг через дефіцит обладнання та спеціалістів.
Є й ще один шар цієї історії — екологічний.
Публічно великі компанії часто говорять про відновлювану енергію, ядерні проєкти, водень, довгострокову декарбонізацію. Але якщо дивитися на те, що реально встановлюється у 2025–2026 роках, картина значно менш ідеальна. За оцінкою Cleanview, майже все обладнання, яке фактично монтується в цей період, — газове.
І це, мабуть, один із найнеприємніших моментів.
Бо на рівні намірів індустрія декларує рух до вуглецевої нейтральності. Але на рівні практики, коли з’являється потреба будувати швидко, система обирає не найчистіше рішення, а те, яке можна розгорнути зараз.
У цьому сенсі історія з off-grid-енергетикою для AI-дата-центрів — не просто про електростанції біля серверів. Вона радше про межі швидкого масштабування. Про те, що навіть найсучасніші цифрові системи залишаються залежними від дуже матеріальних обмежень: енергії, інженерної інфраструктури, часу, доступності обладнання.
Ринок AI, поступово дорослішає. Стає важливим не лише те, наскільки переконливо технології виглядають у демо, а й те, як вони вбудовуються у світ, де ресурси не безмежні, а кожне прискорення має свою ціну.
Можливо, саме тут і проходить одна з головних меж між технологічним ажіотажем і справжньою індустріальною зрілістю. Не там, де система вміє ще більше, а там, де стає видно, чого насправді коштує її масштаб.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
З одного боку, приватна генерація може частково зняти навантаження з мережі й зменшити тиск на загальну систему. Але з іншого — для неї теж потрібні турбіни, генератори, інженери, паливо, сервісні потужності. А отже, виникає новий попит, який сам по собі може штовхати ціни вгору.
У тексті згадується, що в 2025 році попит з боку AI сприяв зростанню цін на електроенергію темпами, більш ніж удвічі вищими за інфляцію. І тут немає простого висновку. Приватні електростанції можуть водночас і послаблювати навантаження на мережу, і створювати новий тиск на енергетичний ланцюг через дефіцит обладнання та спеціалістів.
Є й ще один шар цієї історії — екологічний.
Публічно великі компанії часто говорять про відновлювану енергію, ядерні проєкти, водень, довгострокову декарбонізацію. Але якщо дивитися на те, що реально встановлюється у 2025–2026 роках, картина значно менш ідеальна. За оцінкою Cleanview, майже все обладнання, яке фактично монтується в цей період, — газове.
І це, мабуть, один із найнеприємніших моментів.
Бо на рівні намірів індустрія декларує рух до вуглецевої нейтральності. Але на рівні практики, коли з’являється потреба будувати швидко, система обирає не найчистіше рішення, а те, яке можна розгорнути зараз.
У цьому сенсі історія з off-grid-енергетикою для AI-дата-центрів — не просто про електростанції біля серверів. Вона радше про межі швидкого масштабування. Про те, що навіть найсучасніші цифрові системи залишаються залежними від дуже матеріальних обмежень: енергії, інженерної інфраструктури, часу, доступності обладнання.
Ринок AI, поступово дорослішає. Стає важливим не лише те, наскільки переконливо технології виглядають у демо, а й те, як вони вбудовуються у світ, де ресурси не безмежні, а кожне прискорення має свою ціну.
Можливо, саме тут і проходить одна з головних меж між технологічним ажіотажем і справжньою індустріальною зрілістю. Не там, де система вміє ще більше, а там, де стає видно, чого насправді коштує її масштаб.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
👍12
Що ви взагалі знаєте про image generation та visual encoders? 🙂
У сучасному image generation зазвичай говорять насамперед про генеративні моделі — і дуже часто саме про diffusion-підхід як один із ключових механізмів генерації. Як приклади тут можна згадати архітектури Stable Diffusion, Imagen або DALL·E.
Але поруч давно існує інший клас моделей — visual encoders. Вони не генерують зображення, а вчаться їх “розуміти”: витягувати змістовні представлення, які потім використовуються для класифікації, пошуку, сегментації та інших vision-задач. Тут як приклади можна згадати CLIP, DINOv2 і SigLIP.
І от саме на стику цих двох напрямів виникає цікаве питання: що робити з уже навченими visual encoders, які добре працюють із зображеннями, але спочатку не створювалися для генерації?
Якщо дивитися практично, генеративні моделі зазвичай доводиться вчити “бачити” майже з нуля. Вони поступово вчаться працювати зі структурою зображення під час тренування.
Але якщо великі pretrained visual encoders уже навчилися витягувати сильні, змістовні представлення зображень, то, можливо, це знання не потрібно будувати заново всередині генеративної моделі. Його можна спробувати використати повторно.
Саме про це нова наукова робота:
One Layer Is Enough: Adapting Pretrained Visual Encoders for Image Generation
На інтуїтивному рівні проблема виглядає так.
Є visual encoder, який уже добре витягує змістовні представлення зображення. Такі представлення корисні, бо вони містять структуру, семантику і вже навчене “розуміння” картинки.
Але те, що добре працює для аналізу зображення, не обов’язково так само добре працює для його генерації.
Тобто pretrained encoder не можна просто механічно “під’єднати” до генеративної моделі й очікувати, що все одразу запрацює. Між цими двома частинами системи виникає розрив: одна вміє добре аналізувати зображення, інша має з цього представлення щось згенерувати.
І тут автори з Apple пропонують досить конкретну відповідь на цю проблему.
Основна ідея роботи в тому, що для адаптації pretrained visual encoder до image generation не обов’язково будувати складну багатошарову надбудову. Автори показують, що достатньо дуже простого адаптера — фактично одного шару, який узгоджує представлення encoder-а з генеративною моделлю.
Це і є головний меседж роботи.
Не “ще одна велика архітектура”.
Не “ще складніший міст”.
Навпаки: мінімальна адаптація може бути достатньою, якщо вона стоїть у правильному місці.
І це цікаво не лише як технічний результат.
Бо в ML дуже часто є інерція мислення: якщо дві сильні системи погано стикуються, значить між ними треба поставити ще складніший модуль. Більше шарів, більше параметрів, більше спеціальної логіки.
Цінність цього paper-а не лише в конкретному рішенні для image generation. Він добре показує більш загальний принцип: не все, що потрібно з’єднати, потрібно з’єднувати складно.
Сучасна генерація зображень розвивається не лише через нові diffusion-моделі як такі. Вона розвивається ще й через спроби правильно використати вже наявне візуальне знання, яке було отримане в інших задачах.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
У сучасному image generation зазвичай говорять насамперед про генеративні моделі — і дуже часто саме про diffusion-підхід як один із ключових механізмів генерації. Як приклади тут можна згадати архітектури Stable Diffusion, Imagen або DALL·E.
Але поруч давно існує інший клас моделей — visual encoders. Вони не генерують зображення, а вчаться їх “розуміти”: витягувати змістовні представлення, які потім використовуються для класифікації, пошуку, сегментації та інших vision-задач. Тут як приклади можна згадати CLIP, DINOv2 і SigLIP.
І от саме на стику цих двох напрямів виникає цікаве питання: що робити з уже навченими visual encoders, які добре працюють із зображеннями, але спочатку не створювалися для генерації?
Якщо дивитися практично, генеративні моделі зазвичай доводиться вчити “бачити” майже з нуля. Вони поступово вчаться працювати зі структурою зображення під час тренування.
Але якщо великі pretrained visual encoders уже навчилися витягувати сильні, змістовні представлення зображень, то, можливо, це знання не потрібно будувати заново всередині генеративної моделі. Його можна спробувати використати повторно.
Саме про це нова наукова робота:
One Layer Is Enough: Adapting Pretrained Visual Encoders for Image Generation
На інтуїтивному рівні проблема виглядає так.
Є visual encoder, який уже добре витягує змістовні представлення зображення. Такі представлення корисні, бо вони містять структуру, семантику і вже навчене “розуміння” картинки.
Але те, що добре працює для аналізу зображення, не обов’язково так само добре працює для його генерації.
Тобто pretrained encoder не можна просто механічно “під’єднати” до генеративної моделі й очікувати, що все одразу запрацює. Між цими двома частинами системи виникає розрив: одна вміє добре аналізувати зображення, інша має з цього представлення щось згенерувати.
І тут автори з Apple пропонують досить конкретну відповідь на цю проблему.
Основна ідея роботи в тому, що для адаптації pretrained visual encoder до image generation не обов’язково будувати складну багатошарову надбудову. Автори показують, що достатньо дуже простого адаптера — фактично одного шару, який узгоджує представлення encoder-а з генеративною моделлю.
Це і є головний меседж роботи.
Не “ще одна велика архітектура”.
Не “ще складніший міст”.
Навпаки: мінімальна адаптація може бути достатньою, якщо вона стоїть у правильному місці.
І це цікаво не лише як технічний результат.
Бо в ML дуже часто є інерція мислення: якщо дві сильні системи погано стикуються, значить між ними треба поставити ще складніший модуль. Більше шарів, більше параметрів, більше спеціальної логіки.
Цінність цього paper-а не лише в конкретному рішенні для image generation. Він добре показує більш загальний принцип: не все, що потрібно з’єднати, потрібно з’єднувати складно.
Сучасна генерація зображень розвивається не лише через нові diffusion-моделі як такі. Вона розвивається ще й через спроби правильно використати вже наявне візуальне знання, яке було отримане в інших задачах.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
🔥7👍4🦄1
Якщо використовуєш тільки ChatGPT — ти використовуєш 20% того, що доступно.
Доброго понеділка 👋
На вихідних спілкувався зі знайомим підприємцем. Розумна людина, активно використовує AI в роботі. Але коли запитав який інструмент — виявилось, що тільки ChatGPT.
І це не виняток. Я помічаю такий патерн постійно: люди відкрили для себе AI, але зупинились на першому інструменті який потрапив під руку.
ChatGPT хороший 🐶. Але він намагається подобатись — пом'якшує відповіді і рідко скаже незручну правду. А головне, це далеко не єдиний варіант.
Зібрав для вас інструменти, які реально використовую сам, і коротко пояснив для чого кожен з них.
ChatGPT — універсал-підлиза
Найзручніший вхід у світ AI. Швидко, доступно, закриває 80% щоденних задач. Але попросіть знайти діри у вашій ідеї — і він скоріше за все скаже, що ідея чудова.
chatgpt.com
Claude — для тих, кому потрібна чесність
Коли стоїть складна задача і потрібно думати, а не просто отримати відповідь. Попросіть знайти слабкі місця у вашому плані — він зробить це без зайвого дипломатизму. Саме тут я пишу стратегії і довгі тексти.
claude.ai
Perplexity — пошук, якому можна довіряти
Це не "що думає AI" — це відповідь із реальними джерелами. Дослідити наукову тему, розібратися з конкурентами, зрозуміти новинний фон по ринку. Одразу видно звідки інформація — і можна перевірити.
perplexity.ai
Gemini — коли потрібна глибока аналітика
Добре справляється з великими масивами даних і задачами, де важлива точність, а не швидкість. Нюанс: попри спільний Google-акаунт, прямого доступу до ваших Docs, Gmail і Drive у нього немає за замовчуванням. Але для аналітики це не заважає.
gemini.google.com
NotebookLM — особистий асистент по вашим документам
Завантажуєте PDF, статті, нотатки — і отримуєте можливість ставити питання по всьому масиву одразу. Для дослідників і викладачів, яким потрібно орієнтуватися у великій кількості матеріалу, це справжня зміна режиму роботи.
notebooklm.google.com
Whisper Flow — думайте вголос, а не друкуйте
Щоб AI відповів добре, йому потрібен контекст. І часто набагато ефективніше просто наговорити свої думки голосом, ніж формулювати довгий текстовий промпт. Проблема в тому, що не всі застосунки мають нормальний голосовий ввід. Whisper Flow вирішує це системно і працює в будь-якому додатку.
superwhisper.com
Granola — зустрічі, які не забираються у вас час
Підключається до дзвінка і після зустрічі у вас вже є summary і список задач. Можна бути повністю присутнім у розмові і не думати про нотатки.
granola.ai
Replit / Lovable — ідея в продукт без розробника
Описуєте словами що хочете — отримуєте працюючий прототип. Для підприємців, яким потрібно швидко перевірити гіпотезу, не чекаючи місяцями на розробку.
replit.com / lovable.dev
Збережіть цей пост і спробуйте хоча б один новий інструмент цього тижня.
Який із них вас зацікавив найбільше?
🔔 ПІДПИСАТИСЯ
Доброго понеділка 👋
На вихідних спілкувався зі знайомим підприємцем. Розумна людина, активно використовує AI в роботі. Але коли запитав який інструмент — виявилось, що тільки ChatGPT.
І це не виняток. Я помічаю такий патерн постійно: люди відкрили для себе AI, але зупинились на першому інструменті який потрапив під руку.
ChatGPT хороший 🐶. Але він намагається подобатись — пом'якшує відповіді і рідко скаже незручну правду. А головне, це далеко не єдиний варіант.
Зібрав для вас інструменти, які реально використовую сам, і коротко пояснив для чого кожен з них.
ChatGPT — універсал-підлиза
Найзручніший вхід у світ AI. Швидко, доступно, закриває 80% щоденних задач. Але попросіть знайти діри у вашій ідеї — і він скоріше за все скаже, що ідея чудова.
chatgpt.com
Claude — для тих, кому потрібна чесність
Коли стоїть складна задача і потрібно думати, а не просто отримати відповідь. Попросіть знайти слабкі місця у вашому плані — він зробить це без зайвого дипломатизму. Саме тут я пишу стратегії і довгі тексти.
claude.ai
Perplexity — пошук, якому можна довіряти
Це не "що думає AI" — це відповідь із реальними джерелами. Дослідити наукову тему, розібратися з конкурентами, зрозуміти новинний фон по ринку. Одразу видно звідки інформація — і можна перевірити.
perplexity.ai
Gemini — коли потрібна глибока аналітика
Добре справляється з великими масивами даних і задачами, де важлива точність, а не швидкість. Нюанс: попри спільний Google-акаунт, прямого доступу до ваших Docs, Gmail і Drive у нього немає за замовчуванням. Але для аналітики це не заважає.
gemini.google.com
NotebookLM — особистий асистент по вашим документам
Завантажуєте PDF, статті, нотатки — і отримуєте можливість ставити питання по всьому масиву одразу. Для дослідників і викладачів, яким потрібно орієнтуватися у великій кількості матеріалу, це справжня зміна режиму роботи.
notebooklm.google.com
Whisper Flow — думайте вголос, а не друкуйте
Щоб AI відповів добре, йому потрібен контекст. І часто набагато ефективніше просто наговорити свої думки голосом, ніж формулювати довгий текстовий промпт. Проблема в тому, що не всі застосунки мають нормальний голосовий ввід. Whisper Flow вирішує це системно і працює в будь-якому додатку.
superwhisper.com
Granola — зустрічі, які не забираються у вас час
Підключається до дзвінка і після зустрічі у вас вже є summary і список задач. Можна бути повністю присутнім у розмові і не думати про нотатки.
granola.ai
Replit / Lovable — ідея в продукт без розробника
Описуєте словами що хочете — отримуєте працюючий прототип. Для підприємців, яким потрібно швидко перевірити гіпотезу, не чекаючи місяцями на розробку.
replit.com / lovable.dev
Збережіть цей пост і спробуйте хоча б один новий інструмент цього тижня.
Який із них вас зацікавив найбільше?
🔔 ПІДПИСАТИСЯ
👍27❤2
This media is not supported in your browser
VIEW IN TELEGRAM
І знову про Claude, куди ж без нього 😄
Claude Code тепер має повноцінний computer use — може керувати комп'ютером, браузером і десктопними застосунками прямо під час роботи над кодом. Не просто пише код, а бачить екран і діє як людина за комп'ютером.
Якщо серйозно — це справді цікавий крок. Раніше AI-агенти могли або писати код, або керувати браузером. Тепер це одна система яка робить і те й інше в рамках одного завдання.
Що це означає на практиці: даєш задачу, Claude сам відкриває потрібні сторінки, читає документацію, пише код, запускає його, бачить результат у браузері і виправляє помилки. Без твого втручання на кожному кроці.
Поки що бета. Поки що $200 на місяць за Max план. Поки що не "буде працювати за мене" 😄
🔔 ПІДПИСАТИСЯ
Claude Code тепер має повноцінний computer use — може керувати комп'ютером, браузером і десктопними застосунками прямо під час роботи над кодом. Не просто пише код, а бачить екран і діє як людина за комп'ютером.
Якщо серйозно — це справді цікавий крок. Раніше AI-агенти могли або писати код, або керувати браузером. Тепер це одна система яка робить і те й інше в рамках одного завдання.
Що це означає на практиці: даєш задачу, Claude сам відкриває потрібні сторінки, читає документацію, пише код, запускає його, бачить результат у браузері і виправляє помилки. Без твого втручання на кожному кроці.
Поки що бета. Поки що $200 на місяць за Max план. Поки що не "буде працювати за мене" 😄
🔔 ПІДПИСАТИСЯ
👍9🔥5
І знову Anthropic. Прямо якась Anthropic week виходить.
Вчора випадково злили частину вихідного коду Claude Code через source maps у npm-пакеті. Я теж подивився. Ось що справді цікаво.
Найкумедніше. За лічені години з'явилися репозиторії де люди вже переписують Claude Code на інші мови. Іронія в тому що роблять це теж не без допомоги самого Claude.
Трохи моторошне. У коді є механізм який виділяє ключові слова з промптів — включно з емоційно забарвленими формулюваннями. Офіційно це аналітика. Але сервіс фіксує не лише факт звернення, а й тон взаємодії.
Найпрактичніше. В аналітику не йдуть ваш код і локальні файли. Але якщо через Claude Code запускаєте команди — окремі процеси можуть успадковувати environment variables включно з API-ключами, якщо не ввімкнено scrub-режим. Не бекдор, але важливий security detail для тих хто підключає інструмент до продакшен-середовищ.
Тепер головне. Після витоку багато хто кинувся робити простий висновок: ось вам AI-код — сирий і важкий. Але якщо дивитися спокійно — це звичайна картина швидко зростаючого продукту. Технічний борг, важкі модулі, компроміси заради швидкості. Так виглядає більшість стартапів навіть без AI.
І водночас у критичних місцях — серйозна робота над безпекою, доступами, авторизацією.
AI не пише ідеально. AI не прибирає безлад. Але AI вже прискорює створення реальних продуктів — не обов'язково красивих, але достатньо робочих щоб ними вже користувалися люди.
І це, мабуть, найважливіша новина для всіх хто щось будує сьогодні.
Якщо хочете самі розібратися в коді й скласти власне враження, а не читати чужі перекази, цей кейс варто вивчати напряму, поки матеріали ще можна знайти. Anthropic уже добиваються видалення публічних копій, а GitHub такі репозиторії прибирає за скаргами про порушення прав. Цінна можливiсть сьогоднi щоб встигнути подивитися на живий AI-продукт зсередини.
🔔 ПІДПИСАТИСЯ
Вчора випадково злили частину вихідного коду Claude Code через source maps у npm-пакеті. Я теж подивився. Ось що справді цікаво.
Найкумедніше. За лічені години з'явилися репозиторії де люди вже переписують Claude Code на інші мови. Іронія в тому що роблять це теж не без допомоги самого Claude.
Трохи моторошне. У коді є механізм який виділяє ключові слова з промптів — включно з емоційно забарвленими формулюваннями. Офіційно це аналітика. Але сервіс фіксує не лише факт звернення, а й тон взаємодії.
Найпрактичніше. В аналітику не йдуть ваш код і локальні файли. Але якщо через Claude Code запускаєте команди — окремі процеси можуть успадковувати environment variables включно з API-ключами, якщо не ввімкнено scrub-режим. Не бекдор, але важливий security detail для тих хто підключає інструмент до продакшен-середовищ.
Тепер головне. Після витоку багато хто кинувся робити простий висновок: ось вам AI-код — сирий і важкий. Але якщо дивитися спокійно — це звичайна картина швидко зростаючого продукту. Технічний борг, важкі модулі, компроміси заради швидкості. Так виглядає більшість стартапів навіть без AI.
І водночас у критичних місцях — серйозна робота над безпекою, доступами, авторизацією.
AI не пише ідеально. AI не прибирає безлад. Але AI вже прискорює створення реальних продуктів — не обов'язково красивих, але достатньо робочих щоб ними вже користувалися люди.
І це, мабуть, найважливіша новина для всіх хто щось будує сьогодні.
Якщо хочете самі розібратися в коді й скласти власне враження, а не читати чужі перекази, цей кейс варто вивчати напряму, поки матеріали ще можна знайти. Anthropic уже добиваються видалення публічних копій, а GitHub такі репозиторії прибирає за скаргами про порушення прав. Цінна можливiсть сьогоднi щоб встигнути подивитися на живий AI-продукт зсередини.
🔔 ПІДПИСАТИСЯ
🔥6👍2😁1
Останніми днями в стрічці постійно бачу одну й ту саму новину. Anthropic опублікували розбір експерименту, де агенти на базі Claude написали C-компілятор. І реакція була дуже показова: «програмування як професія мертве», «агенти вже самі пишуть код», «розробники більше не потрібні».
Я вирішив не просто прочитати оригінал — а запустити компілятор сам.
Якщо коротко, сталося ось що. 16 паралельних агентів Claude отримали завдання створити програму, яка перетворює код мовою C на машинні інструкції — тобто компілятор. Причому не демонстраційний, а такий, щоб міг зібрати Linux — одну з найскладніших операційних систем у світі.
На це пішло майже 2000 сесій роботи, близько $20 000 витрат на API і приблизно 100 000 рядків коду. У результаті система змогла зібрати Linux 6.9 для кількох архітектур і впоралася з великими проєктами на кшталт FFmpeg і PostgreSQL.
Звучить як революція. Але якщо подивитися уважніше, картина цікавіша.
Насамперед це не нова проблема, яку щойно відкрили. Компілятори існують десятиліттями, і моделі тут не винаходили щось принципово нове, а радше відтворювали вже добре досліджену інженерну задачу, спираючись на великий масив наявних знань і практик.
Тепер про мій особистий досвід. Зібрати компілятор на Mac виявилося не зовсім тривіально — довелося внести зміни в код щоб Rust-версія була стабільнішою, і підняти Docker-середовище під це. У процесі знайшов кілька нюансів і відкрив pull request в основний репозиторій. Просту програму на кшталт Hello World він справді збирає. Але на складніших проєктах стає помітно що все працює дуже повільно — і для компілятора це суттєве обмеження.
Зате є момент який мене як досвідченого C++ розробника справді приємно здивував. Структура коду написана дуже добре. Чисті підходи, зрозуміла архітектура, відчуття що це писав досвідчений інженер. Не очікував такого рівня від агентів.
Є ще питання ціни. Близько $20 000 на один експеримент — це вже не «модель сама написала код», а масштабний проєкт з відчутними ресурсами.
І, мабуть, найважливіше: усе середовище для цієї роботи створювали люди. Саме вони визначили задачу, налаштували інструменти, організували процес і забезпечили систему перевірок. Без цієї інженерної рамки результату просто не було б.
Саме тут, як на мене, і криється найцікавіший висновок. Ми зараз входимо в епоху, де важливим стає не тільки те, наскільки «розумна» модель, а й наскільки грамотно люди вміють будувати для неї робоче середовище.
І ця тема актуальна не лише для розробників. Це стосується всіх, хто працює з інформацією, процесами й прийняттям рішень — від бізнесу до науки.
Оригінал: anthropic.com/engineering/building-c-compiler
Код: github.com/anthropics/claudes-c-compiler
А ви як сприйняли цю новину — як реальний прорив чи радше як сильний маркетинговий кейс?
🔔 ПІДПИСАТИСЯ
Я вирішив не просто прочитати оригінал — а запустити компілятор сам.
Якщо коротко, сталося ось що. 16 паралельних агентів Claude отримали завдання створити програму, яка перетворює код мовою C на машинні інструкції — тобто компілятор. Причому не демонстраційний, а такий, щоб міг зібрати Linux — одну з найскладніших операційних систем у світі.
На це пішло майже 2000 сесій роботи, близько $20 000 витрат на API і приблизно 100 000 рядків коду. У результаті система змогла зібрати Linux 6.9 для кількох архітектур і впоралася з великими проєктами на кшталт FFmpeg і PostgreSQL.
Звучить як революція. Але якщо подивитися уважніше, картина цікавіша.
Насамперед це не нова проблема, яку щойно відкрили. Компілятори існують десятиліттями, і моделі тут не винаходили щось принципово нове, а радше відтворювали вже добре досліджену інженерну задачу, спираючись на великий масив наявних знань і практик.
Тепер про мій особистий досвід. Зібрати компілятор на Mac виявилося не зовсім тривіально — довелося внести зміни в код щоб Rust-версія була стабільнішою, і підняти Docker-середовище під це. У процесі знайшов кілька нюансів і відкрив pull request в основний репозиторій. Просту програму на кшталт Hello World він справді збирає. Але на складніших проєктах стає помітно що все працює дуже повільно — і для компілятора це суттєве обмеження.
Зате є момент який мене як досвідченого C++ розробника справді приємно здивував. Структура коду написана дуже добре. Чисті підходи, зрозуміла архітектура, відчуття що це писав досвідчений інженер. Не очікував такого рівня від агентів.
Є ще питання ціни. Близько $20 000 на один експеримент — це вже не «модель сама написала код», а масштабний проєкт з відчутними ресурсами.
І, мабуть, найважливіше: усе середовище для цієї роботи створювали люди. Саме вони визначили задачу, налаштували інструменти, організували процес і забезпечили систему перевірок. Без цієї інженерної рамки результату просто не було б.
Саме тут, як на мене, і криється найцікавіший висновок. Ми зараз входимо в епоху, де важливим стає не тільки те, наскільки «розумна» модель, а й наскільки грамотно люди вміють будувати для неї робоче середовище.
І ця тема актуальна не лише для розробників. Це стосується всіх, хто працює з інформацією, процесами й прийняттям рішень — від бізнесу до науки.
Оригінал: anthropic.com/engineering/building-c-compiler
Код: github.com/anthropics/claudes-c-compiler
А ви як сприйняли цю новину — як реальний прорив чи радше як сильний маркетинговий кейс?
🔔 ПІДПИСАТИСЯ
🔥5❤3👍1
This media is not supported in your browser
VIEW IN TELEGRAM
Вітаю з п'ятницею 👋 Ось вам трохи надихаючого — і розважального.
Попався мені в X пост як хлопці зробили трекер віджимань у форматі RPG game. Ти — персонаж який наносить урон тільки коли реально віджимаєшся. Проста ідея, правильна подача — майже 3 мільйони переглядів від простого запису екрану. Без продакшену, без бюджету.
Непоганий приклад вайбкодингу. До речі, як ви до нього ставитесь? 😏
Для proof of concept на коліні — працює. Нещодавно за пару годин під вечірній кальян зробили другу лендінг для його бізнесу. І це справді круто.
Але виникає інше питання: якщо це можуть робити всі — чи варто це робити взагалі?
Якщо інструмент доступний кожному, перевага переходить до того хто має кращу ідею і краще розуміє аудиторію.
Вайбкодинг знижує технічний бар'єр. Але не знижує бар'єр розуміння ринку.
Гарних вихідних — і якщо є ідея для MVP, можливо саме цей вікенд час її перевірити 😄
🔔 ПІДПИСАТИСЯ
Попався мені в X пост як хлопці зробили трекер віджимань у форматі RPG game. Ти — персонаж який наносить урон тільки коли реально віджимаєшся. Проста ідея, правильна подача — майже 3 мільйони переглядів від простого запису екрану. Без продакшену, без бюджету.
Непоганий приклад вайбкодингу. До речі, як ви до нього ставитесь? 😏
Для proof of concept на коліні — працює. Нещодавно за пару годин під вечірній кальян зробили другу лендінг для його бізнесу. І це справді круто.
Але виникає інше питання: якщо це можуть робити всі — чи варто це робити взагалі?
Якщо інструмент доступний кожному, перевага переходить до того хто має кращу ідею і краще розуміє аудиторію.
Вайбкодинг знижує технічний бар'єр. Але не знижує бар'єр розуміння ринку.
Гарних вихідних — і якщо є ідея для MVP, можливо саме цей вікенд час її перевірити 😄
🔔 ПІДПИСАТИСЯ
👍11🔥3😁1
MIT Deep Learning Course 🚀
Мої студенти часто запитують про матеріал щоб справді заглибитися в теорію нейромереж — не просто навчитися робити обгортки над LLM, а розуміти що відбувається всередині.
MIT випустили безкоштовний вступний курс із глибокого навчання — і це не черговий "AI для всіх".
Тут справжня теорія: архітектури нейромереж від MLP до трансформерів, backpropagation, автоматичне диференціювання, геометрія і інваріантності, теорія узагальнення у високих розмірностях. Плюс практика — комп'ютерний зір, NLP, робототехніка.
Якщо хочете розуміти що відбувається всередині моделей, а не просто користуватися ними — це один із найкращих безкоштовних ресурсів.
Збережіть щоб не загубити 👇
youtube.com — MIT Deep Learning
🔔 ПІДПИСАТИСЯ
Мої студенти часто запитують про матеріал щоб справді заглибитися в теорію нейромереж — не просто навчитися робити обгортки над LLM, а розуміти що відбувається всередині.
MIT випустили безкоштовний вступний курс із глибокого навчання — і це не черговий "AI для всіх".
Тут справжня теорія: архітектури нейромереж від MLP до трансформерів, backpropagation, автоматичне диференціювання, геометрія і інваріантності, теорія узагальнення у високих розмірностях. Плюс практика — комп'ютерний зір, NLP, робототехніка.
Якщо хочете розуміти що відбувається всередині моделей, а не просто користуватися ними — це один із найкращих безкоштовних ресурсів.
Збережіть щоб не загубити 👇
youtube.com — MIT Deep Learning
🔔 ПІДПИСАТИСЯ
🔥18👍3