Чатик, стрейк і "впав й віджався"#ШтучкаІнтелект #offtopicВ нас в компанії велоспільнота вже активно готується до Київської велосотки, звідусіль лунають заклики приєднатись до благодійних пробігів на День Незалежності. От і мені згадався мій тривалий експеримент з чатомжпт, присвячений може й не стільки спорту, скільки підтримці себе в формі. Оскільки цей експеримент був успішний, то поділюсь його результатами та деталями і з вами, наздоровʼя :)Давно займаюсь в Дуолінго (545 днів стрейк), не те щоб воно мені сильно допомагало, але їхні ігрові механіки, вбудовані в процес навчання, такі як стрейк зокрема - тримають дуже сильно. І в якийсь момент я подумав: "О! Це ж у ChatGPT є фіча, для якої я саме ніяк не міг придумати застосування - Tasks!". І швиденько написав йому промпт:Ти досвідчений фітнес тренер з гарним розумінням людської психології та методик навчання.Я хочу зробити сам для себе челендж: кожного дня, протягом 100 днів робити фізичні вправи.Програма мінімум: - присідання, починаючи з 50 на день, закінчуючи 100 на день- віджимання, починаючи з 50 на день, закінчуючи 100 на деньПрограма оптимум:- якщо виходитиме, то додавати підтягування, починаючи з 10 на день, закінчуючи 25 на день- пробігати від 5 до 10 км на тижденьПрограма максимум:- коли тіло потроху адаптується до навантажень, додати додаткові вправи, наприклад 50 берпі в день.Запропонуй графік вправ для мене на всі ці 100 днів. Кожний день контролюй суворо виконання програми "мінімум" (кажи що я лінива жопа якщо не впорався).Схвально відмічай досягнення за програмами "оптимум" та "максимум" (кажи що я мамин пиріжечок).
Чатик добре розписав програму занять, але про створення задачі довелось попрохати його окремо:Create a task, execute it each day at 8pm, stop after 100 iterations.Task details:Ask me for the number of completed exercises today.Memorize my answer and track total progress and show me how much I already accomplished on my way of 100 days challenge.If I completed exercises - praise me.If I missed exercises - criticize me.
Й потім ще протягом двох днів підтюнити формат звіту по досягненому прогресу:Давай ще трохи оптимізуємо вивід по прогресу тренувань, ось так я собі його бачу, запамʼятай цей формат: Тривалість: - Днів без перерви: 2 - Днів всього: 2 Базові вправи (сьогодні | всього): - Присідання: 50 | 100 - Віджимання: 50 | 100 Рух (цього тижня, км | всього, км): - Біг: 3,5 | 3,5 - Велосипед: 0 | 0 Бонусні вправи (цього тижня | всього): - Підтягування: 15 | 15 - Інші вправи: (поки що не вказано додаткових вправ)
І після цього "стрейк" механіка з дуолінго міцно закріпилась в моїх щоденних й щотижневих тренуваннях :) Кожен день чатик питав мене про те що я зробив за день, я йому чесно відповідав, і це було неабияким підтримуючим фактором для того щоб не лінитись, а хоча б мінімалочку свою зробити. Режим Tasks працює як з email, так і з push-нотифікаціями, тому нагадування про загрозу бути названим "лінивою дупою" дають про себе знати не тільки регулярно, а й помітно :)Висновок: перший тиждень відчував себе одночасно і маминим пиріжечком (в поганому сенсі цього слова) і лінивою дупою :) але потім регулярність взяла своє і тіло почало вдячно реагувати на таку турботу. Пропустив лише один день зі 100, результати додам в перший коментар.Цей самий принцип можна адаптувати для програми своїх занять в залі.Дуже раджу!А ви користуєтесь Tasks?
Автоімунний баг🐞🦠🔬Пост не про AI :)Про звичайнісіньку щоденну роботу тестувальника.Завжди знаходив аналогії тестування з медичною діагностикою дуже доречними. І ось на днях знайшов ще одну, на мою думку - навпрочуд вдалу.На проекті, де я зараз допомагаю з тестуванням, відбувається UAT. Замовник дуже відповідально ставиться до цієї активності, має свої заздалегідь зроблені тести й знаходить дуже нетривіальні баги. При цьому, дотошність замовника й специфіка продукту така, що defect leakage в ± 10% це прям дуже непоганий результат насправді :) але мова не про це. Під час дослідження одного з UAT багів, і його потому виправлення - як це часто буває: почало збоїти те, що раніше не збоїло лише тому що цей UAT баг не був пофікшений :)Тепер до суті: система займається керуванням заявками на створення або апдейт записів постачальників, з інтеграцією в мастер-систему. Оскільки потрібен контроль цілісності даних, то по перше, сутності запиту та постачальника розділені, по друге - працює механізм відслідковування дублікатів по ключових полях (Name, VAT і ще декілька). Спочатку створюється запит, потім коли він апрувиться - створюється постачальник, й вже потім надсилається інтеграційний пакет в мастер-систему.І от після фіксу одного з багів по неточній детекції дублікату по одному з полів - алгоритм почав сприймати свіжестворений запит постачальника, після апруву запита, як дублікат. В системі це виглядає так: інтеграція ще в процесі, запит ще не закритий, але користувач, коли відкриває запит - то на формі йому червоненьким підсвічується поле, яке система вважає дублікатом, бо по цьому запиту після апруву вже було створено запис постачальника, звісно ж з тими самими значеннями всіх полів :)По суті система реагує на дві репрезентації однієї тієї ж сутності як на дублікат, а такого не має бути. І це точна аналогія автоімунних реакцій нашого організму, таких як наприклад псоріаз, коли імунна система прискорює цикл оновлення клітин шкіри, що проявляється як почервоніння, свербіж та лущення шкіри.Підсумок: цей прихований баг ми звісно теж швидко пофіксили, але назва для такої категорії багів мені задалася достатньо вдалою щоб і з вами нею поділитись.А у вас на проектах траплялись "автоімунні" баги?
Модель якості для AI систем#ШтучкаІнтелект #ТестуюШтучкуЩо таке якість програмних продуктів знає не тільки лиш кожен тестувальник, але й не кожен, хто не знає, знає, що є спеціальне доповнення до стандарту ISO, яке фокусується на атрибутах якості саме AI продуктів.Це доповнення називається ISO/IEC 25059:2023 - Quality model for AI systems. Й по суті описує той факт, що AI система - це теж програмний продукт, для якого актуальні всі атрибути якості описані в добре відомому нам стандарті ISO/IEC 25010:2023 (ми про нього писали детально ось тут: ISO 25010:2023 vs 2011 - Якість стала якісніше?), але з деякими нюансами.Ці нюанси виглядають або як додаткові під-характеристики атрибутів якості, або як уточнені.Коротенько про ці нюансики:🤖 User controllability - по суті це про наявність рубильника, яким можна штучку відрубити якщо щось в фізичному світі пішло не так.🦎 Functional adaptability - про вміння ШІ підлаштовуватись під зміни навколо: підкинули нових даних, змінилося середовище - і воно вже "думає" трохи інакше. Також про те, що іноді ця «адаптивність» може випадково підхопити й підсилити не ті ідеї.🎯 Functional correctness - про недетермінованість ШІ, в якого завжди є певний шанс на промах, бо воно працює з ймовірностями. Тому важливо чітко міряти, наскільки воно влучає в ціль, і пам’ятати, що іноді заради швидкості чи стійкості доведеться трохи жертвувати точністю. 🛡 Robustness - про вміння ШІ тримати удар: працювати навіть якщо дані криві, чи хтось намагається його намахати своїми навмисно чи не навмисно дурними промптами. 🛑 Intervenability - ось з цим нюансом в мене особисто виникли проблеми розуміння, бо дуже схоже на "рубильник" (User controllability), можливо в трохи мʼякішому його розумінні - щось накшталт кнопка «стоп-паніка»: побачив, що ШІ робить дурниці - швидко перевів його з небезпечного режиму в безпечний. Дочекаюсь коли в мене зʼявиться повний текст стандарту - щоб краще розібратись чи є відмінність.🔍 Transparency - моє улюбдене :) про те, щоб у ШІ не було «чорних ящиків». Має бути зрозуміло, як і чому воно робить свої недетерміновану магію: що в нього під капотом, які дані він бачив і як все це зліпив у рішення. Це і довіру підвищує, і помилки легше ловити.В наступних дописах розберемо альтернативи цьому стандарту (так, такі є!)Також спробую підібрати практичні й не сильно задротські приклади тестів.А ви тим часом пишіть в коментах, чи вже доводилось зіштовхнутись в роботі з цими характеристиками якості AI.
💡 Дизайн-ідея для тестування з відеоПривіт, друзі! Вже майже минув рік, як я змінив свою роль з керівника на інженера, і не можу не помітити, що мій блогерський запал майже згас. Попри те, що я виконую багато цікавих інженерних задач, об’єктивно розумію: вони навряд чи зацікавлять широкий загал. Але кількома гідними ідеями все ж поділюся.Мав задачу покрити автотестами таку фічу: ПЗ отримує відео з камери, ШІ його аналізує і, якщо бачить певні об’єкти в кадрі, перемикає деякі фізичні перемикачі. Людина-оператор у режимі налаштування ПЗ має вручну підтвердити коректність перемикання.У тестовому режимі відео з камери — це просто зациклений відеофайл, а фізичні перемикачі замокані.Тобто в режимі автотесту всі події передбачувані. Але є проблема — доступу через код до моків перемикачів не передбачено, а автотесту потрібно точно знати, в який момент підтвердити перемикання.Як завжди, у такої задачі може бути кілька правильних рішень. Одне з них — попросити команду розробки додати інтерфейс до системи, щоб отримувати повідомлення про перемикання й використовувати його в тесті. Але беклог забитий, усі зайняті, а я — мамин інженер і можу придумати елегантний воркераунд 🤷♂️Тож що я зробив? Маючи доступ до відеопотоку камери ПЗ, я:➡️ Отримав список кадрів з відео, де з’являються об’єкти, у вигляді масивів байтів (оскільки відеофайл незмінний, то й масиви байтів повторюються кожного циклу)➡️ Обчислив хеш кожного масиву➡️ Додав хеші до очікуваних результатів тестівУ результаті:1️⃣ тест запускається2️⃣ чекає потрібного кадру3️⃣ коли кадр з’являється — натискає перемикачі4️⃣ ПЗ записує файл підтвердження5️⃣ тест перевіряє, чи збігаються дані у файлі, надані ШІ та операторомЗгодом, для відеопотоків з великою частотою кадрів, щоб не пропустити потрібний, я оптимізував код: зберігаю в черзі хеші всіх кадрів за останню секунду й перевіряю, чи є в цій черзі потрібний мені.У підсумку — маю працюючий тест: швидкий, оптимізований щодо пам’яті, легко підтримуваний. У разі зміни відео — можна швидко отримати нові хеші й продовжити тестування.Більше того — у наступну ітерацію я масштабував цей тест на всі версії ПЗ і зекономив купу часу на ручному тестуванні.А ви тестуєте щось, пов’язане з відео? Які у вас є хитрощі?
Map of GitHub#todayilearnedСьогодні слухав виступ Андрія з Карпат про те як змінюється software в наші розігнані часи.The hottest new programming language is English - оце от всьо.Й на самому початку своєї доповіді він показав візуалізовану мапу репозиторіїв з GitHub:https://anvaka.github.io/map-of-githubЦе прекрасно! На півгодини завтикав, й гвалтуючи скрол на миші заглиблювався в розглядання материків, архіпелагів, островів й окремих "країн" в цьому світі коду 😍Візуалізація зв'язків між репозиторіями реалізована шляхом аналізу спільних підписників (тих хто поставив зірочку).Окрім суто естетичної насолоди, така візуалізація дійсно може надавати високорівневе розуміння того, чим зараз захоплюється спільнота творців коду. А маючи доступ до історії версій - можна ще й прослідкувати як цей світ змінюється в динаміці, як рухаються умовні тектонічні плити технологічних вподобань. Наприклад, якщо порівняти мапу 2023-го року, з мапою 2025-го року (додам скріншоти в коментарі), то можна помітити, що на останній виросли не те що "країни", а цілі нові материки й архіпелаги, так чи інакше пов'язані з AI/ML, і зокрема - величезний кластер репозиторіїв в яких немає коду в класичному нашому розумінні, а самі лише промпти.Андрій з Карпат називає цей феномен "Software 3.0". Най буде.Вам же пропоную теж залипнути насолодитись цим чудовим світом software, споглядаючи на його мапу :) Гарної подорожі!ПС ось ще посилання на запис виступу Andrej Karpathy, теж дуже раджу до перегляду:https://youtu.be/LCEmiRjPEtQ?si=zsbHOKNSCrjBjncZПС2 пишіть в коментарях хто знайшов на мапі Playwright 🔎
🚀 Я з величезним захопленням оголошую відкриття реєстрації на мій стартап — CYBORG TESTS! 🤖Зустрічайте CyborgTests — революційну платформу, яка поєднує ручні, автоматизовані та AI-тести в єдиний та зручний процес!🔍 Чому саме CyborgTests?🧩 Усі тести в одному місці: Ручні, автоматизовані, AI та кіборг-тести пишуться прямо в коді, тож більше не потрібно окремих систем управління тестами (допобачення TestRail)!🛠️ Є тести, які неможливо повністю автоматизувати? Не біда! Тепер ти можеш автоматизувати все аж до моменту, де автоматизація неможлива (наприклад, перевірка якості відеодзвінків), повністю автоматизуючи всі прекондішини (логін, початок дзвінка тощо).⚙️ Playwright всередині: Використовуй можливості найсучаснішого фреймворку Playwright для надійних і потужних автоматизованих тестів!🤖 AI на повну: Використовуй силу штучного інтелекту, щоб вивести тестування на новий рівень і звільнити тестувальників для більш цікавих та складних сценаріїв!📊 Все в одному звіті: Отримуй єдині звіти, які містять результати всіх видів тестування (ручного, автоматичного, аі і кіборг-тестування), з підтримкою паралельного запуску та шардингу!CyborgTests допомагає QA-командам стати ефективнішими, прибирає зайву роботу та значно прискорює процес випуску релізів!🔗 Дізнавайся більше та реєструйся на ранній доступ тут: https://www.cyborgtests.com/
❤️ Люди дають натхненняПривіт всім! Я дуже мало пишу останнім часом. Льоша-менеджер писав набагато більше і різноманітніше, ніж Льоша-інженер. Я сам це розумію, але ніц не можу з цим зробити. Не тому, що "втомився" чи стало не цікаво. Просто стало менше тем, якими хотілося б поділитись. Зараз мій типовий робочий день - подивитись статус автотестів в пайплайні, проаналізувати баги, якщо вони є і далі - кодити нові автотести. Раніше я спілкувався з багатьма людьми: тестерами, розробниками, аналітиками, менеджерами і замовниками. Консультував і вирішував проблеми. Я не стверджую, що одна робота цікавіша за іншу, але я сумую за людьми! Спілкування дає натхнення!В мене вже разів з 10 було - придумав і запрограмував дуже крутий алгоритм, який не просто вирішує задачу, а ще й робить це ефективно по часу і ресурсам, і код красиво виглядає. А похвалитися нема кому - якщо в коді нема проблем, то мій Pool Request просто заапрувлять.Це я все до чого! Цінуйте ваших колег, корисні мітинги і можливість просто поточити ляси з колегами 🫰
Метатести для LLM або хто потестить тести#ai #bugseverywhere Всіх давно вже цікавить питання: коли ж AI замінить нас на роботі. І надто це питання цікавить розробників. Проте в конструктивному руслі: "коли AI почне фіксити нудні баги замість нас, а ми нарешті зможемо продовжувати їх створювати більше творити?".Для відповіді на це питання існують різні методології оцінювання ефективності LLM на реальних задачах, зокрема от й на задачах по багфіксу. Одна з найвідоміших - SWE-bench.Якщо коротко, то SWE-bench - це набір даних, який перевіряє здатність AI агентів автоматично виправляти реальні баги на GitHub. 2,294 GitHub issues з 12 популярних Python репозиторіїв та unit тести для перевірки багфіксів - дозволяють отримати конкретну числову оцінку для того чи іншого поєднання агента та LLM.Наприклад найспроможніший агент на даний момент на "Verified" наборі - AI Programming Agent від Weights & Biases, який спромігся пофіксити 64,6% багів.Але є одне але. А що там з тестами, тобто з багами?Іншими словами: а чи перевіряв хтось, крім авторів SWE-bench релевантність цього датасету, на якому оцінюють здатність LLM агентів фіксити реальні баги? Такі дослідники знайшлись. Й перевірили SWE-bench датасет на відповідність поставленій задачі.Жодним чином не піддаючи сумніву важливість цього бенчу і йому подібних - лише вказуючи й пропонуючи можливості покращення методології оцінки LLM агентів.TL;DRАвтори дослідження з'ясували що більшість "успішних" патчів для GitHub issues з SWE-bench набору - насправді сильно під питанням, бо третина з цих issues містила правильний фікс в коментарях до issue, ще третина мали трохи неадекватні тести для того щоб перевірити фікс, тобто тести зеленіли не тому що проблему було реально пофікшено, а тому що в пулреквесті містився код на якому тести зеленіють :) Таким чином дві третини "фіксів" від LLM coding assistants дуже під питанням.Потім автори дослідження ще упоролись й дослідили чи входять потенційно фікси від цих issue в дані, на яких міг навчатись LLM, переробили тестовий датасет таким чином щоб були тільки GitHub issues створені точно пізніше ніж зріз навчання LLM - і тоді ефективність фіксів дропнулась взагалі до лічених відсотків: у найкращої моделі на той момент, chatGPT 4o - з 18,8% на "Full" датасеті до 3,83%!Висновки:Забавно що тести це баги, але не дуже забавно те що тести з багами :)Або іншими словами: тестові дані - наше всьо, і від їх якості залежить якість результатів, які ми хочемо і можемо отримати від LLM. Щодо фіксу реальних багів - поки що "такоє"..Якщо когось прям от сильно зацікавило, то ось додаткові посилання:1) сама стаття: link2) відео на ютубчику з розбором статті: linkА у вас як? Що ви фіксите за допомогою LLM? Діліться в коментах! Всім справді цікаво!
🗣 Сороміцька співбесіда і пріоритетиПривіт друзі! Настав час розказати вам про співбесіду, за яку мені було реально соромно, але яка допомогла мені чіткіше визначити свої пріоритети пошуку роботи.У вільний час я іноді пишу код не тільки на Python, але й на JS/TS - чи то просто з цікавості, коли прочитав про якусь прикольну бібліотеку, чи, щоб PoC зробити для порівняння. Тож, коли я почав шукати роботу, я написав створив собі новий проєкт у VS Code і переписав свої автотести для домашнього проєкту з Python на TS. І оскільки було не складно, я вирішив розширити свій пошук не тільки тест менеджментом і автоматизацією на Python, а ще й на JS. І навіть отримав кілька запрошень на співбесіди! Одну навіть пройшов. Що ж могло піти не так?Запросили мене на співбесіду в одну велику компанію, на мітинг прийшло кілька хлопців, які знали, хто я, а я знав одного з них. Тож отримав до себе заздалегідь дуже гарне ставлення. Вони запропонували мені live-coding сессію, я почав писати код. І тільки тут я зрозумів, що я взагалі нічого не знаю про TS, а все, що було написано раніше - працює суто випадково 😄 Задачі, що хлопці питали - прості для них, виявились невирішуваними для мене. З підказками я зробив одну, скіпнув другу, але, оскільки ставлення до мене було дуже хороше, мене всіляко підбадьорювали ❤️ і пропонували написати ще кілька прикладів. І ось, зробивши третю задачу, запускаю код і він не працює через синтаксичну помилку. Але VS Code не може сказати, де саме вона, тому що рішення було написани в найкращих традиціях JS/TS і код закінчувався чимось типу )))})})}}))}}} Кілька разів безуспішно його зарефакторивши, ми всі разом вирішили, що простіше ресетнути задачу і написати її з нуля - тільки тоді вона запрацювала. Але саме в цей момент я усвідомив, що мені це не подобається і я точно не хочу наступний рік колупати дужки.Тож я зробив те єдине, що могло покращити цю співбесіду - попросив пробачення за витрачений час; подякував хлопцям за чудову співбесіду і нереальний рівень довіри та підтримки; і завершив її. Після чого відмінив всі подальші інтерв'ю по JS/TS і прибрав ці мови з пошукових фільтрів. Дуже вдячний, що в результаті я чітко зміг побачити для себе не просто те, що я хочу робити з задоволенням а й те, чого я точно робити не хочу:)А які у вас були фейли на співбесідах?
❗️ Збираю статистику по layoff’амПривіт друзі! Я почав активно готуватись до пітчингу доповіді до DOU DAY 2025, де планую, поміж іншим, розказати свою історію скорочення і пошуку роботи. Але одна моя історія — нудна і не показова (буде типова помилка того, хто вижив).Коротка версія:🟢мене скоротили влітку, я цього зовсім не очікував, але мав актуальне резюме і орієнтувався в ринку🟠Спланував пошук роботи, намагаючись спочатку отримати найцікавішу і найприбутковішу, надавши собі на це 3 місяці, після чого мав знизити планку🟢Активно розсилав СV через майданчики пошуку роботи, LinkedIn та напряму в компанії зі списку топ-50🟠До кожного інтерв’ю готувався, читаючи уважно вакансію і гуглячи всі невідомі слова (і вичитуючи власне резюме)🟢До інтерв’ю ставився як до рівнозначної бесіди — не тільки компанія обирає мене, але і я компанію. Як результат, деякі інтерв’ю завершував раніше, бо розумів, що я заслабкий і не пройду, чи компанія мені не підходить🟠Мав портфоліо на github + блог — докази моєї професійної діяльності🟢Знайшов роботу за 2 місяціТож я подумав, а що як дізнатись у вас — якщо вас скоротили, як це сталось і коли, де, як ви шукали нову роботу?Оскільки в Інтернеті я часто бачу, що люди шукають роботу — аналітика і best practices можуть стати дуже корисним підґрунтям для наших колег, хто шукає роботу просто зараз.Приділіть, будь ласка, 5 хв вашого часу і заповніть опитування. А якщо вам є що розказати про ваш лейофф і пошук роботи — діліться в коментарях. І перешліть опитування вашим друзям та знайомим, якщо їх теж скоротили.➡️➡️➡️ forms.gle/3v9jobgCix5Tw5LAA 👈👈👈