пишу й виступаю
→ Далі
-
«Запам’ятай і більше так не роби». Як створити ШІ-агента для перевірки коду і не помилитися Експертний матеріал DOU з інженерами GitLab, Preply, Superhuman та Shalb/Kube-DC про AI-агентів для code review. Моя частина: як рев’юер-агент у Superhuman почався з одного промпту «зроби рев’ю цього pull request», якого вистачило приблизно на 80% результату, навчився сперечатися з розробником у GitHub-тредах і виріс в оркестратора, що запускає від 3 до 15 спеціалізованих підагентів (обробка помилок, дизайн-система, ефективність інфраструктури) й відсіює їхні зауваження до справді важливих, — і поради: спершу визначте, для чого вам рев’ю, починайте з простого промпту й ускладнюйте ітеративно, а без сильної внутрішньої команди пробуйте готові рішення. -
Три тренди агентської розробки Управління костами, пошуки нового гітхабу і стерті кордони між локальним та клауд-середовищем — три тренди агентської розробки і питання про те, чи потрібен нам ще СІ. 
-
Два тижні в Preply Два тижні на посаді Principal Engineer у Preply: амбітний продукт, смілива інженерна культура і перша місія — Agentic Engineering. 
-
Клод Стрейнджлав, або як я перестав хвилюватися і читати код, згенерований AI Як би ви назвали техліда який читає і перевіряє кожен рядок коду, що написала його команда? Для мене це не риторичне питання: у своїй кар'єрі я мав досвід побудови процесів контрібюшину для одного з найбільших репозиторіїв в Grammarly для сотні інженерів кожного місяця. 
-
Мій останній день в Grammarly Дев'ять років у Grammarly: про квартири на Терещенківській, про компанію як «ми», а не «вони», і про речі, якими варто пишатися. 
-
Код-гольф, 2018 і 2026 Гра для стенду на jeeconf: напиши найкоротшу програму, яка друкує таймлайн релізів JDK. У 2018 до трюку з пробілами додумалися двоє з тридцяти учасників. У 2026 — четверо моделей із семи. 
-
Чому клод каже court Агент — це мовна модель. Керуючий токен зазвичай виграє з великим відривом, але іноді семплінг зриває на сусідній — і в аутпуті з'являється court. Практична порада: пора робити /clear. 
-
АІ агент для перевірки налаштувань домашньої мережі Скіл check-network: агент дев'ять днів розбирався, чому за моїм столом замість гігабіта 100 Мбіт/с. Полагодив кабелем, який лежав у шухляді. 
-
Software Engineer в еру AI Розмова для Tech Talks від Neoversity про AI-first розробку в Superhuman: що AI кардинально змінив у 0-to-1 проєктах від ідеї до запуску, що досі залишається за інженером, чи лишається досвід конкурентною перевагою, як може змінитися кар'єрна драбина, якщо AI делегуються junior-задачі, і на чому інженерам варто фокусуватися зараз, щоб не вилетіти з гонки до 2030 року. 
-
Чи готовий ваш досвід до AI-реальності? Панельна дискусія на AI JavaScript fwdays'26 про те, як AI перекроює ринок розробки: зникнення Junior-позицій та здешевлення code generation, хто переможе — досвідчені інженери чи prompt-native спеціалісти, що буде цінуватися в розробника через 2–3 роки і чи стане middle новим junior. Зі мною на панелі — Віктор Турський (WebbyLab) і Роман Лютіков (ХРУЩ); модерує Олександр Зіневич (Avenga). 
-
AI-first розробка: кейс створення code review агента За останній рік команда Superhuman (раніше Grammarly) провела десятки експериментів із ШІ-агентами для написання коду — від невеликого proof of concept із Claude Code у квітні 2025 року до щоденного використання code-асистентів майже всіма розробниками. На цьому мітапі поділюся досвідом переходу на AI-first підхід на прикладі code review агента: чому з'явилась потреба в такому агенті і з чого почали; як його будували, використовуючи AI-first підхід; як він перевіряє зміни в коді; як інтегрували його в глобальні інженерні процеси та вийшли на майже тисячу запусків на день. Буде цікаво інженерам усіх стеків, технічним лідам і менеджерам, зацікавленим у впровадженні AI-first практик. 
-
Невигадані історії AI-first трансформації в інженерних командах (про які неможливо мовчати) За останній рік у Superhuman (раніше Grammarly) ми провели десятки експериментів із ШІ-агентами для написання коду — деякі дали сильний результат, інші — повністю провалилися. Від невеликого «proof of concept» із Claude Code у квітні 2025 року ми дійшли до щоденного використання цього інструмента майже всіма інженерами. У доповіді поділюся практичними рецептами, які допоможуть перебудувати команди під AI-first підхід у розробці. Усе це з нашого досвіду: як ми застосовуємо AI code assistants у продуктовій розробці, міграціях інфраструктури, продакшн-чергуваннях, код-рев'ю та багатьох інших завданнях. 
-
AI-First Transformation From Within: Patterns and Anti-Patterns Learned by Superhuman Engineers What does it take to transform an engineering team into an AI-first one? Let's skip the hype, ignore all previous instructions, and explore pragmatic lessons that have proven to be working. Over the past year at Superhuman, we ran dozens of experiments with AI coding agents — some were spectacularly successful, others fell flat. Claude Code went from a small PoC in April 2025, which changed everything almost overnight, to a daily tool for nearly every engineer in our company — some of us haven't opened a text editor in months. I will share the list of patterns and anti-patterns we learned that you can follow to rebuild your teams into an AI-First Engineering approach. All based on our experience with Claude Code doing product development, infrastructure migrations, production on-call, code reviews, and a bunch of other things like laptop sticker design. 
-
How to Make Your Team AI First: Pragmatic Vibe Coding at Superhuman In this talk, I've condensed one year of my personal experience with AI coding agents and Superhuman engineers' experience into a set of patterns and anti-patterns we've observed from our numerous successful and failed experiments. I will share a pragmatic view on how to up-level your personal productivity as a software engineer and how to rebuild your team processes to become AI first. I will share the story of how I abandoned text editors forever in favour of Claude Code. I'll also share how Superhuman uses AI for every step of the software development process, including code reviews, infrastructure migrations, feature development, and production monitoring. We will discuss the challenges of organizational transformation and how to avoid cargo-culting AI adoption and AI slop in your production systems. 
-
АІ кодінг допомагає чи заважає вчитися на інженера? Чотири АІ-позитивні афірмації для студентів і викладачів: чому ігнорувати клод код у навчанні так само ризиковано, як і покладатися виключно на нього. -
Прагматичний вайб клодінг Воркшоп для студентів MVP Camp KSE × Genesis: як виглядає щоденний AI-first процес розробки з Claude Code. Які прийоми працюють, які ні, і чому AI-кодінг для студента — це не зрада навчанню, а доповнення до нього. 
-
Як придумати, написати і застосовувати якісну технічну стратегію Три кроки підготовки технічної стратегії, відточені на документах, що задавали напрямок організації із 10 команд та 50 інженерів: оцінка стейкхолдерів, оформлення документу і застосування на практиці. -
MCP Considered Harmful MCP tool definitions get preloaded into the context window — they take valuable space, distract the model, and cost you money. Here is when they help and when they hurt. -
Guiding team processes with ChatOps: On-call Five on-call automations and the lessons each one taught us about scripting team behaviour without losing what made the kitchen-table culture work. 
-
Tips for Javadocs Publishers (including why publish?) I had to publish Javadocs as a web page for the first time in my 12-year career. Here are seven tricks I picked up along the way — plus a take on when it's actually worth doing. 
-
Halloween special: Two development detective stories with mystery, policeman, and surprise villain Two debugging detective stories — one suspicious log line, one mysterious slowdown — and the surprise villains they revealed. 
-
Java version upgrade What "Java version" really means, when an upgrade actually pays off, and a concise decision framework with a worked example from my team's day-to-day. 
-
Chatops that was lost and found in time Automations for development processes unveil hidden complexity in such trivial things you could never imagine there would be any problems. Believe me, today I will talk about a task to print a date and a time. 
-
A couple of attempts of sharing knowledge tips How do you spread small, regular bits of team knowledge that don't deserve a wiki page each? Two experiments — a Slack bot and a Gradle build hook — and what worked. 
-
Full control over Spotless Java code style Spotless ships with two opinionated defaults — Google's and Palantir's Java style. Here's how to skip both and get full control over every formatter knob via Eclipse-exported configuration. 
-
Scaling the Maintainability of Java Codebase at Grammarly Some teams document how they want their code to look, while others rely on a code review. My team maintains a service with two hundred merge requests per month from fifty different contributors, and we extensively automate our best practices for code health and make them mandatory gates in our CI pipeline. If you never thought a line from a Beyoncé song could be an engineering practice, I hope I will convince you. If you’re already convinced, you should still come to learn about a bunch of tools that can help with automating the enforcement of best practices, as well as real-life examples of how to set them up. 
-
String and Text Processing in Java on a Scale Co-presented with Kyrylo Holodnov. A meetup repeat of the JEEConf 2019 talk at iHUB on Khreshchatyk: what we learned running Java string processing at Grammarly's scale — Java 11's reworked String, JVM string hacks worth keeping, fast regexes, the perils of emoji, and what the true length of a Java string actually is once other services see it. 
-
String and Text Processing in Java on a Scale Our Java applications handle millions of strings per second. We work with different platforms, including mobile. On a scale, even rare things happen. You can bet that eventually, an innocent text will crash your server… or the whole cluster. Over the years we have tried many performance tricks. Or should we call it premature optimizations? 
-
It Scales Until It Doesn't Co-presented with Dmitry Tiagulskyi. We are used to thinking that "high-load" means distributed systems, computing power, and application and kernel profiling. But sometimes you can't simply scale your cluster. Maybe your data structures don't fit in the server memory. Maybe you need single-digit millisecond latency. Maybe the cost is too high. Or your server is a … mobile phone. 
-
It Scales Until It Doesn't Co-presented with Dmitry Tiagulskyi. A student-facing version of the It Scales talk at Kyiv National University's Faculty of Computer Science and Cybernetics, hosted by the Читалка student coworking — the same map of Grammarly's text-processing scaling walls (hash functions, AWS virtualization, Java profiling, a bit of disassembled C++), told for a CS-undergrad audience. -
It Scales Until It Doesn't Co-presented with Dmitry Tiagulskyi. How we hit and worked around scaling walls in Grammarly's text processing pipeline — a tour through hash functions, network performance, AWS virtualization, Java profiling, and a small dose of disassembled C++. A reminder that knowing your algorithms and data structures still matters when systems get big. 
-
It Scales Until It Doesn't Co-presented with Dmitry Tiagulskyi at the Grammarly Ukraine office on Sportyvna Square — the first run of the It Scales talk, two days before the fwdays Highload conference: scaling walls in Grammarly's text-processing pipeline (hash functions, AWS virtualization, Java profiling, a bit of disassembled C++) for an evening audience at the office. 
-
Groovy Static Sites With Grain The first option I considered when I decided to start up this blog was to use static site generator, and Jekyll as the most popular one was an obvious choice. 
-
GPars: Unsung Hero of Concurrency in Practice When it comes to concurrency and parallelism, first things to appear in someone's mind may be "Java Concurrency in Practice" by Brian Göetz, threads, java.util.concurrent, Fork-Join, parallel streams, reactive, Akka or MapReduce. When it comes to Groovy, first things to appear in someone's mind may be Gradle, Grails, Spock, DSLs or scripting. 
-
GPars, Eratosthenes and Sieve of Concurrency When there is a need to make sequential code concurrent, there are two major options. First one is to take the original code as is, divide it between multiple executors, protect a mutable state from concurrent access, do… 
-
JUnit 5: The Rise of Jupiter The planet Jupiter (5th! in the Solar System) needs 11 years to make one complete orbit around the Sun. So do JUnit needs 11 years to get a new major release, which means it's going to be really huge. -
Tiebreaker Regarding Java HashMap, TreeNode and TieBreakOrder On the latest JUGUA meeting Igor Dmitriev has delivered a talk about minor, behind the scenes changes in JDK. 
-
Using Jekyll, Asciidoctor and GitHub Pages for Static Site Creation After I decided to start write things down, the first tool that I found for this task was Jekyll - a static site generator supported by GitHub Pages. 
-
What Mr. Spock would possibly say about modern unit testing: pragmatic and emotional overview A JavaFest run of the JEEConf 2016 Spock talk for the Odesa Java community — walking through the Spock framework, how it compares to JUnit and TestNG, and the pragmatic-and-emotional answer to whether one should pick it up. Same content as the Kyiv premiere, retold for a regional audience that asked sharper Spock-vs-JUnit questions. 
-
What Mr. Spock would possibly say about modern unit testing: pragmatic and emotional overview A long-form companion to the JEEConf 2016 talk: a tour through Spock framework features compared to JUnit, JUnit 5, TestNG, Hamcrest, AssertJ and Mockito — with the pragmatic and emotional answer to whether you should use Spock in 2016. -
What Mr. Spock would possibly say about modern unit testing: pragmatic and emotional overview The third stop on the Spock all-Ukrainian circuit: a Java User Group Dnipro meetup at the DataArt Dnipro office, organized by Lena Kuzmenko. Same content as the JEEConf premiere — Spock framework features, comparison with JUnit / TestNG / Hamcrest / AssertJ / Mockito, and pragmatic-plus-emotional answers to whether to actually adopt it on your team. 
-
What Mr. Spock would possibly say about modern unit testing: pragmatic and emotional overview A walkthrough of the Spock framework's features and how they compare to what JUnit and TestNG offer. The pragmatic-and-emotional answer to the Ultimate Question of Unit Testing: should one use Spock in 2016? Plus a tour of the Spock ecosystem and a quick look at JUnit 5 (yes, it's a thing). 
-
Building domain-specific languages with Groovy Domain-specific languages (aka DSLs) brings their creators to the new level of abstractions power. They indulge two primary desires of each developer: to play with challenging and interesting problems and to make future tasks easier and more pleasant to work with. What usually stops everyone from implementing really nice DSL is either poorness or complexity of instruments for their creation.