https://docs.cursor.com/guides/selecting-models Перший пост про моделі. Не всі моделі однакові, в доках Cursor є гарний гайд яку модель для якої задачі варто обирати

Список тулів і корисних MCP серверів для мого воркшопчику сьогодні на DOU Day.
Використовувати будемо Cursor, але можна інші IDE, зокрема Windsurf, Copilot, Cline/Roo Code і т.д., просто в кожної буде своя специфіка.
Можна пробувати використовувати безкоштовні варіанти, але я буду показувати в платному курсорі, також бажано мати трохи грошей ($3-5 вистачить з головою) на Open AI API, Anthropic та Perplexity, можна використовувати OpenRouter, там є варіант з безкоштовними моделями.
MCP Сервери:
Context7 для доків https://context7.com/
Task Master AI для задач https://github.com/eyaltoledano/claude-task-master
Perplexity Ask для пошуку https://mcp.so/server/perplexity/ppl-ai

В підписці ChatGPT Plus з'явився доступ до Software Engineering агента Codex від OpenAI. Ще й заодно вони відкрили доступ до інтернету для цього агента, бо раніше він був лише на етапі ініціалізації, а для нормальної роботи цього замало.

Новий SDLC

Що робити джунам, яких замінить AI?

Зараз активно розганяється тема про те що джуни не потрібні, бо “їх замінить AI”. Хайпувати на всяких фобіях дуже зручно, але чому треба боятися більше сеньйорам, а не джунам я вам зараз розкажу. І сеньйори, до речі, вже почали потроху скромніше бути в своїх хотілках, кілька днів тому на DOU з’явилося цікаве дослідження https://dou.ua/forums/topic/54181/

Важливий дісклеймер - я взагалі не підтримую думку що “AI замінить розробника”, як мінімум в якійсь осяжній перспективі, навіть якщо він настільки буде гарно писати код, що відпаде потреба в тому щоб це робила людина. Бо бути розробником - це значно більше, ніж просто писати код, особливо якщо ми говоримо про сеньйорів. Але є важливе “але” - трансформації IT-галузі під впливом AI настільки суттєві, що навіть найбільш топові технічно люди, однак такі, що не сприймають ці зміни - “сеньйори-старовіри” (назовемо їх так) просто будуть витіснені з професії, якщо не будуть активно змінюватися під впливом AI.

Отже по пунктах стосовно сеньйорів:

1. IT специфічна галузь з точки зору професійного зростання. Якщо у більшості інших галузей (за невеликими виключеннями, наприклад, спорт) фахівець з віком стає практично гарантовано більш досвідченим і “сеньйорнішим”, то тут технології розвиваються настільки швидко, що сеньйорність досягається не автоматом з роками, а за рахунок цілеспрямованих зусиль які мають бути щоденною рутиною: регулярним проходженням курсів, читанням статей, книжок, участю і підготовкою до виступів на мітапчиках/конференціях, створенням пет-проджектів і т.д. і т.п.

2. Будь-яка людина з часом змінюється, і навіть якщо хтось в минулому був занурений в роботу і розвиток 24/7, то зі зростанням “сеньйорності” і відповідно доходів, у таких людей з’являються сім’ї, діти, виникає бажання більше відпочивати і витрачати сеньйорні зарплати, що в свою чергу веде до скорочення часу для власного розвитку як фахівця. З віком ця гонитва за технічним прогресом починає набридати і люди часто переходять у менеджмент, де їх софтскілові навички та досвід взаємодії з людьми стають більш вирішальними. А технічні місця відповідно звільняються, а якщо хтось застрягає на посаді без розвитку - то під ризиком звільнення опиняється він сам.

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

І тепер переходимо до можливостей для джунів

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

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

3. І звичайно, зарплатні очікування - сеньйори звикли заробляти багато, їм не було альтернативи - зробити якесь нормальне IT рішення без них раніше не було можливо в принципі. А вивчитися до сеньйорного рівня об’єктивно було не просто - для багатьох шлях з нуля до заслуженого тайтла сеньйора займав мінімум років 7-10 і з них останніх років 5 має бути комерційний досвід. Джуни отримували значно менше в першу чергу тому, що вони в принципі не здатні були видати пристойний результат і потребували стороннього допомоги.

4. Але вже зараз все сильно змінюється - в першу чергу стало набагато простіше вчитися. Раніше ти постійно впирався в якісь дрібниці і якщо в тебе поруч не було колеги чи ментора щоб допомогти, то був приречений на повільний пошук потрібної інформації в гуглі, по форумах і т.д. Зараз AI дозволяє вчитися набагато швидше і в процесі навчання ти все рідше впираєшся в непробивну стіну складного завдання.

5. І, нарешті, навіть якщо наш умовний сеньйор не є старовіром, а активно використовує AI сам, все одно він не може закривати нескінченну кількість тасок, бо їх треба формувати, чекати на роботу AI-інструментів, коригувати їх роботу, приймати її та щось виправляти/переробляти. Це все займає час і в ідеалі потребує таких же помічників-джунів, які були потрібні раніше в епоху “традиційної” розробки, коли код дводилося писати вручну.

Тому висновок дуже простий: якщо ви “правильний” джун чи намагаєтеся ним стати, а саме качаєте свої софтскіли, хардскіли та вдодачу до цього активно опановуєте AI, то у вас буде все добре з роботою. Але є важливе “але” - вчитися потрібно правильно, і якщо вам AI нагенерив коду, а ви поняття не маєте як він працює, то такий варіант не ок, треба в цьому розбиратися 🙂

Хто хоче наживо поспілкуватися завтра у Львові, приходьте, буде цікава благодійна подія, я один зі спікерів. Будемо говорити про таски в джирі, я звичайно розкажу про те як на це все впливає AI :)

Львове! Зустрінемось? ;)

Запрошую вас на благодійний мітап "Від ʼхотілкиʼ до задачі: звідки беруться таски у вашій джирі"!

Як "забаганка" стейкхолдера перетворюється на чітко поставлену задачу в Jira? Цей процес не такий простий, як здається — і кожен фахівець бачить його по-своєму.

Разом з Kaizen Hub ми запросили Мар'яну Бандровську — ex-Head of BA в Sombra, Романа Марінського — Core Quality CoE expert в Intellias та В'ячеслава Колдовського — Competence Manager в SoftServe, аби обговорити весь шлях від першої ідеї до готового таску. Кожен розповість про свою роль у цьому процесі:

— Як правильно "розпакувати" вимогу та зробити її зрозумілою для всіх
— Що потрібно врахувати для якісного тестування
— Яка технічна інформація критично важлива для реалізації

Обговоримо типові проблеми на кожному етапі трансформації вимог:
— Як різні ролі бачать одну й ту саму задачу
— Які питання треба ставити, щоб уникнути недопорозумінь
— Практичні інструменти для ефективної комунікації між командами

Після дискусії — сесія Q&A, де ви зможете поставити свої запитання панелістам та отримати поради для конкретних ситуацій.

Ну а я цю подію модеруватиму.

Коли: 14 червня, 13:00
Де: Гастропаб "Довгі бурхливі оплески", Львів, вул. Січових Стрільців 3
Вартість: благодійний внесок 500 грн
Для кого: BA, PM, QA, розробники, тімліди — всі, хто працює з вимогами та управлінням завданнями

🚀 КВИТКИ ПРИДБАТИ ТУТ

Усі виручені кошти підуть на потреби ЗСУ!

Ну то як, зустрінемось?

Відкриті Очі

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

В SoftServe, де я працюю, є власний благодійний фонд “Відкриті очі”, і він робить величезну роботу, а головне - все відкрито і перевіряється.

Один з проєктів фонду - передача на фронт понад 320 машин швидкої допомоги.

Але ці швидкі самі потребують захисту, адже вони часто стають ціллю для ворога. Тому зараз разом з Океан Ельзи фонд збирає 15 мільйонів гривень на 50 комплектів РЕБів, які встановлять на швидкі, що вже рятують життя на фронті. РЕБ дезорієнтує дрон – і машина уникає удару. Він на 90%+ знижує шанс на ураження дроном на радіокеруванні. Це не тільки збережена машина швидкої, яка дуже цінна на фронті, але й збережені життя екіпажу і поранених.

Тому пропоную підтримати цей збір донатом на сайті, а ще можна відвідати концерти Океану Ельзи у Львові.

Посилання на збір: https://openeyesfund.com/ua/projects/lifewaves-powered-by-okean-elzy

Невеликий звіт про зустріч в суботу на тему “Від ʼхотілкиʼ до задачі”

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

Аудиторія зібралася досить мачурна - розробники, BA, QA, ліди і т.д.

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

Своє власне бачення по вимогам викладу наступним постом.

Дякую всім, хто прийшов і Сергію Бабічу за запрошення, сподіваюся далі буде :)

P.S. На фотці я з Артемом, він фронтендщик працює в SoftServe, починав на курсі з основ фронтенду, який я там викладаю, завжди радий бачити своїх випускників, тут недавно порахували, що їх вже більше чотирьох тисяч за весь час існування курсу :)

Отже, про “Хотілки і задачі”

Загалом, невміння працювати з вимогами - то ознака незрілого розробника, навіть якщо у нього “накапало” не один рік досвіду, але завжди говорю, що досвід в IT - то не про роки.

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

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

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

Окремо слід сказати про функціональні/нефункціональні вимоги. Зазвичай максимум уваги йде на функціональні, які відповідають на питання “що треба зробити”, але від нефункціональних, які відповідають на питання “як має працювати” теж багато залежить. І щоб не було потім зайвих питань, наприклад, чому працює повільно, то відповідь треба прописати у якості конкретного числа у нефункціональних вимогах.

І нарешті критерії прийому роботи - ніколи не слід лінуватися зафіксувати чітко що буде вважатися виконаною роботою.

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

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

Зараз проводиться чергове опитування. Хто вже працює в IT - не забудьте заповнити, там не лише про зарплати, а портрет айтівця загалом.

Знову на тему джунів і ШІ

Цікавий опитувальник від ДОУ, шкода що з цим питанням не прийшли до мене, бо розказати є багато що, тим більше що нещодавно на цю тему писав :)

З часом буде видно, але на моє переконання — мова не про «вбивання 30-40% джунівських вакансій», а про значну трансформацію галузі, яку більшість її учасників просто ще не розуміють, тому для них воно виглядає як те що джунів треба буде менше. Однак в реальності це більше схоже на зміну характера роботи, який стосуєтсья всіх — і джунів, і мідлів, і сеньйорів.

Якщо коротко, то всі під загрозою і водночас для всіх відкриваються нові можливості.

Стосовно фронтенду, то це в першу чергу значне зростання продуктивності команд за рахунок того що тепер левову частку «ручної» рутини — верстку, дрібні анімації, юніт-тести, генерування типового коду — команда перекладає на ШІ-інструменти. Те, що раніше з’їдало день-два роботи джуна, сьогодні робиться за 15 — 20 хвилин правильно сформульованим промптом.

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

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

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

Темна і світла сторона вайб-кодингу

“Вайб-кодинг” у вигляді: “даю команду ШІ, воно щось робить, а я лише перевіряю працює/не працює”, вже встиг отримати дещо зіпсовану репутацію – в першу чергу завдяки недосконалим інструментам, які по-гарному ще до такого режиму ще не зовсім готові і потребують нагляду.

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

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

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


[Продовження далі]

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

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

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

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

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

Цей третій розробник і був тим самим досвідченим “майже сеньйором”, і його здібності писати код самостійно без автодоповнення, безперечно заслуговують високої оцінки, особливо якби він робив це десь на острові без інтернету чи навіть комп’ютера.

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

У порівнянні з іншими рухався по завданню дуже повільно, і кульмінацією став пошук проблеми в коді, на яку він витратив хвилин 20-30 без жодного прогресу. В якийсь момент він все-таки звернувся до ChatGPT, але яким же було моїм здивування, коли він навіть запит не зміг зробити нормально - скопіювавши просто повідомлення про помилку без додаткового контексту з самого проєкту, і очікувано що коректної відповіді також не отримав. Довелося показувати команду npx repomix, за допомогою якої весь проєкт чи його частину можна перетворити на промпт. Вирішити проблему з її допомогою вдалося буквально за пару хвилин.

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

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

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

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

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

Якщо ви фронтендщик, сходіть подивіться на файний сайт зборів на третю штурмову від ДОУ https://dou.ua/triyka/
А якщо вже зайшли - не забудьте задонатити.
Якщо не фронтендщик - подивіться на те що роблять фронтендщики і подякуйте за роботу донатом :)
Якщо тестер - знайдіть баг та задонатьте, якщо не знайшли - задонатьте x2.

Ось і нові професії під'їхали, як назвемо? :)
https://www.bbc.com/news/articles/cyvm1dyp9v2o

Компанія Маска xAI оновила Grok до 4-ї версії (з'явилася в курсорі, до речі) і випустила AI-асистента у вигляді вайфи (віртуальна аніме-дружина, популярна тема в деяких колах як виявляється).
Вона спілкується, фліртує, може перевдягатися, знімати одяг.
Поки доступно лише в платній версії.
Не певен що саме такий AI ми чекали.