writing & talking
→ Next up
-
▸ Fwdays Tech Summit'26, online
Claude Strangelove, or: How I Learned to Stop Worrying and Reading AI-Generated Code
-
Claude Strangelove, or: How I Learned to Stop Worrying and Reading AI-Generated Code How would you call a tech lead who reads and checks every single line of code their team writes? For me it is not a rhetorical question: in my career I built the contribution process for one of the largest repositories at Grammarly, for a hundred contributors monthly. -
My last day at Grammarly Nine years at Grammarly: apartments on Tereshchenkivska Street, a company that is “us” rather than “them”, and a lot of things worth being proud of. 
-
Code golf, 2018 and 2026 A game for our jeeconf booth: write the shortest program that prints the JDK release timeline. In 2018 two of thirty participants found the whitespace trick. In 2026 — four models out of seven. 
-
Why Claude says court An agent is a language model. The control token normally wins by a wide margin, but sometimes sampling slips to its neighbour — and court shows up in the output. Practical advice: time to run /clear. 
-
An AI agent that checks your home network setup The check-network skill: an agent spent nine days working out why my desk got 100 Mbps out of a gigabit plan. The fix was a cable I already owned. 
-
Software Engineer in the AI Era A Tech Talks conversation with Neoversity about AI-first software engineering at Superhuman: what changed in 0-to-1 product development, what still stays with the engineer, whether experience remains a competitive advantage, how junior careers may evolve when AI takes over junior-sized tasks, and what engineers should focus on now to stay in the race toward 2030. 
-
Is your experience ready for the AI reality? A panel discussion at AI JavaScript fwdays'26 on how AI is reshaping the development market: the disappearance of junior positions and the falling cost of code generation; who comes out ahead — experienced engineers or prompt-native specialists; what will make a developer valuable in 2–3 years; and whether middle is the new junior. On the panel with me: Viktor Turskyi (WebbyLab) and Roman Liutikov (Khrushch); moderated by Oleksandr Zinevych (Avenga). 
-
AI-first development: building a code review agent Over the past year the Superhuman (formerly Grammarly) team ran dozens of experiments with AI agents for writing code — from a small proof of concept with Claude Code in April 2025 to daily use of code assistants by almost every developer. At this meetup I'll share our experience of moving to an AI-first approach through the example of a code review agent: why the need for such an agent arose and where we started; how we built it using an AI-first approach; how it reviews code changes; and how we integrated it into our global engineering processes and scaled to nearly a thousand runs a day. It'll be useful for engineers of every stack, tech leads, and managers interested in adopting AI-first practices. 
-
True stories of AI-first transformation in engineering teams (the ones you can't keep quiet about) Over the past year at Superhuman (formerly Grammarly) we ran dozens of experiments with AI agents for writing code — some delivered strong results, others failed completely. From a small proof of concept with Claude Code in April 2025, we got to nearly every engineer using the tool every day. In this talk I'll share practical recipes that help re-tool teams around an AI-first approach to development. All of it from our own experience: how we apply AI code assistants in product development, infrastructure migrations, production on-call, code review, and many other tasks. 
-
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. 
-
Does AI coding help or hinder learning to be an engineer? Four AI-positive affirmations for students and teachers: why ignoring Claude Code in your studies is as risky as relying on it alone. -
Pragmatic vibe clauding A workshop for MVP Camp KSE × Genesis students: what a daily AI-first development process with Claude Code actually looks like. Which techniques work, which don't, and why AI coding isn't a betrayal of learning for a student but a complement to it. 
-
How to devise, write, and apply a solid technical strategy Three steps for preparing a technical strategy, honed on documents that set the direction for an organization of 10 teams and 50 engineers: assessing stakeholders, writing the document, and applying it in practice. -
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.