У цій доповіді Владислав розповість про його шлях приборкання AI: від простого Plan Mode в Cursor/Claude до складних систем документування. Він розбере, чому GitHub Spec Kit виявився занадто важким, як ADR (Architecture Decision Records) допомагають агентам не «губити» контекст між сесіями і чому OpenSpec від Y Combinator (Fission-AI, W26) став для нас золотою серединою. Ключова теза: якість коду на виході = якість специфікації на вході. Разом поміркуємо про трансформацію ролі розробника — від «кодера» до «архітектора специфікацій».

Що якщо інженер отримує не задачу, а вже готовий PR з контекстом і пропозицією рішення? У Wix ми будуємо remote agents — автономні агенти, які тригеряться зовнішніми подіями (Jira, Slack), виконують задачу у фоні без участі людини і повертають результат як контекст для розробника. У доповіді я розберу: що таке remote agents, як вони влаштовані архітектурно, і як впровадити такого агента у себе в системі. Поділюсь реальними цифрами — success та failure кейси з нашого досвіду. Окремо — про неочевидне: де агенти ламаються, чому spec-driven підхід критичний для їх роботи, і що змінюється в процесах команди, коли частину роботи робить агент. Доповідь буде корисна тим, хто вже працює з AI-інструментами і думає над наступним кроком — від copilot до автономії.

Ще десять років тому ми тягнули в проєкти бібліотеки та фреймворки не від хорошого життя. Це був єдиний спосіб вижити в часи «бравзерних воєн» і не потонути в спагеті-коді. Фреймворки стали нашим порятунком, і ми до них звикли. З того часу веб змінився, а наші звички — ні. HTML, CSS та JS зробили величезний стрибок вперед, але ми продовжуємо автоматично тягнути мегабайти абстракцій, щоб просто відрендерити список товарів, і гордо називаємо це «сучасним стеком». Настав час поставити собі незручні питання: • Що насправді вирішує фреймворк сьогодні, окрім нашого страху залишитися наодинці з чистим JS? • Де межа, за якою «комфорт розробника» стає безглуздим тягарем для продукту? • Чи не став фреймворк просто зручною ширмою, за якою ми ховаємо небажання знати, як працює платформа? Я не закликаю видалити React завтра (хоча…). Але я прагну розібратися: чи досі фреймворки вирішують реальні технічні проблеми, а чи ми створюємо черговий Hello World на реакті просто тому, що вже не вміємо інакше?

Розповідати про щось абстрактне легко і прикольно – і розумним можна прикинутися, і перевірити тези ніяк не вийде – це ж абстракція. У світі, де кожен перший тепер "ШІ-візіонер" я хочу поговорити з вами про ШІ максимально предметно на прикладі своєї роботи – GitLab.  І це ідеальний приклад, поки всі розповідають про світ рожевих поні – greenfield проєкти, де все пишеться з нуля, я хочу поділитися досвідом хардкорного brownfield – що де і як на проєкті, що існує багато років. Ми поговоримо про те: - Як ми дружимо (або скоріше ні) штучний інтелект та джаваскрипт - Мої налаштування та секретний соус для агентської розробки - Які мої досягнення на пару з Опусом (улюблена моделька) - Скільки коду на джаваскрипті я пишу руками - Що заважає нам отримати оту міфічну х10 продуктивність і що я з цим роблю Я сподіваюся, що з цього case study кожен вийде з розумінням, а що саме зробити на своєму проєкті, щоб покращувати життя вже просто зараз.

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

Доповідь про те, як підвищити продуктивність розробника за допомогою AI-інструментів у Cursor — від автоматизованого читання та написання коду до створення AI-«колег» і побудови наскрізних пайплайнів розробки.

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

<p>JavaScript та Golang — це два різні світи, які часто перетинаються в сучасних проєктах: перший домінує у frontend-розробці та швидкому прототипуванні, тоді як другий — у високонавантажених сервісах та мікросервісних архітектурах. <p>У цій доповіді я поділюся власним досвідом переходу з JS на Go, порівняю підходи до асинхронного програмування, архітектури додатків, роботи з базами даних та інструментів. Ми розглянемо не тільки відмінності, а й спільні риси, які допомагають розробникам легше адаптуватися між цими екосистемами.</p>

У багатьох проєктах хуки стали рефлексом: їх додають автоматично, навіть там, де вони не потрібні. Але кожен зайвий хук — це додаткова складність, і часто — без вигоди. У цій доповіді разом з вами спробуємо розібратися, коли хуки не потрібні та як писати простіший та зрозуміліший код без зайвих use*.

В цій доповіді Дмитро розповість як створив DSL мову для парсінга HTML сторінок, яка використовується для WEB скрапінга. Поговоримо про алгоритми дерев, оптимізацію JS-коду, DOM, а також спробуємо це все на прикладі live coding.