«Не устал ли ты сидеть на своей Java 10 лет?» Тимлид из Варшавы — о работе, где язык больше не важен, а код за тебя всё чаще пишет ИИ
Раньше ИТ-рынок часто нанимал бэкендеров по одному критерию — стек. Пишешь на Java — идёшь на Java-вакансию. Сегодня многие компании это правило игнорируют.
Алексей — пять лет в Cycode, израильском сайберсек стартапе, которого Gartner называет лидером индустрии. Алексей ведёт одну из варшавских команд и как раз из тех, кто нанимает не глядя на основной язык разработки. Мы поговорили с ним о том, что стоит за этим подходом, в чём сегодня вообще суть работы бэкендера, когда код всё чаще пишет нейросеть, и кого берут в кибербез такого уровня.
В конце бонус: открытые вакансии, Cycode прямо сейчас нанимает бэкендеров.
Коротко о Cycode
Израильский стартап в кибербезопасности. Большие компании гоняют код через десятки security-инструментов и тонут в их разрозненных предупреждениях. Cycode сводит всё это в одну картину, добавляет собственные сканеры и по всему пути кода, от коммита до продакшена, отбирает из шума действительно опасное и помогает исправить. Последний год компания перестраивается под мир, где заметную часть кода пишет агент.
Познакомиться с командой вживую можно на ближайшем TechSpot в Варшаве — 23 сентября.
Инженеров нанимает On The Spot Development: компания строит локальные R&D-команды для международных технологических компаний.
«Меняются только знаки препинания»
— У нас команда language-agnostic. То есть мне не важно, на чём ты писал раньше. У нас бэкенд на .NET, но человек, который не знает этот фреймворк, зато понимает общие принципы бэкенд-разработки, придёт и будет писать на .NET. Там нет каких-то очень сложных вещей, которые требуют глубокого знания именно языка. Всё плюс-минус одинаковое, меняются только «знаки препинания».
Тем более сейчас. Имея ИИ, тебе, в принципе, не надо уметь писать код. Надо понимать и думать. Кодовый ассистент умеет писать на любом языке.
Недавно было ровно наоборот. Четыре года назад в СНГ почти никто, кроме процента-двух, не готов был пойти на .NET-вакансию, если основной стек всю жизнь был Java. Это такая правда, к сожалению. А в Израиле, откуда Cycode, к этому относятся спокойно: в армии все учили Python, потом каждый пишет на том, на чём надо. Язык — дело десятое.
«Мы не пишем код сами — мы генерим его»
Чтобы объяснить, чем мы занимаемся, начну издалека. Cycode следит за безопасностью кода на всём его пути: от разработчика до продакшена. Начиналось всё с простого — искали секреты, которые кто-то запушил в GitHub. Потом стали искать всё подряд: уязвимости, мисконфигурации, утечки, дыры в облаке.
А за последний год пришла большая эра ИИ, и это добавило кучу новых мест, где можно налажать. Стало больше кода. Сильно больше. Практически весь код теперь где-то генерит нейросеть. И люди меньше стали отвечать за то, что пушат, потому что меньше пропускают это через голову.
Я не скажу, что сам код стал небезопасным из-за того, что его пишет ИИ. Ты всегда можешь попросить: «Проверь, что этот код безопасный» — и всё будет нормально. Ну, проблема в другом — появилось ещё одно место, где человек может ошибиться. Раньше секрет попадал в код так: разработчик что-то дебажил, закинул в файл, закоммитил. Теперь ты можешь слить секрет ещё быстрее — просто вставить его в промпт, даже не запушив никуда. Ты его туда сольёшь — а он там уже живёт.
Поэтому мы в Cycode и говорим, что мир, где код писали люди, закончился. И я это вижу по своей работе.
«Ты должен управлять агентом, а не быть его фолловером»
Управлять агентом должен ты. Это не должен быть AI-driven development, где ИИ говорит: «Я нашёл решение, оно вот такое», — а ты в силу своих знаний продукта, кодовой базы понимаешь, что решение-то неправильное. Не надо идти за ним как фолловер. Можешь продолжить с ним диалог, разобраться, что он прав. А можешь тупо сказать «да, окей» — и если он был неправ, то в какой-то момент это всплывёт.
Теперь ИИ ещё и сам чинит. Простой пример: у тебя уязвимая зависимость в проекте. Мы нашли, где она сконфигурена, знаем версию, знаем, в какой версии уже есть фикс. Дальше наша задача — просто открыть тебе pull request, который делает исправление. Это не так сложно. А есть и другая сторона — не только чинить постфактум, но и блокировать наперёд сами действия, которые плодят уязвимости. И действия тут уже не только человеческие: ИИ тоже теперь actor.
«Клиент не будет счастлив, если попросить у него 30 реплик»
Разберём на конкретной задаче, которая сейчас у меня открыта в соседнем терминале. Если по-человечески: у клиента тормозит наш сервис, и починить это можно дорого и в лоб, а можно — головой. Мы выбираем головой.
Сервис называется Broker — маленькая штука, которую клиент ставит у себя, чтобы мы могли забирать нужные данные из его закрытой инфраструктуры. Написан он не идеально и под нагрузкой начинает захлёбываться. Самое простое — попросить клиента добавить железа. Только не придёшь же к нему с просьбой «дай мне 30 реплик этого сервиса, и мы будем классно работать» — некрасиво.
Значит, ищем настоящую причину. Сели с Claude, взяли метрики. Сначала грешили на одну строчку в коде — что где-то стоит лишний Time.Sleep. Оказалось, не в ней дело. Проблема прозаичнее: Broker забирал новые задачи только после того, как разгребёт все предыдущие, — работал строго по очереди. Чинится параллелизмом: пусть берёт задачи одновременно. Весь разбор, человек плюс агент, занял примерно час.
«Плюс-минус 150 сервисов — и свой SAST-движок на Rust»
Про крафт. Бэкенд у нас на .NET, фронтенд на React и TypeScript. Микросервисная архитектура: плюс-минус 150 сервисов, всё в Kubernetes, на AWS. Kafka как service bus. Из баз — Mongo, Postgres, Redis, ClickHouse. И Rust — на нём мы делаем наш SAST-движок.
SAST-движок Cycode анализирует код на уязвимости ещё до запуска, не выполняя его, а строя упрощённое представление и симулируя, как через этот код текут опасные данные. Это называется taint-flow анализ: движок находит точки, откуда приходят ненадёжные данные (например, пользовательский ввод), и проверяет, доходят ли они до рискованного места использования: SQL-запроса, лога, eval. Раньше, кстати, SAST-сканер просто искал подозрительные паттерны построчно в коде и не знал, срабатывает ли этот код вообще. Сейчас строим стек-деревья, из которых виден реальный путь вызова, это даёт существенно меньше ложных срабатываний алертов.
Про это можно послушать вживую
23 сентября Cycode и On The Spot проводят в Варшаве TechSpot-митап про кибербезопасность в эпоху ИИ.
С докладами выступят:
• Software Engineer из команды Cycode. Расскажет про SAST-движок, который они делают для скана кода на уязвимости: как устроен сканер, как он отслеживает путь опасных данных через код (taint-flow анализ), и почему ИИ не заменяет SAST-сканирование, но удачно его дополняет. А ещё — почему в принципе нельзя выполнить статическое сканирование идеально.
• Senior AppSec-специалист и по совместительству преподаватель Military University of Technology. Разберёт идентичность ИИ-агентов, корректные способы их аутентификации и авторизации.
Кроме того, на ивенте будет AppSec Case Clinic: панелисты вживую разберут сложные кейсы, которые участники ивента принесут с собой.
Регистрация
По людям устроено так: любую большую вещь, в принципе, разработчик ведёт сам, от дизайна до релиза, один или двое. Архитектуру обсуждаем в узком кругу; если заворачиваем, то с конкретным объяснением, а не «мы так не хотим».
Я в Варшаве веду команду интеграций. У Cycode их около 45 — со всеми соседями по рынку: Snyk, SonarQube, Black Duck, Coverity, Orca. Клиент редко покупает один инструмент безопасности, обычно несколько — и хочет видеть все находки в одном месте, сравнивать: кто находит больше, у кого меньше ложных срабатываний.
Помимо обнаружения уязвимостей, другая часть работы — их исправлять, плюс интеграции с трекерами задач и системами алертов. В продукте восемь доменных команд, и все тимы распределённые: в Израиле, в Польше, в Великобритании.
«"Если бы сделали на Rust, было бы супербыстро" — вечный вброс»
В команде всегда есть любители сказать: «Вот если бы мы это переписали на Rust, было бы супербыстро». Но это просто вброс, чтобы поразгонять. Если у тебя внешняя тула отвечает минуту, то без разницы, на чём написан клиент — на .NET, на Rust, — у тебя всё равно эта минута, пока тула отвечает. Продукт собран из кучи интеграций, и упираемся мы обычно не в микросекунды.
Свежий холивар про ИИ: коммитить через него или нет. Пока агент за тебя коммитит, он съедает кучу токенов, а ты бы то же самое сделал сам и быстрее. Поэтому кто-то принципиально коммитит руками. А кто-то наоборот: сидит, разговаривает с тобой, а Claude в это время коммитит.
«Думать головой, а не думать Claude»
Несмотря на то, что Claude — это главный инструмент в Cycode, у нас приживается человек, который умеет и хочет думать. Если ты общаешься с Claude, то это ты ему объясняешь, что тебе надо, а не он тебе. Потому что, если клод неправ и ты идёшь за ним — вы оба потом неправы, но ответственность несёшь ты. Мы хотим на 100 процентов, чтобы человек думал головой, а не думал Claude.
В команду берём тех, кто ищет решение, а не новые проблемы. Проблема всегда найдётся, это несложно. Сложно быть проактивным, решать проблемы и приносить результат.
Мы всегда тестируем сами. Сделал фичу — ты за неё отвечаешь: сам думаешь, как покрыть её логами, какие алерты поставить, чтобы быть уверенным, что всё хорошо.
И ещё важно не бояться выходить за рамки своего домена. Очень частая история: упёрся в то, что не работает у соседней команды, и остановился ровно на этой черте — мол, чужое. Да не чужое, ты в этом же продукте работаешь. Тебе ничего не стоит написать две строчки, которые это чинят, или пойти к ответственному разработчику, получить от него добро и принести фикс. Никто не держит тебя в границах твоей команды. Надо выйти наружу — иди.
«Первые три месяца лид катает тебя по продукту»
Как выглядит старт. Первую неделю, кроме всякой бюрократии с лэптопом, даём небольшие понятные задачи: баги, где ясно, как чинить, или «добавь по примеру». Смысл в том, чтобы человек потрогал код, а не утонул сразу.
Потом месяца три основная задача уже моя, как лида, — покатать человека по продукту, по всей зоне ответственности команды. Чтобы он всё пощупал и в голове сложился кругозор: где он вообще работает. Желательно, чтобы за эти три месяца у него уже были и своя фича, и таска, и починённый баг. Обычно выходит больше.
«Если ты любишь прожигать время — это не то место»
Обратная сторона: кому у нас не место. Если ты любишь прожигать время, это не к нам. Есть же куча мест, где ты будешь три года обсуждать, куда передвинуть кнопку, заэстимируешь это на пять лет, а потом положишь код на полку, потому что релизить боишься. У нас не так.
А что ты получишь за два-три года, чего не получишь в спокойном месте, в каком-нибудь большом аутсорсе? Главное — production-опыт. В аутсорсе ты написал, проект зарелизили, и в лучшем случае остался на суппорте, а всех перекинули на следующий. А тут продукт с живыми клиентами, реальным мониторингом, инцидентами. Учишься где-то на своих, где-то на чужих ошибках. Это как вулкан: ты знаешь, что он будет извергаться, но не знаешь, с какой стороны польётся лава.
И коммуникация — это тоже большой опыт для синьорити. Если взять любую матрицу «мидл — синьор», большая часть пунктов там как раз про общение и коммуникацию.
У нас, кстати, процессы очень прямые. Фаундер может прийти и сказать: «У вас тут не работает» — вместо того чтобы гонять это через три круга бюрократии. Петля получается сильно короче. Иногда даже слишком: был период, когда фаундер заходил и мержил все pull request'ы на фронтенде, что висели больше дня. Новый человек приходит — а у него PR уже замержен, и не факт, что кто-то его проверил. Такое мы, наоборот, стараемся гасить.
«Не устал ли ты 10 лет делать одно и то же?»
Когда сильный бэкендер или DevOps сомневается, идти ли к нам, я обычно отвечаю так.
Хотя, честно, сильные бэкендеры обычно не сомневаются. Они и так понимают, где профит.
Сейчас мы нанимаем пять бэкенд-разработчиков в команду в Варшаве:
Если вы сами не ищете работу, рекомендуйте друзей. В случае успеха бонус — 1,000$ 😉
