Senior Backend Engineer · Tech Lead · 6+ років
Макс
Ястремський
Позиціювання
За мною ті частини системи, які не можна зробити приблизно правильно — гроші, замовлення, виробничі процеси, — і я будую інструменти, які доводять, що роботу справді зроблено.
Факти
- Стек
- PHP 8.4 · Laravel 12 · Node / NestJS
- Дані
- MySQL 8 · Redis · Docker
- Локація
- Україна, UTC+3
- Відкритий до
- Віддалено з будь-якої точки · релокація · готовий вийти за два тижні
- Ринки
- Ізраїль · Україна
- Мови
- Англійська B2 · українська рідна · російська вільно
Відкритий код · MIT · флагман
Groundwork
Плагін для Claude Code, який робить перевірку частиною процесу розробки, а не залишає її людині.
«Агент охоче напише правдоподібний код і так само охоче відзвітує, що все готово. Groundwork робить перевірку частиною процесу.»
- 7
- кодових баз у продакшні
- 340
- запусків процедур
- 160
- написаних специфікацій
- 27
- передач фронтенду
- 1 з 3
- зупинено до коду
Приблизно, станом на серпень 2026
Оберіть задачу. Подивіться, як змінюється процес.
Нуль JavaScript — radio-поля і CSS. З клавіатури: Tab у групу, далі стрілки. Працює з вимкненими скриптами.
L0 — Дрібниця
Без специфікації. Без плану. Без review-агентів. Без погодження. Автоматичні гейти і є повне визначення готовності.
Хто перевіряє
Ніхто — і це навмисно.
Що потрібно
- Гейти, які спрацьовують самі
L1 — Невелике виправлення
Регресійний тест, який спершу падає, потім одна жива перевірка саме того, що виправлено, — а не обхід усіх споживачів.
Хто перевіряє
Без агентів — натомість точкове самотрасування.
Що потрібно
- Коротка вбудована специфікація
- Регресійний тест, який падає першим
- Жива перевірка того єдиного, що виправлено
L2 — Функціональність
Дослідження розходиться вшир ще до планування. Радіус ураження картографують, а не припускають, і нічого не пишуть до узгодження плану.
Хто перевіряє
- impact-mapper — що це зламає
- conformance-reviewer — чи задовольняє diff критерії
Що потрібно
- Специфікація, план, погодження
- До 2 раундів запитань
- Тести, написані до коду
L3 — Високий ризик
Права доступу, міграції, публічні контракти, видимість фінансових даних. Тут під сумнів ставлять намір, а не лише код.
Хто перевіряє
- impact-mapper
- blind-spot-map — про що ніхто не здогадався спитати
- grounded-researcher — що насправді робить провайдер, з посиланням
- conformance-reviewer
- adversarial-verifier — чи правда, що «воно працює»
Що потрібно
- Специфікація, план, звірка вимог, нотатки до розгортання
- До 4 раундів запитань
- ADR, коли рішення наскрізне
L4 — Критично
Фінансові розрахунки, життєвий цикл замовлення, модель прав, руйнівні міграції. Бути приблизно правим тут означає бути неправим.
Хто перевіряє
- Усе, що вмикає L3
- Змагальна панель — щонайменше двоє незалежних скептиків на найризикованіших твердженнях
Що потрібно
- Усе, що вимагає L3
- Нотатки щодо відкату
- Погодження людиною, завжди
- форматування при редагуванні
- статичний аналіз
- набір тестів
- контракт OpenAPI
- скан дефектів
- заявлене покриття
- заявлена оцінка
- намір задачі
- контракт агента
- примусовий runner
- міграції заблоковано
- правки заблоковано під час дослідження
- незапушена робота
Вибрані роботи
Чотири рішення
Не переліки можливостей. Кожен запис фіксує обмеження, що обрано замість чого, і ту деталь, яку middle-інженер зробив би неправильно.
- 01
Groundwork
Класифікація задач за ризиком L0–L4, 5 спеціалізованих review-агентів, 13 автоматичних гейтів і 15 процедур робочого процесу, під ліцензією MIT.
Неочевидна частинаПриблизно кожну третю задачу зупиняють до того, як написано хоч рядок коду: неправильно окреслена, конфліктує з наявною поведінкою або дешевше вирішується без розробки. - 02
Голос у структуровані дані
Мовлення стає перевіреною задачею, а не здогадкою: транскрипція під домен, вилучення за схемою і людина перед кожною дією.
Неочевидна частинаТести не мають права звертатися до провайдера. Річ не в рахунку: набір тестів, який залежить від віддаленої моделі, — це набір, що падає з причин, не пов'язаних зі змінами, які перевіряють, і за два тижні команда вчиться його ігнорувати. У CI провайдер замокано, а оновлення моделі ловлять регресійні тести відповідей, які звіряють структурований вихід із фіксованими випадками. Тож тихо перевчену модель ловить набір тестів, а не користувач. - 03
Платежі, кліринг і податкові документи
Токенізація карток, кліринг з ключами ідемпотентності та бухгалтерський експорт — у домені, де бути приблизно правим означає бути неправим.
Неочевидна частинаПодатковий документ із нульовою сумою провайдер відхиляє одразу. Це звучить як крайній випадок — доки знижка, повернення чи повністю покрита позиція не створить такий документ посеред загалом коректної партії. А оскільки випуск працює за принципом «усе або нічого», падає вся партія, і рахунки не отримує ніхто. Такі позиції треба розпізнавати й закривати локально, щоб нуль узагалі не дійшов до провайдера. - 04
Мультиринкова e-commerce платформа
Одна кодова база, клонована під кожен ринок: валюта, локаль і часовий пояс з конфігурації, рушій цін, платежі й доставка за драйверами та синхронізація каталогу з ERP.
Неочевидна частинаСинхронізація каталогу з ERP складає кожну зміну товару як типізований DTO, щоб людина переглянула її до застосування. Записувати вхідні дані одразу в каталог було б значно менше роботи — і імпорт, який застосовує себе сам, це імпорт, який ніхто не може відкотити. Коли ERP надсилає неправильну ціну на десять тисяч товарів, різниця між «складено на перегляд» і «застосовано» — це різниця між відхиленою партією і зіпсованими вихідними.
Карта компетенцій
Що я роблю
Згруповано чесно. Без відсотків — стовпчик «навички на 80%» не каже читачеві нічого, що він міг би перевірити.
Бекенд і платформа
- PHP 8.4, Laravel 12
- Node, NestJS
- MySQL 8, PostgreSQL
- Redis
- Docker
- Мікросервіси
Гроші й коректність
- Токенізація карток за PCI
- Ключі ідемпотентності
- Десяткові гроші через bcmath
- Мультивалютність і ПДВ
- Бухгалтерський і податковий експорт
- Регулярні списання, прямий дебет
Прикладний AI у продакшні
- Вилучення, обмежене схемою
- Виклик інструментів без автовиконання
- Облік вартості кожного виклику
- Абстракція провайдерів і запасний шлях
- Захист від ін’єкцій у промпт
- Регресійні тести відповідей
Інтеграції та надійність
- Ланцюжки запасних драйверів
- Вебхуки статусу доставки
- Реєстр перевірок стану інтеграцій
- Ланцюжки задач у черзі
- OAuth2 між сервісами
Складний рендеринг і дані
- Іврит, письмо справа наліво і двонапрямні PDF
- OCR через морфологічне виділення сітки
- Класифікація кольору в CIE-Lab
- Пошук і ранжування з допуском одруківок
- Конвеєри на FFmpeg та Imagick
Як я веду команду
- Розробка від специфікації
- Картографування радіуса ураження до планування
- Змагальна перевірка
- Контракти OpenAPI, що не відстають
- RBAC на боці сервера
- Фронтенд, коли він стоїть на шляху: Vue, React, TypeScript
Як я працюю
Три правила
Це не наміри. Це те, що примусово перевіряють інструменти.
Заземлюй, а не вгадуй.
Те, що робить зовнішній сервіс, підтверджується його офіційною документацією з посиланням — або позначається як невідоме й доводиться в пісочниці. Правдоподібна відповідь про чужий API — найдорожчий різновид помилки.
Специфікація — дешеве місце помилитися.
Дослідження широке; зміна вузька. Кожна третя задача не доходить до коду, бо обговорення показало: вона неправильно окреслена, вже вирішена або дешевша без розробки.
Твердження — це не доказ.
Тести, статичний аналіз і перевірки контрактів працюють як гейти, а не як добрі наміри. «Воно працює» перевіряє рецензент, єдине завдання якого — спробувати це спростувати.
Контакти
Відкритий до роботи
Розглядаю позиції Senior Backend і Tech Lead — віддалено з будь-якої точки · релокація · готовий вийти за два тижні. Працював на ізраїльському та українському ринках, зокрема з івритом і продуктами з письмом справа наліво.