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

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

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

В мене було коли потрібно було зробити промпт для створення опису статті без переказу самої статті. Для того щоб було зрозуміло чи читати її, чи ні. Заглибившись у правило, я намагався виписувати рецепт до найдрібнішої деталі, що треба писати, що не треба. На які деталі звертати увагу, а які пропускати. Промпт розбухав та ставав дедалі більшим та громоздким. А потім я згадав про метафору. Я попросив зробити його твіт про статтю. Це було несподіване відкриття, яке моментально вводило у потрібний спосіб мислення. «Create a twit about that» і можна було видаляти пʼять абзаців дрібних пояснень що робити і воно робило це навіть краще, ніж моє полотно інструкцій. Там ще довелося додати деякі деталі, накшталт, не використовуй емоджи та хештеги, але основа вже була. Коротка ясна аналогія, яка концентрувала всю суть.

Інший приклад – формування вимог до програмного забезпечення у системах, як CursorAI, Windsurf, Trae.AI чи Zed.AI. Тут можна вловити той дух інтуїції, коли замість довгих пояснень достатньо сказати: «зроби PRD». Замість тисячи поясненть, що саме треба скласти, що там повинно бути, та що ігнорувати, можна звести до одного слова.

Шукайте потрібну метафору та вона виведе ваші промпти на новий рівень.

На днях дуже скромно вийшла модель Claude 3.7 і вони ставлять з ног на голову все, що було до цього. Усі попередні тести не мають жодного значення, бо Claude 3.7 здатний генерувати 127 тисяч вихідних токенів. Не плутати, інші можуть приймати 127 тищ, а генерують вони майже всі тільки 8 тищ. А тут 127 тищ і за один запит. Осьо вам новий тест: сгенеруй мені "Кайдашеву сімʼю". І результати:

Нечуй-Левицкий: 100% якості
Клод: 12% якості
Інші моделі: 0% якості

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

По-перше, кожен окремий файл потрібен буди невеликим. Десь 150 рядків вже ліміт, рівень помилок генерації коду буде мінімальним. Звісно, не треба просто тупо бити файл на окремі частини по 150 рядків. Або просто робити екстракт функції де вам заманеться. Ось цього ШІ поки що притомно не зробить за вас — він не спланує архітектуру додатка таким чином, щоб кожен окремий файл (тобто модуль) був невеликим та атомарним. Плануйте та рефакторіть так, щоб залишатися в цьому ліміті й буде вам щастя.

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

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

Ну й робіть коміти якомога частіше.

Дивіться які в мене шикарні нейровуса!

Вікно Овертона у програмуванні.

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

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

Якщо ви вже в ситуації, коли вікно Овертона вже відкрите нарозхрист, памʼятайте, що різко ляскнути його не можна. Вікно зачиняється так само повільно, як і відкривається.

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

https://ai-2027.com

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

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

Зараз все краще з АІ. Навіть нічого не робити на лаві запасних. Це раніше ти без проекту сидиш, а зараз — цінний співробітник, якого не хочуть віддавати конкурентам.

https://techcrunch.com/2025/04/07/google-is-allegedly-paying-some-ai-staff-to-do-nothing-for-a-year-rather-than-join-rivals/

Стаття в Harvard Business Review про реальне використання генеративного AI вийшла. Забавно, що реальні сценарії використання AI простими смертними взагалі не ті, які передбачали розробники, мріючи про зміну світу.

От, наприклад, генерація коду підскочила з 47 на 5 місце. Зрозуміло, корисно. Але поруч піднімається тема «здорового способу життя» – аж із 75 на 10 місце. Оце вже цікавіше. Хоча найбільше радує перше місце – терапевтичні розмови з GPT. Ну хоч хтось тепер може пояснити, що у нас за проблеми!

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

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

https://hbr.org/2025/04/how-people-are-really-using-gen-ai-in-2025

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

Памʼятаєте wolkswagen репозиторій, який перевіряє, що тести запускаються на CI і робить їх всіх зеленими? 10 років пройшло так ото.

Зустрічайте нового кандидата на звання найкориснішого та актуального репозіторію: tariff. Ця гадюка накладає часові пошліни на інклудання пакетів різних.

tariff.set({
    "numpy": 50,     # 50% tariff on numpy
    "pandas": 200,   # 200% tariff on pandas
    "requests": 150  # 150% tariff on requests
})

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

Живемо в цікаві часи, друзі!

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

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

https://www.moaijobs.com/job/research-scientist-post-agi-research-deepmind-9825

На превеликий жаль Карпович не зміг подолати проблеми. Біль та печаль.

Банка на допомогу дружині: https://send.monobank.ua/jar/3N6eh1DJAg

Виявляється, що багато хто навіть не здогадується про існування adsf — універсальний менеджер версій для мов програмування та суміжних інструментів (усіляких Yarn, UV тощо).

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

asdf plugin add rust && asdf install rust latest і все можна програмувати на Rust. Ну, там ще його трошки вивчити треба, але кому потрібні такі дурниці.

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

Продовжуємо рубрику корисних сервісів. Сьогодні в нас сервіс, який по API повертає причину відмови в відповіді. Дуже корисно, користуємося.

https://github.com/gotev/no-as-a-service

Намалювали в мене діти тварин різних вигаданих. Довелося обробляти. Звісно, просто знайти потрібний сервіс, чи вручну грузити туди, потім ще й сюди, а потім в редакторі це мержити не хотілося зовсім, тому обробляв це автоматично, передаючі по ланцюжку викликів між різними моделями: хтось відео редагував, хтось координати окремих тварин знаходив, хтось фонову музику писав. Наприкінці отримав merged.mp4 ось цей.
Як вам? Діти просто в захваті.

​​Десь рік тому в мене була дуже жвава дискусія на тему того, що все в інтернеті зараз перетворюється на markdown. Тобто, звісно, є ще зображення, графіки та відео, але текстова частина всього контенту або є markdown, або однозначно конвертується в markdown. Тоді мене впевнювали, що маркдаун для розробників, а всі інші, маркетологи, наприклад, знати не знають що це таке. І не повинні. А зараз на просунутих сторінках інтернету вже є кнопочка "Copy as Markdown". Далі маркдауна буде ще більше.

Якщо ваша сторінка не буде вміти перетворитися на markdown, то LLM з вами будуть працювати гірше. Це новий SEO, новий формат для індексації та новий формат для спілкування з LLM. Браузери під це вже зʼявляються. Найпростіший та найзрозуміліший формат це зробити — розширення документа. Замість .html обробляйте .md. Щоб сторінки на кшталт https://docs.anthropic.com/en/docs/get-started можна було відкрити як https://docs.anthropic.com/en/docs/get-started.md і отримати markdown версію сторінки. І ще через деякий час раптово виявиться, що ці md-версії сторінок будуть відвідувати частіше, ніж html-версії. Готуйтеся вже зараз.

Реальна історія зі стартапу-єдинорога часів пандемії.

Потрібен був сервіс для відстеження онлайн-активності на 100к користувачів. Протестували Ruby, Node.js, Elixir та Rust. Rust переміг за всіма параметрами.
За 2 тижні написали MVP. Сервіс працював місяцями без жодного збою, витримував навантаження в 1-2 мільйони користувачів.
Компанія найняла 3 Rust-розробників для підготовки до великої події. Але виявилося... їм нема що робити! Сервіс працював ідеально.
Новий директор побачив проблему у тому, щоє троє дорогих розробників, які сидять без роботи і нічого не роблять. Замість розширення використання Rust, він поставив ультиматум: вивчайте Ruby/Node.js або шукайте нову роботу.
Усі, звісно, пішли. Спроба переписати сервіс на інших мовах провалилася.
Іноді технології працюють настільки добре, що виявляють організаційну некомпетентність. І для деяких компаній це страшніше за будь-які баги.

https://www.reddit.com/r/rust/comments/1kp74t2/rust_success_story_that_killed_rust_usage_in_a/