writing & talking — talking
→ Next up
-
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. 
-
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. 
-
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. 
-
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. -
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. -
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 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.