Нещодавно Superhuman (раніше Grammarly) запустила Superhuman Go — AI-асистента, який працює поруч із вами на кожній платформі. Щоб його створити, нам було потрібне масштабоване рішення, яке підтримує необмежену кількість агентів, динамічно формує інтерфейс користувача та виглядає однаково на всіх підтримуваних десктопних і мобільних платформах. Приєднуйтеся, щоб дізнатися, як ми знайшли рішення для цього інноваційного продукту

У цій доповіді Владислав розповість про його шлях приборкання 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*.