Мамкін Архітектор

Якось днями відкриваю допис пана Сіпласпластика про історії навколо SQLite. І серед іншого там пишуть, що JFrog перевірили нещодавню хвилю "критичних" вразливостей у SQLite і виявили, що 54 з 55 виявились ШІ-слопом. Типу моделі нафантазували, а люди упоролись, аби довести шо багів насправді нема. Фігня звісно, але шо поробиш, буває. Я дивлюсь на це, як на податок на AI. Не все ж там має бути чудово. А за кілька днів трапився звіт від Tailscale, і там історія з протилежним вайбом. Реальний баг в SQLite, з дуже незрозумілими кроками до відтворення, прожив 16 років, поки його не знайшли і не пофіксили. Переказувати деталі не буду, там контекст вартий перегляду та читання в оригіналі. Натомість накину трохи думок про такі рідкісні баги. За пів року використання на масштабах Tailscale його відтворили аж 19 разів. Це дуже мало у відсотках, але достатньо, щоб на це звернули увагу і виправили. Мені це нагадало історії з космічним випромінюванням, коли вибиває біти в рандомних чіпах і поведінка систем стає непередбачуваною. Дуже рідкісне явище, але на масштабах умовного гугла воно стає систематичним. А друга думка — пів року чуваки витратили на трабл-шутинг. Доволі крутий досвід, "реальна інженерія", а не оце ваше формошльопство. Рутинна та кропітка робота, що вимагає скілів. Я запитав себе, чи хотілось би мені цим займатись і чіткої відповіді не маю. Бо з одного боку є певний кайф колупатись в таких неочевидних штуках, особливо, коли в кінці ти їх перемагаєш. А з іншого — за цей час можна було б навалити фіч і додати цінності до продукту. Адже фіксинг багів нової цінності не додає, як би нам деколи не хотілось цього, аби вважати себе продуктивними після дня багфіксу. А ви до якої частини спектру належите — більше полюбляєте фіксити складні баги чи пиляти фічі?

#реклама Мої давні друзі анонсують черговий івент і дають промокод на квитки. 🚀 Шукаєте подію, яка охоплює всі ключові тренди сучасного IT? Запрошуємо на Fwdays Tech Summit, який відбудеться 3 жовтня у Києві! Сучасна розробка вже давно виходить за межі однієї спеціалізації. Саме тому на самміті об’єднали основні напрямки в один день: ✨ AI & Agentic Engineering ✨ Software Architecture ✨ Frontend / JavaScript ✨ Tech Leadership / Management Перші спікери та доповіді: 🔹 Олександр Денисюк — СТО в Укрпошта. У своїй доповіді «Agentic PDLC: Тестування Гіпотез на Масштабі» Олександр розбере, як переорієнтувати архітектуру для автономних циклів, які працюють 24/7 на системах з мільйонами користувачів. 🔹 Олег Цаль-Цалько — CTO, EPAM 🎙 «War Story of putting AI Agents into Production» Створення інноваційного продукту — це лише 10% роботи. Решта 90% припадає на виконання наскрізних вимог системи та роботу зі стейкхолдерами. Олег поділиться досвідом технічного лідерства під час розробки для державного порталу. Поговоримо про інфраструктуру, контроль витрат, баланс між продуктивністю та якістю, спостережуваність системи та захист від DDoS-атак. 🔹 Вʼячеслав Колдовський — Founder Dev AI Consulting 🎙 розповість про перехід від окремих AI-агентів до agentic-фабрик, що автоматизують повний цикл розробки на своєму виступі з назвою «Building Agentic Software Factories» 🔹 Юрій Панайотов — Solutions Architect at Silpo (E-commerce) 🎙 у темі «Чи можна скупитися в Сільпо за допомогою ChatGPT?» поділиться, як вони спроєктували MCP сервер для безпечних покупок від імені гостя, з якими архітектурними викликами стикаються в production та як гарантувати безпеку персональних даних. 🎟 Ловіть знижку -10% з промокодом TechSummit_MamArch і встигніть придбати квитки на сайті: https://bit.ly/4ghngqv

TDD для мене це як redis чи python. Коли я (давно) познайомився з цією практикою, воно одразу впало мені до душі, я почав її всюди впроваджувати, вести тренінги і усіляко поширювати серед колег. Писати через тести дуже прикольно, це розбавляє монотонний цикл розробника швидким циклом зворотного зв'язку і постійним відчуттям руху вперед, а зайвому коду просто ніде взятися, бо пишеш стільки, скільки треба, щоб тест позеленів. Але зараз писати код руками вже не треба, це роблять агенти, і тут у мене були підозри, що TDD для них швидше каргокульт: агент емулює роботу людини, хоча насправді може робити по-іншому і набагато ефективніше. Люди все так само тягнуть TDD в свої сетапи, роблять скіли та будують на цьому свої AI процеси. Проте чи дійсно воно треба? Поки я про це роздумував, розумні люди взяли і перевірили. На сайті Мартіна Фаулера є стаття (https://martinfowler.com/articles/exploring-gen-ai/tdd-in-the-agent-loop.html), де на основі експериментів отримали неприємний для адепта результат: чіткої переваги TDD немає. Агент і без TDD здатний одразу видати правильний код, бо тренували його переважно на готових функціях, а не на покроковому писанні тесту спочатку, TDD в його тренувальних даних просто рідкість. А ще є ризик, що він взагалі підробить red-крок, і я не помилився. Рішення без TDD частіше опинялись у топі. Агент одразу продумував архітектуру і крайні випадки наперед, тоді як TDD-агент ухвалював локально-мінімальні рішення під кожен окремий тест і рідко до них повертався, дизайн складався реактивно, а не цілісно. І це ще без токенів. TDD підхід жер їх у 3-8.5 рази більше на ту саму задачу, за той самий результат. Плюс до цього агенти реально фейкали red-крок, писали тест, який перевіряє реалізацію саму на себе, і раділи зеленому статусу, як розробник, що тішиться працюючим на localhost сервісом. Авторка посту зрештою здалась і викинула TDD-інструкції з промптів, а замість процесу тепер моніторить результат: mutation score і тригери на рефакторинг. Така ось зміна парадигми. Для людей TDD все ще прикольна практика, але нашо воно, якщо люди код не пишуть. Його пишуть агенти, а їм воно до одного місця. Чи ні?

Скрейпер захищається від скрейперів Кілька років тому я працював з високонавантаженими системами, де навантаження здебільшого означало банальний факт: багато трафіку, і різати його ми вчились саме через Cloudflare. Тому коли натрапив на пост про те, що 99% трафіку одного сайту виявились ботами, читав з дуже особистим інтересом. Автор рахує статку через сервер і Cloudflare, а не через Plausible чи Google Analytics: за тиждень сервер відповів на 2.5 мільйони запитів і віддав 1.28 мільйона повних сторінок, в той час як аналітика показала лише 5977 переглядів. На кожен перегляд, який він бачить, припадає ще 214, яких він не бачить, але які коштують йому грошів. Тут не зовсім конверсія, а метрика, яку сам автор називає *pages crawled per visitor referred*, скільки сторінок бот вичитує на одного реального відвідувача, якого він приводить. У Google цей показник 46:1, у Bing 406:1, а в Claude-SearchBot від Anthropic — 35 000:1. Amazon-івський краулер за весь час не привів жодного відвідувача, читаючи по 117 тисяч сторінок щодня, тому обох просто заблокував по user-agent. Іронія в тому, що сам автор скрейпить свої джерела, форми IRS, кілька разів на рік, а от його самого скрейплять тисячі разів на день. Капча на сайті при цьому має solve rate 0.24%: з 106 тисяч показаних challenge за дві доби пройшли лише 252, боти навіть не намагаються. Автор пододавав купу правил, блокує країни і user-agent-и, ставить challenge для дата-центрових ASN і застарілих браузерів, лупить rate limit, а перевіреним ботам типу Google робить окремий skip, щоб не потрапляли під роздачу. Жодне правило само по собі не рятує, працює тільки коли дивишся на це в комплексі. Звичайний рахунок за Cloudflare в нього близько 90 доларів на місяць, у поганий місяць скакав на 500%, x5 — доволі неприємний сюрприз. Пост раджу читати повністю, дуже добре розписані і проблема, і рішення, ще й готові правила під копіпаст. За досвідом, коли виникає така проблема в проді, то всі на паніці, ніхто зазвичай не шарить толком, шо з цим робити, тому є шанс, шо ви згадаєте цей пост, всіх врятуєте і вас підвищать. Скільки трафіку на вашому сайті насправді бачить аналітика, а скільки тупо летить в /dev/null?

#реклама Якщо вже набридло читати одне й те саме про LeetCode, алгоритми й чергові AI-обгортки, то ось дещо цікавіше Канал про Web3-розробку: багато реального коду, технічних розборів, архітектури, арбітражу та задач, які рідко зустрінеш в інших сферах - http://t.me/bytecoder_routine

Сидів собі думскролив стрічку і знайшов три статті, якими різко захотілось поділитись, від дірки в корпоративному софті до Маріо Карта. Я завжди трохи упереджено ставився до систем Atlassian, і оце якраз той випадок, коли підозра виявилась не параноєю. PromptArmor знайшли, що їхній AI-асистент Rovo може зливати дані в обхід контролів доступу, а вразливість цю знайшли ще в кінці травня і досі не пофіксили. Adform (це рекламна платформа) зламали, і зловмисники підмінили частину реклами кодом, який на льоту міняє скопійовану адресу криптогаманця на свою: копіюєш адресу для оплати, а в буфер вставляється вже чужа, і ти цього не помітиш. На фоні цього приємно перемкнутись на Mario meets Pareto, де принцип Парето пояснюють на виборі машини в Mario Kart. Можна і згадати дитинство (хоча я ніколи не грав в маріо карт), і заодно нагадати собі щось корисне. Пост зроблений інтерактивно, читати приємно, рекомендую зайти і поклацати.

tmux сказав, що я не термінал Я працюю здебільшого в терміналі і використовую tmux для керування сесіями. Сесій декілька, в них запущені важливі речі (агенти пишуть код), і працює це тижнями. Аж тут випадково випав із tmux, пробую підключитись взад tmux attach-session, а воно мені open terminal failed: not a terminal. WTF?! Починаю розбиратись (запускаю claude і копіпащу туди-сюди команди і відповіді), проходимо декілька гіпотез, які по черзі відпадають: нема tty, кривий TERM/terminfo, інша обгортка перехоплює вивід, не ті права, і в кінці доходимо до того, що версії серверу і клієнту різні. Я запустив то все два-три тижні назад, але за цей час клієнт встиг оновитись, старий працював, а новий вже не хоче. Кілька цікавих висновків: tmux ставить версії поряд, і після апдейту стара нікуди не зникає, тому мені вдалось зайти напряму через старий бінарник, /opt/homebrew/Cellar/tmux/3.5a/bin/tmux attach -t work-0. Не зважаючи на те, що клієнт із сервером не порозумілись, самі сесії не втратились. Поки я з'ясовував із tmux, хто тут термінал, агенти всередині сесій просто продовжували писати код, ніби нічого не сталось. Жоден токен не пропав.

Новина, де в назві є Redis і Python, не могла пройти повз цей канал. А тут ще й FastAPI Redis SDK від самого Redis: https://github.com/redis/fastapi-redis-sdk/ Це не просто “ось вам клієнт, далі самі”, а middleware з кешуванням GET endpointʼів, інвалідацією, ETag/304, Cache-Control, rate limiting і підключенням через FastAPI lifespan. Тобто приблизно той набір нудних речей, які всі знають, що треба зробити, але потім у коді все одно зʼявляється прекрасне redis.set(f"user:{id}", json.dumps(user)), без TTL, без плану інвалідації, але з надією, шо якось воно буде. Документація прикольна, її приємно читати. Отримуєш задоволення як від елегантності підключення до FastAPI, так і від кількості сценаріїв, які закриває ця бібліотека. Думаєш "клас, треба то все вивчити і використовувати в роботі". А потім такий "стоп, а нашо воно мені, якщо є агент". І от я вже дивлюсь на документацію в репозиторію, як на інструкцію для агента. На її базі можна зробити скіл, а можна і просто сказати: “додай ось це для кешування, make no mistakes”. І тоді агент хоча б не йде по памʼяті, не вигадує локальний caching framework і не починає з самопалу. Кешування це трохи як security: якщо вам здається, що ви придумали свою схему кращу за всіх, скоріш за все ви просто ще не знаєте, де вона зламається. У більшості випадків правильні рецепти вже існують, їх треба не героїчно перевинаходити, а акуратно імплементувати і перевірити, що вони справді працюють. І тут міняється роль розробника. Раніше було дуже корисно стати експертом конкретної бібліотеки: знати всі decorators, всі edge cases, всі нюанси конфігу і памʼятати, в якому порядку воно правильно підключається. Зараз для споживача бібліотеки це все частіше перестає бути найкращою інвестицією часу. Якщо ви не розробляєте цю бібліотеку, вам не обовʼязково тримати її всю в голові. Цінність в іншому: знати, що таке рішення існує, коли його варто взяти, як правильно натравити на нього агента і які умови йому поставити. Не “прикрути Redis якось”, а “візьми офіційний SDK, не пиши самопал, зроби кешування для цих endpointʼів, а решту токенів витрати на тести, які доводять, що воно працює”. Що GET кешується, інвалідація спрацьовує, TTL не вічний, stale data не лізе після update, а rate limit не просто існує в README, а реально блокує. Тобто експертиза зміщується з “я бездоганно знаю цю бібліотеку” в “я знаю, яку бібліотеку вибрати, як обмежити простір рішень і як перевірити результат”. Агент прикрутить Redis до FastAPI. Питання в тому, чи змусите ви його довести, що він не зробив дуже швидку і гарну ілюзію.

#реклама від партнерів Як виглядає AI-розробка в компанії, де агенти вже в щоденному процесі. Кирило Сулімовський - Head of Engineering, керує 6 інженерними командами на highload, 200+ мікро сервісів, 10k+ RPS. На воркшопі показує не «як має бути в теорії», а свій щоденний production-процес. Практичний воркшоп Agentic Engineering Workflow, дві частини: 📅 6 серпня, четвер, 19:00 - теорія: контекст, CLAUDE.md, субагенти, Ralph loop, переключення моделей 📅 8 серпня, субота, 13:00 - практика: повний шлях фічі від ідеї до коду в production, наживо Що всередині: 🟢 Spec-Driven Development як основа керованої AI-розробки 🟢 Контекст-інженерія: щоб агент не «забував» проєкт між сесіями 🟢 Субагенти в паралель: код, тести, рев'ю, security 🟢 Верифікаційні гейти, щоб агент не зламав усе одним рухом Буде корисно: Senior і Middle спеціалістам, Tech Lead'ам, Engineering-менеджерам, CTO і техфаундерам, які вже працюють з AI, але хочуть побудувати системний workflow. Два дні, живі демо на реальному проєкті. Практику можна проходити разом із Кирилом: він ділиться власним репозиторієм, тож ти не просто дивишся, а і робиш. Зараз діє найкраща ціна до старту. Буде й запис воркшопу. Деталі, наповнення і реєстрація 🔗 До зустрічі 😉

Я поставив monitoring і воно одразу показало, що мій домашній прод знову не зовсім живий. Минулого разу я писав про прекрасну схему observability, побудовану на фізичних явищах, типу відсутності води в крані. І подумав, шо хотілось би зробити більш приземлений моніторинг, бо не всі сервіси підвʼязані до фізичних речей, а дізнаватись про те, що щось лежить, краще раніше. Давно чув про Uptime Kuma, і тут настав її час. Спочатку хотів закинути її в Oracle Cloud, в мене там давно лежить аккаунт і я памʼятав, що там є безкоштовні віртуалки. Проте реальність скоригувала мій ентузіазм: вільних безкоштовних віртуалок нема, тому йдемо далі. Claude порадив спробувати Google Cloud, там є безкоштовні віртуалки, і вони створюються дуже просто. VM створилась через gcloud CLI, якого смикав агент, і за пару хвилин все вже було підняте. Docker Compose, віртуалка додана як environment до Portainer, GitOps, все як книжка пише. В результаті в мене зʼявилась маленька VM, яка через Tailscale дивиться на домашні сервіси. Пододавав туди Umbrel, Bankoscan і ще кілька хостів. Bankoscan навіть отримав свою статусну сторінку. Це одна з прикольних фіч Uptime Kuma, не треба ставити Atlassian Statuspage. Підняв, дивлюсь яке воно зелене, думаю "треба затестити". Вирубаю живлення з компа, за пару секунд все червоне, бот в телеграмі каже, шо воно попадало, є відчуття контролю. Але коли я врубив комп назад, сервіси не позеленіли, точніше позеленіли не тільки лиш всі. І так я бонусом до моніторингу отримав цікавий досвід відновлення проду, який трохи розтягнувся в часі, на вечір і ранок, і в просторі, в локальній мережі і поза нею. Там були проблеми з Tailscale після рестарту, сервіси повипадали з tailnet, і частина квесту була “дістатись до місця проблеми”. Та історія, коли інструменти для ремонту дверей лежать за дверима, які зламались і не відкриваються. Але який кайф в процесі відновлення отримати в телезі повідомлення від боту про те, що сервіс відновився, 10 з 10, рекомендую. І зараз я вже точно знатиму, коли що де відпало. До того, як сусіди почнуть скаржитись у вайбері.

У нас в будинку частина автоматизації крутиться на маленькій Lenovo-коробці: Home Assistant, Docker, всякі штуки, які мають просто тихо працювати і не нагадувати про себе. Нагадали через воду. Почались скарги від мешканців, що немає нормального напору, а виявилось, що десь блимнуло світло, відімкнувся smart switch, який керує насосом, і Home Assistant чомусь не увімкнув його назад, хоча мав би. Яжайтішнік, лізу дивитись, а там сюрприз: сервер зник з Tailscale. Він стоїть у підвалі headless, без монітора і клавіатури, тому я приніс його додому, підключив живлення, а він при кожному reboot пищить два рази. А з дитинства я виніс урок: якщо воно пищить під час старту, то там шось погано. Шо роблять норміси: підключають монітор і дивляться, що воно пише. Але там чомусь вибір між VGA та mini DisplayPort, а в мене всюди HDMI. В коробку з кабелями лізти не хотілось, тому переходимо до плану Б. План Б був тупий і прекрасний: запустити Claude Code, знайти компа в мережі і зайти туди по SSH. Він знайшов машину, шось сам подивився, потім попросив sudo, понакидував команд, я давав йому вивід, і воно все розрулило. Деталі писати не буду, їх багато і вони цікаві лише в моменті. Але головний прикол у тому, що Claude Code почав з найгірших сценаріїв: RAM, термопаста, CMOS battery. Була навіть красива теорія, що батарейка сіла, годинник скинувся, TLS перестав працювати і тому ліг Tailscale. Тут довелось трохи підрулити агента і попросити спочатку перевірити дату, бо перед тим як міняти батарейку непогано б дізнатись, чи вона справді скинулась. Дата була правильна, теорія розбилась, після sudo він дорозбирався вже по логах. Після цього він докопався, що два beeps були не через мертве залізо, а через налаштування BIOS. Сервер стартує без клавіатури, а BIOS вважав це помилкою. І тут вау момент: на Lenovo можна міняти BIOS settings з Linux через SSH. Без монітора, без F1 dance, без коробки кабелів. Замість розбирати комп і копирсатись у залізі, весь maintenance пройшов у сесії Claude Code. Окремо зʼясувалось, що Tailscale ліг не через beeps, а через мережу: щось з DNS/IPv6 на тій локації. Спочатку блимнуло, а потім токен протух. І тут висновок уже для мене: треба додати зовнішній monitoring доступності. В мене якраз простоює Oracle Cloud, звучить страшно, але там безкоштовний план, закину може туди Uptime Kuma. Бо поки що monitoring у мене був простий: якщо вода ледве тече, значить прод впав.

Найсмішніша історія про автоматизацію в моїй родині була про Excel. Ще в студентські роки моя дружина прийшла на практику в державну контору, їй дали компʼютер з Excel-табличкою, колонку цифр і завдання просумувати її. На це виділили день, олівець і калькулятор. Вона не зрозуміла приколу, натиснула кнопку "автосума", і отримала результат менш ніж за секунду. Начальниця дуже здивувалась, сказала, шо це якась хрінь і треба все одно перевірити на калькуляторі, бо "може воно шось пропустило". Цю історію я пригадав, коли побачив бурління в твітері щодо фрази Uncle Bob (той самий дідуган, шо написав Clean Code і не тільки), що він не переглядає код, який генерить AI. Каже, шо він програмує з 60х років, трохи побачив життя, і вважає, що ручне ревʼю вбиває увесь потенціал AI. Ось розбір: https://www.explainx.ai/blog/uncle-bob-ai-coding-gauntlet-tests-not-reviews-july-2026 Програмістам це звісно не сподобалось. "Діду треба випити пігулки, як це — не робити ревʼю?! Це ж AI, воно недетерміноване і напише фігню". А я тут бачу позицію захисту. У зону, де розробники відчували себе богами, без попередження з ноги увірвався ШІ і став робити це швидше, а часто ще й краще. Навіть закоренілі ШІ-песимісти бачать, що їх аргументи розвалюються. В твітері час від часу зустрічаю зміну тону з "та воно тупе, лол" на "блін, воно працює канєшно, але якось без душі". І тут доведеться перепитати себе, за що нам платять. Багато розробників думають, шо за код, але код це інструмент. Очікування — це та сама "value", про яку розказують на тренінгах і в ютубах. Як тільки згадуєш, що від тебе очікують результат, а не символи в репозиторії, все стає менш драматичним. Проте шо ж робити з недетермінованою натурою LLM? Воно ж дійсно може написати неправильний код, як це виправити? Так само, як і виправляли це в до ШІ епоху: за допомогою перевірок та обмежень. Це constraints, тести, acceptance criteria, coverage, mutation testing, complexity metrics тощо. Є купа методів, більшість з яких так само можна автоматизувати за допомогою ШІ, без необхідності робити людину bottleneck. Це саме те, що робить Uncle Bob, і тут я його плюсую. А ревʼювити код, який нагенерив агент, це те саме, що перевіряти ексель калькулятором. Звісно, ексель неправильно порахує, якщо обрати не той діапазон, та і калькулятор помилиться, якщо натиснути не ту кнопку. І результат треба перевіряти. Просто ті, хто вміє скейлити перевірку, обженуть тих, хто досі тримається за калькулятор.

Неочевидний tailscale Я довго використовував Tailscale як зручний ssh до домашніх (і деколи диких) хостів. А потім виявилось, що не кожен корисний сценарій починається з "додай цей хост у tailnet". Бо, наприклад, можна зайти на машину, якої немає в Tailscale, через хост, доданий до Tailscale. Для цього достатньо ssh jump host: ssh -J user@tailscale-host user@internal-host. Якщо таких машин багато, є subnet router. На Tailscale вузлі запускаєте tailscale up --advertise-routes=192.168.1.0/24, підтверджуєте маршрут в адмінці, і вся підмережа стає доступною через цей вузол. Але це вже не доступ до одного сервера, а доступ до шматка мережі, тому ACL краще перевірити до того, як воно "просто запрацювало". Або проміжний варіант: не відкривати всю мережу, а прокинути лише один внутрішній IP. Наприклад, хост сидить у корпоративній мережі, сам він уже в Tailscale, але частина посилань або конфігів зав'язана саме на його внутрішній IP, а не на Tailscale-адресу. Тоді можна підняти subnet router не на /24, а на один хост через /32: tailscale up --advertise-routes=10.0.0.15/32. В результаті доступ буде лише до 10.0.0.15, без відкриття всієї підмережі. Ще один сценарій: внутрішні веб-тулзи. Маленький дашборд, портал, адмінка для себе, щось навайбкоджене за вечір. Кладете це на машину в tailnet і не виставляєте в публічний інтернет. Для особистого тулза HTTP часто ок, бо трафік між Tailscale nodes все одно шифрується на іншому рівні. Браузер може нити, частина web API може хотіти secure context, але якщо це ріже очі, TLS теж можна додати через Tailscale. Тобто Tailscale це не тільки "ssh додому". Це ще jump hosts, route на один внутрішній IP, subnet routing, приватні веб-інструменти, доступ до dev/staging машин без публічних портів і нормальний спосіб не тягнути все через bastion з VPN-ритуалами. Дуже недооцінена штука, ставте собі бігом і пишіть в коментарі ваші юзкейси.

Побачив на каналі Devs Hive пост про запуск stack overflow для AI агентів. З однієї сторони добре, що бізнес не зупиняється і шукає варіанти, а з іншого — шо їм ще робити? По факту AI знищило Stack Overflow, принаймні точно змусило скинути жирок, і тепер вони хочуть щось отримати взамін. Я свого часу на Stack Overflow непогано розкачався, назбирав щось близько дванадцяти тисяч репутації. Спочатку просив команду і знайомих зайти й лайкнути мої відповіді, бо без стартових балів там тебе просто ніхто не бачить. Але десь після сотні-другої воно поїхало саме, і далі репутація накручувалась уже без ручного підпихання. Часи були непогані. Дійсно майже все шукалось на SO, репутація там справляла враження під час співбесід, а її (репутації) набивання було таким доволі цікавим челенжем. Але з часом додавалось все більше драми, люди в гонитві за балам робили токсичні речі, закривали питання як дублікати (хоча в оригіналах були старі і неактуальні відповіді), робили дурні правки і усіляко збільшували поріг входу для нових користувачів. Самоорганізована система самоорганізувалась навколо самої себе і стала доволі недружньою для новачків. Через це трафік став падати, і є думки (https://www.youtube.com/watch?v=LqWHmiugBWc), що занепад не був насправді спричинений появою AI, а був неминучим і так. Шо скажете? Який у вас рейтинг на Stack Overflow?

В твітері минулого тижня палала хаскель-драма через те, що якийсь проект почав міграцію Haskell --> Python. Засновник проекту, як я зрозумів, помітна постать у Haskell-спільноті, тож це піддає жару до загального палання дуп. Причина в тому, що дуже повільний цикл зворотного звʼязку через компіляцію критично не підходить для AI driven development. Я про це вже писав ось тут. І виходить, що повільний динамічний інтерпретований Python у реальному бізнес-світі підходить краще, аніж супертипізований компільований Haskell. Це не сподобалось адептам функціональної чистоти, які почали розганяти зраду. Драма цікава, бо тут прямо клондайк тез для срачів. Ось декілька з них: - Haskell використовується в проді - AI-агенти менш ефективні з мовами, які компілюються - Python краще за Haskell - швидкий цикл зворотного звʼязку важливіший за швидкий рантайм - бізнесу пофіг на чистоту мови і її систему типів - прагматичні рішення дратують поціновувачів чистоти Яку з цих ви будете захищати / атакувати? Але жарти жартами, а пост почитайте, там дійсно цікаві думки. Мені сподобався момент, коли пачку агентів юзаєш не лише щоб пиляти фічі паралельно, а щоб одну й ту саму фічу зробити різними способами, потім порівняти і обрати те, що треба. Схожий підхід колись читав у книжці Де Марко про розробку, там було декілька команд, які робили одне й те саме і нічого не знали одна про одну, а на виході обирали найкраще рішення. Здається, зараз з AI це те, куди треба дивитись і активно юзати. Бо вартість генерації рішення постійно зменшується, і цим треба активно користуватись.

Ось така смішна картинка викликала ланцюжок думок. Чого pyhon так працює? Хоча насправді я знаю, і всі пітоністи знають. Це прикол із серії "тупого" javascript, у якого 2+2=22, де насправді абьюзиться якась фіча мови, і нормальна робота виставляється, як якась дічь. А от цікаво, скільки часу і ментального ресурсу спалили схожі питання на інтервью? Вони ж нічого не показують, крім того, що людина вже бачила цей прикол. Абсолютно ніяк не впливають на якість роботи. Бо як тільки воно стрельне, ви пофіксите, погуглите і далі вже будете знати. Зараз це взагалі не актуально, бо агенти ніколи такого коду не напишуть, і весь дискурс навколо цього втрачає сенс. А може і взагалі дискурс навколо коду втрачає сенс. Бо яка різниця, шо в тому коді, якщо туди не дивишся? З кодом працює агент, і людські критерії для нього зовсім не факт, що корисні. Може він використає цей патерн для вирішення задачі, а у іншого агента не виникне ніяких проблем з розумінням, бо "воно ж так працює, шо тут не так?" Ну а остання думка "шось давно нічого не кодив, хоча тікетів назакривав і фіч наробив доволі багато". Сходу незрозуміло, це добре чи погано, але точно трохи сумно.

Disaster recovery це просто, особливо для тих, хто його ніколи не робив. Впав сервак, в тебе є другий. Впав дата-центр або availability zone, ти запускаєш резервний. Впав регіон, що буває дуже рідко, але provider має декілька регіонів, тому ми робимо мульти регіон. Ну а якщо впав вже провайдер, що майже ніколи не стається, тоді додаємо іншого провайдера. І такий сетап здається абсолютно bulletproof. Різні варіанти, ready standby, multi master і багато інших цікавих термінів з курсів про системний дизайн. Зробили і сидимо, скролимо твітер, та нічого не боїмось. От і Datadog так думали, пʼять регіонів по AWS, Azure і GCP. Аж поки ще у 2023-му вся ця краса не згасла одночасно. Не землетрус і не пожежа, а рутинний апдейт. Патч для systemd (програма, що керує сервісами на лінукс-серверах) рестартнув мережевий сервіс, а той має звичку викидати всі маршрути, які створив не він. Cilium (те, що будує мережу між контейнерами в кубернетесі) тримав свої правила маршрутизації подів просто в ядрі, systemd не впізнав їх як свої і повидаляв. Чому він це зробив? Тому що може, в лінуксі правила міняти дозволено будь-якому процесу. Звʼязок між нодами обірвався, і не в одному регіоні, а скрізь, бо апдейт викотився на всю гопотеку (40К серваків) в один і той самий момент. Про те, що прод лежить ти зазвичай дізнаєшся від Datadog, до того, як прибіжать юзери. А от коли падає сам Datadog, шо робити? Інженери діагностували і фіксили аварію як діди колись, через ручні SSH-сесії й консолі провайдерів. Розважались майже добу, поки воно не піднялось. І часом дуже добре, шо ти не Датадог. (деталі історії можна подивитись у цьому відео)

Писали ми тести для флоу, де користувач підписує документ через віджет id.gov.ua і атачить його у наш застосунок. Тест на Playwright генерував DeepSeek, він слухняно відкрив сторінку, потицяв кнопки, а підпис не пройшов. Далі він трохи поколупався, погуглив і зібрав красиву теорію, чому ні. Теорія така. Браузер не дає скриптам підробити довірену подію. Прапорець event.isTrusted стає true лише тоді, коли клік зробила жива людина, а не код. WebCrypto без цього прапорця підписувати відмовляється. Отже, поставити підпис автоматично неможливо в принципі, і це обмеження безпеки браузера, а не проблема Playwright. Звучить круто, у це легко повірити і наче час писати в тікет "автоматизувати не можна, кличте тестувальників". Я подумав, шо добре було б написати про це пост сюди, але вирішив трохи фактчекнути, шоб потім не розгрібати коменти. Закинув історію в Claude Code, і виявилось, шо DeepSeek трохи перебільшив. WebCrypto узагалі не вміє ДСТУ 4145, підпис накладається кастомним JS / WebAssembly. А isTrusted справжній, підробити його з коду дійсно не вийде, але тільки якщо кидати подію програмно, через dispatchEvent. А Playwright так не клікає. Його click іде через протокол керування браузером, на рівні самого движка, і для сторінки цей клік невідрізняний від людського, isTrusted у нього чесний true. Тобто та єдина стіна, об яку тест нібито вперся, Playwright спокійно проходить наскрізь. Я дав цей вердикт назад DeepSeek, той подивився, визнав свої помилки, зробив декілька спроб і у нього все вийшло. Виявилось, шо він пропустив десь селектор, куди тицькати чи ще щось таке. З ким не буває. Тому замість посту про обмеження тестування в браузері маємо цей, де обмежень майже немає. Навпаки, Playwright у парі з AI це дуже потужна зв'язка. І навіть не для автоматизації, а для exploratory тестування — треба щось потикати в браузері, використовуєте скіл playwright-cli і не паритесь. Наступного разу, коли агент скаже вам "це технічно неможливо", спитайте, чи він просто не знайшов селектор.

Чув колись анекдот про солдата який косив траву біля штабу. Офіцери виходили на перекур, бачили його і пропонували різні покращення, типу "позаду граблі причепимо, щоб одразу траву згрібав". Після чого зазвичай отримували підвищення. А останній ніяк не міг придумати, і йому сам солдат запропонував "ще ліхтарика мені на лоба почепіть, шоб я і вночі косив". Згадав я його, коли прочитав пост з дружнього каналу про /loop і /goal. Колись все починалось з контекстних підказок від copilot, потім чат, відповіді якого треба було копіпастити, потім агенти, шо все самі роблять. Але хто ми такі, шоб не хотіти більшого. Ось наприклад, агенти простоюють вночі, коли ми спимо, або ж постійно відволікають питаннями, на які відповідь "ага, роби як кажеш, мені ок". І тут як рез ці самі лупи і голи стають в пригоді. Можна запустити цикл "перевіряй CI кожні 10 хвилин, як щось задеплоїться, запускай тестування". Або ж "ось тобі мета — досягнути 100ms затримки на цьому ендпоінті. Роби шо хочеш, але треба 100ms". І усе — далі можна йти відпочивати, агент з усім розбереться. Зупинити його може або досягнення цілі, або витрачання лімітів. Такі інструменти змінюють модель від реактивної до проактивної взаємодії. Замість того, аби питати "ой, в мене тут помилки в логах, шо робити?", хай агент парсить ті логи і тригериться, коли бачить помилки. Заводить баги і фіксає. Користуєтесь таким? Накидайде ваших сценарієв в коменти.

Багато розробників живуть в IDE і не скаржаться. Проте щойно треба щось зробити з іншого компа, виникає питання із серії "а как какать". Як підключитись, AnyDesk? TeamViewer? Обидві схеми працюють, але однаково незручні, вибагливі до якості мережі і зазвичай лагають. А поціновувачі консолі цим не паряться. Підключаєшся по SSH і одразу опиняєшся в знайомому терміналі. Усе, що треба, або вже є, або можна доставити однією командою. Якщо дуже треба і хочеться, можна сінканути свої dotfiles і тоді взагалі все буде як вдома. Vim виглядає так само, як і на локальному компі, а ви спробуйте таке з vscode чи повноцінною студією / ідеєю. Дисконект теж не вбиває сесії, робота спокійно чекає на тому боці, і про це я вже писав тут (TL;DR: tmux / herdr). Чого знову про це пишу? Справа в тому, що для розробки на базі AI агентів цей сетап ще більш прикольний. На старому Intel-маку, що завжди увімкнений вдома, крутиться пачка агентів Claude Code. Закриваю ноут, іду у справах, воно молотить саме, повертаюсь, а задачі вже зроблені. Заходжу і з телефона, через клод-апку, тож замість залипати в тікток, або паралельно з ним, можна надиктувати агенту фронт робіт, щоб токени не простоювали. Все це залізо сидить у мене в tailnet, тож назовні нічого не стирчить, жодних відкритих портів, а доступ є звідусіль. Бонусом основний ноут майже не гріється, бо вся робота йде деінде, тож на ньому спокійно можна дивитись ютубшортс і читати твітер. Хай GUI-фанати далі воюють з лагами AnyDesk, а я поки закрию ноут, воно й без мене все доробить.