Ну что вы скажете? С 12 минут до 3 секунд(!) сократил время поиска инструкций полнотекстовый поиск в KMS Gran.
Один из наших клиентов - IT-компания - хранила документацию в Google Docs и Telegram, что вызывало путаницу. В 2024 году внедрили базу знаний KMS Gran, создав разделы "Проекты", "API-документация" и "Ошибки и уроки".
Результат спустя год:
время поиска инструкций сократилось до 3 секунд
скрипты автоматизировали уведомления о новых версиях API, уменьшив время согласования релизов на 30%.
за 6 месяцев количество багов в коде снизилось на 25%, так как разработчики быстро находили решения по прошлым ошибкам.
Статистика показала, что раздел "Ошибки и уроки" просматривали 80% команды, что привело к добавлению видео-разборов типичных ошибок.
А какие процессы хотелось бы улучшить в вашей команде?
Компания PVS-Studio и платформа Securitm заключили технологическое партнёрство для обеспечения интеграции статического анализатора кода PVS-Studio в экосистему DevSecOps.
Облачный сервис и программное обеспечение SGRC Securitm позволяют построить управление информационной безопасностью на базе риск-ориентированного подхода и единой информационной модели компании.
Отчёт анализатора PVS-Studio стало возможным загрузить в Securitm для дальнейшего использования с помощью пользовательского интерфейса системы.
Подробнее о том, как загрузить отчёт анализатора PVS-Studio в систему Securitm можно прочитать в посвящённом этому разделе нашей документации.
Также мы с коллегами из Securitm провели совместный вебинар, на котором обсудили, как обеспечить соблюдение требований ГОСТ в области РБПО, а также показали реальные примеры использования PVS-Studio и Securitm.
Почему ваша архитектура ломается? Спросите у того, кто чинил десятки таких систем!
04.09.2025 в 15:00 (Мск) приглашаемна первую открытую AMA-сессию «Спроси меня о чем угодно» с Дмитрием Овчаренко — техническим директоромдепартамента«Разработка для финансового сектора» IBS и экспертом Учебного центра IBS по архитектуре ПО.
Что вас ждёт (и почему это не обычный вебинар):
✔️ Без воды — только честные ответы на ваши вопросы (даже на те, о которых стыдно спросить).
✔️ Разбор реальных косяков — как ломались системы и что с этим делали.
✔️ Карьерный лифт — что нужно, чтобы перейти из разработчика в архитекторы?
А еще конкурс:
Пришлите самый нестандартный, забавный или абсурдный вопрос в комментариях к этому посту. Автор лучшего получит приз!
Кому полезно?
➕ Разработчикам, которые хотят расти до архитекторов.
➕ Аналитикам, уставшим от абстрактных советов.
➕ Всем, кому интересно, как устроена «кухня» fintech.
Компания PVS-Studio и Inseq заключили технологическое партнёрство для обеспечения интеграции статического анализатора кода PVS-Studio в экосистему DevSecOps.
Программное обеспечение Inseq RBPO предназначено для создания и управления конфигурациями, необходимыми для автоматического развёртывания и настройки компонентов инфраструктуры безопасной разработки ПО — систем контроля версий, анализаторов кода, инструментов автоматизации сборки, тестирования и развёртывания. Управление конфигурациями и политиками безопасности осуществляется централизованно.
"ИНСЕК.РБПО" представляет собой клиент-серверную систему, работающую на локальном оборудовании. Она включает серверную часть, генерирующую конфигурационные файлы, и веб-приложение с графическим интерфейсом для взаимодействия с пользователями.
Внутри этой платформы стало возможным использовать статический анализатор PVS-Studio для поиска критических ошибок в исходном коде.
Также мы провели вебинар с коллегами из Inseq, в котором поговорили о необходимости регулярного статического анализа, а также в целом об автоматизации в РБПО.
Красные флаги в код-ревью: перегибы, которых лучше избегать
Фокус на мелочах. Если уделять много внимания опечаткам и код-стайлу, то времени уйдет много, а реальных результатов будет мало. Главное — это всё-таки архитектура, алгоритмы и производительность, а косметика только на втором плане. Зачем портить настроение себе и команде, если можно ничего никому не портить?
Поверхностный анализ. Забивать на проверку кода — тоже плохая идея. И дело даже не в багах, их отловит тестировщик. Дело в безопасности всей системы. Если какой-нибудь хакер найдет уязвимость, которую QA не нашел, — жди беды. Ну и техдолг никто не отменял: если не делать сразу хорошо, однажды придется переделывать.
Токсичность. Во время код-ревью лучше всё-таки искать потенциальные проблемы с кодом, а не учить коллег работать. То есть фокус внимания — не на поиске недостатков в чужой работе, а на самом коде. А личные предпочтения и вкусы относительно кода лучше обсуждать отдельно.
Обратную связь стоит давать вдумчиво — подбирать слова и контролировать интонацию. Фидбек должен быть таким, чтобы у разработчика не возникало ощущения, будто он ни на что не годится.
А каким должен быть хорошее код-ревью — в нашем блоге.
Эффект «стены Дурова», который я открыл за 10 лет до самого Дурова
По студенчеству я, как и любой джун, совершал ошибки. Одна из них — классический пример истины «работает — не трожь».
2004 год. Я на 3-м курсе факультета прикладной математики и информатики АГУ (г. Майкоп), параллельно работаю программистом в математической школе при университете. Моя вотчина — программа для подсчёта рейтингов учеников, набор текстов для методичек и небольшой сайт с гостевой книгой.
Кто не застал — гостевая книга тогда была чем-то вроде бесконечного чата без регистрации. У детей мат. школы в ней кипела жизнь: по 100–200 сообщений в день (иногда даже больше), свои шутки, обсуждения задачек, разговоры «за жизнь». Формат был простой и лёгкий — написал ник, сообщение, и готово.
А я молодой, амбициозный и несу людям счастье)))
Я тогда подумал. Почему они мучаются с этим бесконечным тредом сообщений? Это же жутко неудобно! А что если я уберу эту гостевую книгу и заменю ее на удобный форум для своих? Хорошая же идея? Ну, если судить логически, то да. Свой форум, регистрация, понятно, кто пишет, можно делать свои темы и не тонуть в бесконечной беседе. На тот момент мне казалось, что это отличная идея сделать жизнь определенного круга людей лучше.
Нашел на просторах хороший движок и в один прекрасный день заменил гостевую книгу на этот форум. Создал темы и стал ждать, как мне люди скажут спасибо.
Догадываетесь, что было дальше? )))
Правильно. Провал… Ученики не стали использовать новый форум!
Была попытка одного человека что-то написать, но когда никто не ответил, то и он перестал что-то писать + пара регистраций пользователей. Моя попытка это исправить ни к чему не привела. Я даже старые сообщения пользователей из гостевой книги загрузил в новый форум. Все бестолку. Сайт, у которого был отличный трафик, буквально за неделю перестали посещать.
Для меня это было потрясение. Как так вообще? Я же хотел сделать как лучше для пользователей! Почему они не стали использовать новый форум?
Рефлексия и мои мысли на эту тему прилагаются:
Новый форум не взлетел, т. к. старый был ламповый, легкий. Можно добавить одну запись под ником «Препод такой-то», а следующую «Иванов Иван». Было интересно переписываться в таком легком формате. Был вайб от использования такого формата. Может, помните в VK знаменитое: «Дуров, верни стену!»? Этот косяк Павла из той же оперы.
Если какой-то сервис работает хорошо, но, на твой взгляд, там все организовано очень нелогично, не надо это исправлять сию минуту! Надо сделать опрос, проверить гипотезы, попробовать узнать мнение пользователей. Бывает, конечно, и такое, что пользователи не могут тебе сказать, что нужно добавить, и при добавлении этого «чего-то» оно действительно взлетает, но делать это нужно аккуратно, просчитывая варианты.
Этот студенческий урок 20-летней давности я вспоминаю до сих пор каждый раз, когда моя команда предлагает «быстро улучшить» какой-нибудь работающий модуль. Часто при взгляде на проблему задаю себе вопрос: «Какую настоящую работу выполняет для пользователя этот старый, неудобный, но привычный функционал? И не убьем ли мы ту самую "ламповость", просто заменив ее на "правильное" решение?»
Вот такая история.
P. S. Если кто-то читает мой пост из тех, кто тогда сидел в этой гостевой книге, прошу у вас прощения. Я не хотел, чтобы так все вышло.
---
Понравилась эта история? Это пример того, как я анализирую ошибки и извлекаю из них практические уроки. В моем ТГ канале Код ИТ-директора я гораздо чаще делюсь подобными мыслями, короткими кейсами и полезными инструментами, которые не всегда доходят до формата большой статьи.
Приглашаем вас на регулярную встречу фронтенд-сообщества в неформальной обстановке 28 августа. В этот раз — MoscowJS в гостях у Альфа-Банка.
В программе:
От JavaScript к DeFi: как инженеры могут изменить мир финансов. Спикер: Даниил Швецов, Full Stack Engineer. Доклад познакомит JavaScript-инженеров с основами DeFi: ключевыми концепциями, математическими моделями и работой с JS SDK.
Архитектура микрофронтендов: от А до Single Spa. Спикер: Павел Шлыков, Team Lead Frontend. Поговорим о микрофронтендах с нуля: от принципов и базовой реализации до инструментов вроде Module Federation и single-spa. Разберёмся, как всё устроено, и рассмотрим нестандартные подходы.
Под капотом платформы. Спикер: Антон Марченко, Ведущий разработчик. Доклад об опыте сборки платформы из готовых решений и объединения приложений через iframe, Module Federation и webview. Узнаете про выбор подходов и работу с командами.
Гильдия: место, где разработчик перестаёт быть одиноким кузнецом. Спикер: Владислав Сазонов, Head of Frontend. Чувствуете себя одиноким фронтендером? Есть решение — гильдия. В докладе — о том, как этот формат помогает расти, делиться опытом и не выгорать, а также краткий исторический экскурс.
Присоединяйтесь онлайн и офлайн — зарегистрироваться можно по ссылке.
Где: г. Москва, Андропова пр-т., 18, к. 3 (офис Альфа-Банка)
OpenAI выпустила GPT-5. Разница между GPT-4 и GPT-5 примерно как между студентом и доктором наук, заявлил Сэм Альтман.
GPT-5 является самой мощной существующей моделью для кодинга. Она может выстраивать более сложные цепочки действий и писать более сложный код в одном стиле. Простым промптом можно создать функционирующее веб-приложение — на презентации сгенерировали Duolingo платформу для изучения французского языка с полноценными дизайном, анимациями, озвучками и игрой. Новая модель значительно меньше склонна к галлюцинациям — она будет меньше врать и притворяться. Также она стала гораздо менее «подхалимской». Тексты, генерируемые GPT-5, стали более естественными и человечными. Вместе с этим модель лучше понимает и исправляет свои ошибки. ChatGPT интегрируют в Gmail и Google Календарь на следующей неделе. Можно будет управлять как электронной почтой, так и своим расписанием прямо в чате. GPT-5 сама определяет, как лучше ответить — быстро или «подумав».
GPT-5 умеет не только вести разговор, но и выполнять реальные задачи: создавать приложения, планировать календарь, проводить исследования. Она сама определяет, как лучше ответить — быстро или «подумав». Модель справляется с генерацией кода, выдаёт меньше галлюцинаций, и даже даёт более точные ответы на медицинские вопросы.
По тестам GPT-5:
Обходит Claude Opus 4.1 и Gemini 2.5 Pro в программировании
Слегка уступает Grok 4 Heavy в тесте «Humanity’s Last Exam»
Отвечает на медицинские вопросы с ошибками всего в 1.6% случаев (у GPT-4o — 12.9%)
Ведёт себя безопаснее: меньше обманывает, точнее различает вредные и безопасные запросы.
Платные подписчики Plus и Pro получили доступ к более мощной версии GPT-5 Pro. В API теперь доступны три размера: gpt-5, mini и nano.
GPT-5 можно попробовать в Cursor — тут, и в Copilot — тут.
Компания PVS-Studio и платформа Hexway заключили технологическое партнёрство для обеспечения интеграции статического анализатора кода PVS-Studio в экосистему DevSecOps.
Hexway VamPy — это решение, агрегирующее данные о безопасности из разных источников для работы с уязвимостями.
В Hexway стало возможным загрузить результаты анализа PVS-Studio в виде отчёта и работать с конкретными ошибками так же, как это позволяют другие инструменты. Загрузка возможна двумя способами: через пользовательский интерфейс или командную строку с использованием CLI-инструментов.
Подробнее о том, как загрузить результаты анализа PVS-Studio в Hexway VamPy можно прочитать в соответствующем разделе нашей документации.
Говорим на языке событий: что даёт ивент-шторминг и как его правильно провести
Привет! Я Иван Чернов, системный архитектор, в этом посте расскажу про ивент-шторминг.
В Островке есть набор сервисов, который разбит на логические блоки так, чтобы в рамках блока можно было итерировать: Островок, Островок B2B и Островок Командировки. При этом запускать новые фичи, которые будут сквозь эти слои прорезаться.
Мы растём по количеству и продуктов, и людей, нанятых для их разработки. Недавно начали толкаться локтями: не понимали, как качественно контрибьютить в большие кодовые базы, как они должны эволюционировать. Поэтому пришли к ивент-штормингу.
Что это за практика? На встрече с одной стороны сажаем бизнес, с другой — разработку. Просим бизнес рассказать, что и как он делает в работе с клиентом.
Ивент-шторминг проводится с фокусом на цикличную реактивность: происходит событие, которое визуально меняет что-то для пользователя, тот принимает решение и отдаёт команду, команда приводит к новому событию.
На этих циклах фокусируемся на доске в Miro во время встречи.
В ивент-шторминге 3 этапа:
1. Сейлзы выстраивают по циклам цепочку событий: от «клиента у нас ещё нет» до «клиент нас окончательно покинул». Даже в простых цепочках 20–30 действий. В готовом таймлайне есть happy pass: клиент успешно прошёл весь путь. И альтернативные пути: что-то пошло не так.
2. Проходим по таймлайну с конца, ищем ошибки. Выделяем ключевые события, которые нельзя откатить: клиент зарегистрировался, совершил бронирование, провёл оплату. Здесь происходит стык сервисов. На стыках обогащаем цепочку. Пишем, кто и что делает: актор-клиент зарегистрировался, подключился сервис юзер-менеджмента.
3. Выявляем, какие агрегаты работают с событием. Мапим команды: клиент регистрируется, в работе участвует команда регистрации.
Цепочка готова, мы получили полезный контекст, все одинаково понимают процессы и видят, что нужно делать, чтобы их улучшить.
Во время встречи составляем словарик. Если сейлз говорит непонятное разработчикам слово — мы его добавляем в словарь, и оно просасывается в наш интерфейс и кодовую базу. Всё это учит разработчиков понимать, на какие рычажки они влияют своим кодом.
Поделюсь советами, как круто провести ивент-шторминг.
Онлайн-формат
● Для проведения онлайн достаточно доски в Miro.
● Разбивайте встречу на три части, каждая встреча — один этап.
● На последней встрече отпустите бизнес, выявите агрегаты и сервисы, задействованные в таймлайне с разработкой.
● Максимум людей для успешной фасилитации онлайн — 8–10 человек.
● Ищите представителей бизнеса в оргчате выбранного домена: спрашивайте у руководства, «кто тут самый инициативный».
● Вам нужны работники «с полей», которые лучше всего шарят в процессах, и тимлиды первого уровня.
● Берите людей из разных направлений домена.
● Бизнес-участники должны понимать: ивент-шторминг — процесс обучения, они эксперты, а разработка — ученики. Им нужно говорить на своём языке, а не подстраиваться под разработку.
● Дайте участникам базовый словарь. Четыре самых важных слова: актор, команда, событие, термин.
● Важны вводные по времени и цели: на сессию уйдёт суммарно 6–8 часов, она даст единое понимание процессов.
Фасилитация
● На старте не бойтесь повторить все вводные.
● Дайте сейлзсам 10 минут на то, чтобы каждый выстроил индивидуальный таймлайн, дальше начинайте мёржить таймлайны с общим обсуждением.
● Событие — факт в прошедшем времени, его не отмотать. Следите, чтобы так и записывали.
● Первым делом простройте happy pass, иначе у вас не выстроится цельное видение процесса. Альтернативные ветки обозначьте на первом этапе, а достраивайте на втором, проверяя таймлайн с конца.
● Если бизнес утверждает, что два события происходят одновременно, это важная точка обсуждения.
● Организуйте пост-процессинг: важно передать разработке результаты, объяснить, какие процессы у нас уже верно реализованы, а где нужно обновление и дополнительное внедрение.
Почему ваш новый «гениальный» флоу вызывает тревогу в команде? Всё о психологии сопротивления изменениям — в одной статье!
Представьте ситуацию: вы, как продакт, несколько недель потратили на исследования, кастдевы, прототипирование и дизайн. Вы выносили идею, защитили её перед стейкхолдерами и теперь, сияя от предвкушения, приносите команде разработки новый, идеально продуманный флоу. А в ответ — тишина. Или, что хуже, шквал вопросов в стиле «а зачем?», «у нас и так всё работает» и «это всё сломает».
Знакомо? Прежде чем записывать команду в ретрограды и саботажники, давайте разберёмся. То, с чем вы столкнулись — не вредность, а фундаментальный баг (или фича?) человеческой психики. Имя ему — сопротивление изменениям.
В статье «Почему ваш новый «гениальный» флоу вызывает у команды панику? Разбираем психологию сопротивления изменениям» мы копнём в нейробиологию и психологию, чтобы понять, почему наш мозг так ненавидит всё новое, и что с этим делать продакту, тимлиду или любому другому менеджеру. Узнаем почему понятный костыль всегда приятнее неизвестного счастья, что на самом деле пугает разработчиков и тимлидов, когда вы внедряете инновации, как обойти страхи, не потерять доверие и не получить force push в master обратно и какие психологические лайфхаки реально работают в жизни, а не в учебниках. Автор разбирает реальные кейсы, шутит, находит баги в «операционке» команды и даёт понятные инструкции, как внедрять любые изменения.
Представлен обучающий курс по Python под названием Advanced Python Mastery от Дэвида Бизли, автора нескольких книг-бестселлеров по этому языку программирования и одного из главных знатоков Python. В базе курса представлены данные по работе на уровне процессора и компилятора до продвинутых концепций программирования на Python и самых актуальных фреймворков, а также десятки материалов с PyCon.
Для ЛЛ: перечислены способы мотивации сотрудников, которые вам могут показаться банальными
Недавно на работе разгорелся жаркий спор. Двое наших разработчиков сцепились из-за выбора библиотеки для работы с датами в монорепе на js. Один был фанатом Luxon, утверждая, что она идеально подходит для сложных задач с датами и временем. Второй клялся, что Date-fns – в это лучший выбор, потому что она лёгкая, быстрая и позволяет использовать только нужные функции, не раздувая проект.
Ну не суть. Я сидел рядом и наблюдал за этим словесным баттлом. Проект уже грозил загнуться, не начавшись.
Понимая, что бесконечные дебаты ни к чему не приведут, я решил вмешаться. Первое, что необходимо сделать в таких ситуациях – выслушать всех причастных. Я дал каждому возможность высказаться, кивая и делая вид, что записываю их аргументы в блокнот. В голове я уже прикидывал, как не дать спору остановить работу.
Разрешение конфликта
Чтобы выйти из тупика, я предложил компромисс: «Ребята, давайте так. Каждый из вас реализует свою часть проекта с использованием своей библиотеки. На проверку идей у вас 2 дня, потом сравним, что получилось». Они согласились, и весь накал спора тут же утих – оба погрузились в работу, стремясь доказать, что их выбор лучший.
В итоге мы остановились на одной из либ, но не это важно. Главное, что разрешился конфликт между двумя сотрудниками на почве выбора технологий. А часто бывает и по-другому, что никто не хочет уступать и каждый топит за свой алгоритм/либу в проекте.
В таких случаях я обычно:
Развожу спорщиков по разным проектам
Или принимаю сам решение какую технологию использовать далее
В обоих случаях после конфликта может упасть мотивация, могут затаиться обиды и т.д.
Мотивация-шмотивация
Несмотря на подзаголовок, я приведу реально применённые способы поднятия мотивации разработчиков:
Деньги-деньги, решают многое. Сюда же незапланированные премии.
Повышение должности сотрудника (иногда даже без повышения зарплаты, не везде корректно настроены грейды). Был «разработчик», стал «Ведущий разработчик», потом «Старший разработчик» и т.д.
Обновляешь ноутбук работнику. Иногда для сотрудника это долгожданное обновление, и это очень повышает его мотивацию и лояльность к компании (ну или к тому, кто её выбил).
Про лишние дни отдыха тоже понятно.
Оплата билетов на конференции по IT-тематике (а они не всем по карману сейчас), покупка лицензий на удобный софт.
Признание заслуг в разработке проекта перед вышестоящим начальством и текущей командой. Хотя это должно быть по умолчанию в команде.
Этих пунктов может быть ещё очень много, везде индивидуально.
Конфликты между коллегами в команде – это не трагедия, а возможность для экспериментов и роста. Выслушать каждого, дать шанс доказать свою точку зрения на практике и подкрепить это мотивацией – именно так конфликт становится точкой роста.
Если есть чем поделиться, как вас мотивировали - прошу в комментарии.
Краткий (и не краткий) экскурс в ГОСТ Р 56939-2024 – РБПО
Недавно мои коллеги обработали и опубликовал пятую — финальную — часть моего рассказа про ГОСТ Р 56939-2024 – Разработка безопасного программного обеспечения. Поскольку все части записывались сразу, к моменту выхода этого заключительного видео я понимаю, что сейчас бы немного иначе его сделал. Видение меняется, появляется новая информация. Например, завершился этап домашнего задания испытаний анализаторов кода, и про это стоило бы упомянуть. Или, например, появилась эта методическая рекомендация, про которую стоило бы рассказать.
Но не страшно, про новое расскажем в рамках других митапов и вебинаров. А пока, вот все части общего обзора:
Но на этом история не закончилась. Сейчас вместе с УЦ "МАСКОМ" и приглашёнными гостями-экспертами мы записываем подробный цикл вебинаров про каждый из 25 процессов, описанных в стандарте.
чем отличаются SLI, SLO и SLA и как их правильно применять?
когда компании осознают необходимость этих метрик и как их встраивать в процессы?
как оценить критичность сервисов и доказать бизнесу ценность SLO/SLA?
В теме помогут разобраться Паша Лакосников, руководитель юнита ArchGovernance в Авито, Дима Синявский, SRE-инженер в Ви.Tech, и Кирилл Юрков, Observability and Reliability Engineering Manager в ecom.tech.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Компания PVS-Studio и платформа AppSec.Hub заключили технологическое партнёрство для обеспечения интеграции статического анализатора кода PVS-Studio в экосистему DevSecOps.
AppSec.Hub — это платформа для автоматизации процессов Application Security, которая позволяет объединять различные инструменты анализа, тестирования и мониторинга безопасности приложений.
Отчёт анализатора PVS-Studio теперь можно загрузить для просмотра в платформу AppSecHub вручную с помощью пользовательского интерфейса инструмента либо с помощью специальной утилиты командной строки.
Подробнее о работе PVS-Studio в AppSec.Hub можно прочитать в посвящённом этому разделе документации.
Также мы провели вебинар с коллегами из AppSec Solutions, чтобы на практике показать, как инструменты работают вместе, а также поделиться полезным опытом в интеграции статического анализа в DevSecOps.
Как мы в Страховом Доме ВСК внедряем ИИ: спецпроект System Analysis & AI Talks AI-запросы, Kafka, автоматизация и даже вайб-кодинг — всё это не сюжет киберпанк-романа, а реальный спецпроект IT VSK — System Analysis & AI Talks, который мы недавно провели в Страховом Доме ВСК.
Этот проект родился из простой, но важной идеи: системный анализ — это не скучно, особенно когда в дело вступает нейросеть. И когда в одной комнате собираются системные аналитики, разработчики и эксперты по ИИ, разговор получается горячим. А мы не просто поговорили, мы показали, как всё это работает на практике в рамках корпоративных ИТ-систем.
System Analysis & AI Talks: немного про магию В рамках AI Talks мы разобрали реальное применение LLM в деятельности системного аналитика — не на уровне «что может ИИ», а с погружением:
Что такое LLM в контексте продуктовой разработки;
Как выполнять базовые операции и избегать ошибок в промт-дизайне;
Как тюнинговать промты под конкретные бизнес-задачи;
Как встраивать нейросети в ежедневную практику.
Особый интерес вызвал наш блок «Открытый микрофон», где участники делились собственным опытом: от подсказок к составлению бизнес-требований до генерации тест-кейсов в один клик.
TechDay: ИИ-киборги, вайб-кодинг и Kafka на грани Вторая часть ИИ-марафона прошла под флагом нашего флагманского проекта TechDay по искусственному интеллекту. Делимся тремя самыми горячими темами:
AI-киборги: минус разработчик или плюс вайб?
Где грань между помощником и угрозой? На этой сессии мы:
Подключали ИИ к IDE прямо на глазах у публики
Показывали, как правильно и этично использовать помощников, не превращая их в «копипасту из ада»
Про наш эксперимент с N8N + ИИ: рассказали коллегам про новые возможности в Страховом Доме ВСК.
Вайб-кодинг: как писать сервисы, не трогая клавиатуру?
Здесь мы раскрыли необычную тему: разработка типового сервиса без ручного программирования. Сравнили: кодить по классике, с low-code, с помощью ИИ — где удобнее, где быстрее, а где надёжнее. В финале показали, как собрать прототип за полчаса, даже если вы не fullstack-разработчик.
Kafka без боли: как не утопить прод Завершили встречу рассказом о самых критичных ошибках при работе с Kafka, которые мы реально встречали в проектах:
Как не перегрузить сеть и диск, когда вы рассылаете сотни тысяч сообщений;
Почему архитектура решает (и как её не сломать с первого коммита);
И где границы между гибкостью и хаосом в распределённых системах;
Что за этим всем стоит?
Спецпроект System Analysis & AI Talks стал частью нашей инициативы по созданию открытого инженерного сообщества внутри Страхового Дома ВСК.
Мы убеждены: ИИ — это не волшебная палочка и не замена человеку, а инструмент, который нужно понимать, настраивать и адаптировать. А ещё — это повод поговорить не только про технологии, но и про культуру внутри команды: делиться опытом, сомневаться, спорить, искать нестандартные решения. Именно это мы и сделали.
P.S. Если вы в своей компании делаете что-то похожее — поделитесь, нам правда интересно! Следите за публикациями в блоге — будет много нового: и про Kafka, и про промты, и про реальные грабли с ИИ в проде.
Про сотрудника Игоря, или про того, кто ни в чем никогда не виноват
Работал у меня в компании лет 5 сотрудник, назовем его Игорь. И странное дело, он всегда был ни в чем не виноват. Что бы ни происходило, но он не виноват по определению.
Это был человек, который всегда делал работу только так, что у него не было никаких вариантов для самостоятельного принятия решений. Если ему что-то непонятно (даже по мелочи), он всегда подходил и спрашивал, как быть. Если есть несколько вариантов решения задачи, он озвучит все варианты и оставить выбор за мной.
С одной стороны, это хорошо, как сотрудник он всегда делегировал сложную часть работы и ответственность на руководителя, а с другой стороны, выглядел как маленький ребёнок, которому дали задачу и даже в самых простых вещах человек бежит к тебе и спрашивает, что и как ему делать.
Причём если ошибка была в коде, который он написал. Игорь каким-то волшебным образом умудрялся всегда находить слова типа: «А вот помнишь, ты мне говорил вот это сделать, я так и сделал, и вот в результате появилась ошибка». Иногда доходило до смешного: на форме при разработке были какие-то орфографические ошибки, и он начинал юлить. )) Мне в какой-то момент даже стало интересно, а в принципе он может сказать: «Я сделал здесь ошибку». И знаете что? За 5 лет работы с ним я так и не добился такого признания.
Что еще было: был сон на рабочем месте в рабочее время, несколько жестких будунищ после выходных, и в таких случаях я всегда его отправлял домой, потому что толку от такого сотрудника нет никакого (это другая история). Но нет. Он никогда не виноват. )))
Минутка рефлексии и мои рассуждения по поводу таких сотрудников:
Сотрудник, не берущий на себя ответственность, обходится компании дороже, чем кажется. Его реальная стоимость — это не только его зарплата, но и десятки часов моего времени как руководителя, потраченные на микроменеджмент и исправление последствий и принятие решений там, где это должен был сделать он. Я, как руководитель, хочу платить деньги профессионалу, а не маленькому ребенку.
На собеседовании нужно всегда задавать вопрос об ошибках. Простой вопрос «Расскажите о своей самой серьезной ошибке и что вы сделали, чтобы ее исправить?» мгновенно выявляет «Игорей». Они либо не могут вспомнить ни одной ошибки, либо рассказывают историю, где виноваты были обстоятельства или коллеги. Так не бывает в реальной жизни. Мы все ошибаемся и это нужно уметь признавать.
Нужно вовремя принимать решение об увольнении. Моя ошибка была в том, что я держал Игоря 5 лет в надежде, что он изменится. Люди меняются крайне редко. Моя задача как руководителя — не быть психотерапевтом, а собирать эффективную команду. Я затянул с этим решением, и это стоило компании и денег, и нервов.
Такие дела…
А у вас в практике был такой коллега — Игорь, который никогда не берет на себя ответственность и пытается ее спихнуть на другого человека?
Больше полезной информации про ИТ-управление, спорные вопросы в найме, менеджменте и планировании — в блоге Код ИТ-директора в Telegram, VK, Дзен, Instagram*, FB*. Подпишитесь, чтобы не пропустить новые тексты!
*Признаны экстремистскими организациями и запрещены на территории РФ.
— Слушай, я посмотрел у Тинькоффа — у них такие крутые анимации. Давайте и нам такие сделаем!
— Ну, у нас не финтех, мобильного приложения нет, и вообще — у нас CRM для логистов…
— Ну и что? Люди любят, когда красиво! Сделаем плавные графики, чтобы всё оживало. UX, UI, ты же понимаешь!
— У нас при этом не работают фильтры, отчёты формируются вручную, и у клиента падает система при импорте Excel. Может, сначала это починим?
— Ладно… Только кнопки тогда сделай с закруглениями, как в Тинькоффе. Хоть что-то красивое будет.
Выглядит лучше. Работает — так же плохо.
Потому что копировать обёртку, когда продукт внутри разваливается — это мёртворождение дизайна.
Вдохновение — не преступление.
Но копирование без понимания контекста — худший выбор.
У Тинькоффа и команда дизайнеров, и исследования юзабилити, и огромный бюджет, и полгода на rollout.
Сначала надо решить боль клиента, а не украсить страдание. Сделай стабильный функционал, и только потом — красивый. Иначе копирование по цене тех долга выйдет.
Представлен открытый репозиторий с коллекцией гайдов по почти всем стекам технологий — от операционных систем и языков программирования до паттернов проектирования и принципов дизайна. Все гайды сжаты и структурированы, включая популярные языки программирования — Python, Java, Go, JS, Rust, всё об инструментах, редакторах кода и IDE, а также шпаргалки по горячим клавишам, библиотеки и фреймворки для работы.
Простой и бесплатной CRM не существует? Похоже, теперь такая уже есть!
Мы запустили в открытое тестирование первую версию CRM внутри YouGile. Она доступна всем без исключения пользователям бесплатно. Смотрите подробнее о ее возможностях:
А для команд до 10 человек вся система управления проектами YouGile бесплатна навсегда без каких-либо ограничений.
Привет, Хабр! 👋 Хочу поделиться небольшой, но полезной фичей, которая упростила мне жизнь при оформлении коммитов.
В своей работе я придерживаюсь структурированного подхода к именованию веток и сообщений коммитов. Подробнее об этом можно почитать здесь: 📎 https://habr.com/ru/articles/820547/
Я использую предложенные в статье правила, немного адаптировав их под себя. Например, добавляю номер задачи в текст коммита — это сильно упрощает анализ изменений при подготовке релиза.
Почему это удобно?
Указание номера задачи позволяет быстро понять, какие именно тикеты попадают в релиз. Особенно это помогает при ревью и при деплое.
Пример структуры ветки:
feat/dev-123_filter или fix/dev-432_filter
Сообщения коммитов я пишу в следующем формате:
dev-123 | настроил сортировку в фильтре
Чтобы не вставлять руками номер задачи каждый раз, я написал небольшой shell-скрипт, который делает это автоматически.
Скрипт prepare-commit-msg
#!/bin/sh
COMMIT_MSG_FILE=".git/COMMIT_EDITMSG"
BRANCH_NAME=$(git rev-parse --abbrev-ref HEAD)
if echo "$BRANCH_NAME" | grep -qE 'dev-[0-9]+'; then
TASK_ID=$(echo "$BRANCH_NAME" | grep -oE 'dev-[0-9]+')
if ! grep -q "$TASK_ID" "$COMMIT_MSG_FILE"; then
sed -i.bak "1s/^/$TASK_ID | /" "$COMMIT_MSG_FILE"
rm -f "$COMMIT_MSG_FILE.bak"
fi
fi
Скрипт нужно сохранить как .git/hooks/prepare-commit-msg и сделать исполняемым:
chmod +x .git/hooks/prepare-commit-msg
Как это работает?
COMMIT_MSG_FILE — путь до файла, в который Git записывает текст коммита.
BRANCH_NAME — название текущей ветки.
Сначала проверяется, есть ли в названии ветки номер задачи (dev-123).
Если он найден и ещё не указан в коммите — скрипт добавляет его в начало первой строки сообщения.
Таким образом, ваш коммит автоматически будет выглядеть так:
dev-123 | добавил пагинацию в список товаров
Вроде мелочь, а приятно — экономит время и упрощает навигацию по истории коммитов.
Если будет интересно — это и другие полезные скрипты, на моём GitHub
Откровения евангелистов БЯМ (LLM) для целей софтостроения генерируются публикуются с высокой скоростью. Не только на хабре, LinkedIn заполнен ими "под завязку". Прочитывать всё невозможно, да и не нужно, но некоторый тренд в изложении присутствует.
К сожалению, авторы много пишут о процессе, забывая собственно цели. Упоминание о функциональной сложности программы, как правило, отсутствует. Длина описаний процесса может создать ложное впечатление о развесистой функциональности, хотя большинство примеров находятся на уровне "записная книжка". В этом нет ничего плохого, просто не забываем, что 30 лет назад RAD типа Delphi умели создавать такие же "книжки" без написания кода вообще: достаточно было "накидать" компонентов на форму, настроить, связать их, и нажать "Run".
Накидали, и что дальше?
За словами "писать на близком к естественному языку", скрывается постепенное создание быстро растущего "промпта" - детальной спецификации, местами - псевдокода. Как следствие, необходимо иметь версии таких "исходников", как и раньше для кода (об этом практически не пишут). Для сторонних пакетов, API служб и прочих зависимостей не забываем указывать версии. По сравнению с таким "псевдокодом" техзадание может показаться увлекательной беллетристикой. Речь идет по сути о конечных спецификациях, ведь программирование - не столько кодирование (от силы 20% времени), сколько детальное проектирование и стабилизация.
Размер спецификаций псевдокода вкупе с описаниями контекста среды могут превзойти собственно размеры генерируемого кода, написанного программистом на формальном ЯВУ. Спецификации придется так же хранить в Git, и нервно просматривать, что же изменилось в сценариях, почему, ***, вместо слова "опять" кто-то написал "снова".
Для детерминированности процесса желательно, чтобы моделька была в том же состоянии, что и на предыдущем этапе генерации, но для внешних БЯМ-сервисов это недостижимо. Напомню, что компиляторы и классические генераторы кода (CASE, MDD) - детерминированные.
На первый план выходят тесты, их нужно писать "больше и лучше", потому что под капотом теперь только "черный ящик", "белого" больше нет. Тесты нужно постоянно обновлять в зависимости от объема изменений. Если ваши новые спецификации меняют 20% существующей кодовой базы, то тестов придется менять вдвое больше, принимая 2:1 за стандартное соотношение тестов к коду. Для языков без статической типизации тестирование еще более усложняется.
В реальных проектах написание сотен строк в день - это режим стартапа, причем на "нулевом цикле". Достаточно быстро программист приходит к естественной норме десятков строк в день, остальное время занимает понимание текущего потока проблем, поиск ошибок, интеграция и стабилизация. Хороший программист минимизирует объем порождаемого кода. Нужно ли включать БЯМ для написания 50 строк в день - вопрос.
В процессе не предусмотрена роль юниоров. Перспектива - "уйти со сцены", не воспитав смены, достаточно сомнительная для бизнеса и весьма печальная в личном плане.
Напоследок накину немного философского. Евангелисты любят упоминать, что человеческий мозг и БЯМы работают на одних и тех же принципах. Часто выясняется, что курса "Аналоговые ЭВМ" на их потоке уже не было, что несколько удручает. Еще более простой вопрос на примере несуществующей (пока?) телепортации: "Человек на входе телепортера и на выходе - это одна и та же личность?"
Небольшой технический чек, который стоит пройти каждому, кто ведёт продукт или отвечает за разработку. Если узнаете себя — возможно, пора не спешить с новой фичей, а разложить фундамент.
Весь проект держится на одном человеке И он — не документация. Ушёл в отпуск — проект замер.
Задачи ставятся в личке, на встрече или в голове "Я же в телеге писал задачу". Без трекинга всё разваливается.
Никто не может объяснить, что по приоритету Всё срочно, всё горит, всё одновременно. Ну вы поняли.
Прод выкатывается вручную, или в пятницу вечером Даже не баг, а фича. Проблемы по подписке.
Тестов нет, баги ловим по фидбеку Багрепорт от клиента — это не QA.
Архитектура — это слово из чужого лексикона Потому что “нам и так норм”. До первой перегрузки.
Вопросы “а как это работает?” решаются методом тыка Потому что комментировать код — западло.
Бэкапы где-то есть… но никто не проверял Олег говорил, что сохранял себе дамп локально
Ушёл один человек — и половина знаний ушла с ним Значит, их не было в проекте — только в его голове.
Если вы загнули 3–4 пальца — значит пора встать и осмотреться. Пока “всё работает” — это ещё не стабильность, это просто везение.
Некоторые проблемы уже рассмотрел подробнее в своих статьях
Как легко потерять смысл разработки, добавляя “полезности”
Сделаем ещё кнопку, она “точно нужна”
Добавим фильтр, и сортировку, и модалку, ну мало ли
Вот бы выгрузку в Excel, и график, и пуши!
…Проект набирает скорость. Только куда?
В чём проблема? Когда цель — просто сделать больше фичей, а не решить конкретную задачу, продукт начинает разваливаться: интерфейс пухнет, команда тонет в «хотелках», релизы идут в спешке, а люди - даже не замечают большинство этих «удобств»
Парадокс: чем больше фич, тем хуже продукт
Потому что он уже не про ценность, а про “галочки” и “давайте сделаем ещё”.
У фичи должен быть KPI, надо ставить вопрос «а что изменится от нее?». Также их надо подчищать, если старые не используются: «больше ≠ лучше»
Хороший пример: есть множество платных плагинов для Notion, в которых тонна функций. Но пользователям часто нужна была именно интеграция с Гугл таблицами, они не хотели переплачивать за другие возможности плагина.
Один парень заметил это, и сделал элементарный плагин для интеграции Notion с Google Sheets, на чем начал зарабатывать хорошие деньги. Людям не нужно «все и сразу», им нужна качественная точечная фича
Я пишу о таких штуках в Telegram-канале Техдир на пальцах — без кода и заумных слов. Только реальные кейсы, честные мысли и решения, которые работают.
Почему зависимость от одного специалиста может утопить всю команду. Выглядит как супергерой. На деле — одиночка, от которого зависит всё.
Это «человек-комбайн». Его любят, на него надеются, он незаменим. До тех пор, пока всё не рухнет.
Первый этап
Команда обращается за всем именно к нему: помощь, проверка, советы. Он — живая документация и мозг проекта.
Для бизнеса всё выглядит отлично: «три в одном, да ещё и без лишних затрат».
Второй этап
Постепенно «комбайн» устаёт: таски неинтересные, общения слишком много, помощи просят постоянно.
Он начинает раздражаться, отказывать, “зависимые” замыкаются. Процессы начинают проседать — но пока это незаметно сверху.
Третий этап
Бизнес не замечает проблему, а специалист уже морально ушёл. Проходит немного времени, и вот он увольняется. И…
Судный день
Без него — никто не знает, как деплоить, где что лежит, как починить баг.
Документации нет, у разработчиков паника.
Прод падает. Клиенты жалуются. Команда — в ступоре.
Восстановление занимает недели. А иногда — проект просто не поднимается.
Как не угодить в ловушку?
Раздавайте ответственность. Не сливайте всё на одного “самого умного”. Растите дублирующих специалистов. Пишите документацию. Один супермен — это риск, а не преимущество.
Коромысло с одним ведром — всегда перевесит в одну сторону.
Я пишу о таких штуках в Telegram-канале Техдир на пальцах — без кода и заумных слов. Только реальные кейсы, честные мысли и решения, которые работают.
Карма vs Инженерная честность: Почему рейтинги убивают экспертизу
Есть в инженерной культуре наивная вера: если система имеет метрики и правила - она безусловно и по умолчанию объективна. Карма на Хабре тому идеальный контрпример. Формально всё честно: пост → оценка → рейтинг. На практике же это цифровой аналог пассивно-агрессивного "не зашло". Без объяснений. Без контекста.
Карма против инженерной честности
Социальная инженерия вместо экспертной оценки
Главный парадокс: чтобы выжить, ты должен угадывать не истину, а ожидания аудитории. Тон, формат, табу. Это краш-тест на конформизм:
Написал, что 80% мониторинга в проде — это фейковый SLO? → Минус ("негатив"). Сказал, что ChatGPT пишет ТЗ лучше джуна? → Минус ("ересь"). Осмелился быть лаконичным без смайликов? → Минус ("агрессия").
Почему так? Потому что карма измеряет не глубину мысли, а комфорт восприятия. Инженерная точность = высокомерие. Прямолинейность = токсичность. Даже если за этим — годы практики и статистика.
Карма как инструмент подавления инакомыслия
Самое циничное на мой взгляд, найдутся и оппоненты, несомненно, это - непрозрачность. Минус прилетает анонимно, без мандата на критику. И неважно, что твой вклад в тему - как у топ-комментатора. Система молчит, а ты получаешь ярлык "ненадёжного".
Итог: Действительно качественные и экспертные умы, готовые спорить и рушить догмы, — уходят. Остаются те, кто мастерски жонглирует банальностями в дружелюбной обёртке. Звучит довольно резко, соглашусь. Но иначе не донести усть мысли. Платформа медленно превращается в клуб взаимного одобрения.
Что делать?
Игнорировать карму как погрешность системы (но тогда зачем она?).
Требовать мандат для минусов ("Укажи причину: факт ошибка/оффтоп/токсичность"). Хотя у кого тут истребуешь - не нравится, двери на кнопке "выйти".
Ввести верифицированную карму - например, чисто теоретически, только от пользователей с 100+ постами в профильных хабах.
Пока же мы имеем соцсеть, где алгоритмическая справедливость проигрывает человеческой... нетерпимости.
P.S. Этот текст - эксперимент. Проверим, сколько стоит сказать: "Император голый". За инженерную честность - не жалко. P.P.S. Карма — временна. Культура дискуссии — вечна.
Как QA и DEV могут эффективно работать вместе, а не играть в бесконечный пинг-понг с передачей фичи на тестирование и багов туда-обратно?
Об этом Лена Федорова, QA Garage Eight, рассказала на своей лекции «Мир, дружба, тестирование» на QA митапе в офисе Garage Eight. Она поделилась кейсом своей команды по внедрению совместного тестирования и тем, какие результаты оно дало.
Смотри лекцию и узнаешь: > что такое «совместное тестирование»? > какие у него преимущества и недостатки; > каким командам подойдет этот подход; > как измерить успех.
Как развернуть среду разработки и сервис управления проектами в облаке?
Группа IT-компаний Lad сократила время запуска клиентских проектов, автоматизировала сборку клиентских приложений для iOS и развернула производительную инфраструктуру для публичных сервисов. И все это — на инфраструктуре Selectel.
В основе инфраструктуры — облачные серверы с быстрым запуском, автомасштабированием и возможностью использовать подход GitOps.
Чтобы автоматизировать сборку клиентских приложений для iOS, компания арендовала в Selectel серверы Mac mini®.
За производительность инфраструктуры для публичных сервисов отвечает связка из Managed Kubernetes, Container Registry и S3. Она позволяет поддерживать микросервисную архитектуру с отказоустойчивыми кластерами, автоскейлингом и надежным хранением файлов.
Как группа IT-компаний Lad развернула окружения для разработки и тестирования, а также запустила сервис для управления проектами и ИИ-ассистента для бизнеса, читайте в Академии Selectel.
1-2 августа в Перми мы проведем уже традиционную конференцию про разработку и управление в IT-компаниях — Ural Digital Weekend 2025. Сейчас уже готова программа всех секций.
Микро-дайджест недели. Интересные мысли и инсайты.
Дайджест по материалам зарубежных медиа. Минимум булшита, максимум инсайтов.
=> До появления ИИ вас отличали знания. Знать больше, означало зарабатывать больше. Накопление навыков, развитие экспертных знаний и освоение фреймворков вывели вас вперед.
А когда знания перестают быть дефицитными, что остается ценным? Мудрость. Вы можете получить ответы от ИИ, но то, как вы используете эти ответы, требует мудрости.
Мудрость это то как жить. Это остаток ошибок, усвоенный временем и размышлениями. Его нельзя торопить, и его нельзя копипастить. Это воплощение опыта, руководство изнутри.
Независимо от того, насколько умным становится ИИ, он не может прожить вашу жизнь за вас. Вот почему экономика будущего будет ценить мудрых работников. Давайте углубимся в их три основных навыка: эмоциональная ясность, проницательность и связь.
=> Выход отчета The OpenAI Files отражает высокий уровень беспокойства среди лидеров мнений, в том числе со стороны бывших сотрудников OpenAI, и напрямую связан с убежденностью в том, что OpenAI действительно стремительно приближается к созданию AGI.
Сэм Альтман в своих недавних выступлениях говорит о том, что на пути к AGI мир уже прошел требуемый горизонт событий, и предсказывает, что в ближайшие несколько лет мир изменится сильнее, чем за последние столетия.
Илья Суцкевер, Ян Лейке и Стивен Адлер, бьют тревогу не из-за медленного прогресса, а из-за «опасной гонки» и «безрассудного» стремления к AGI, без наличия надежных методов контроля и согласования с человеческими ценностями.
Периодически появляются заявления инсайдеров, что фактически AGI «уже достигнут» внутри OpenAI на экспериментальных моделях.
=> Интервью с Сэмом Альтманом на AI Startup School в Сан-Франциско как и всегда приоткрывает некоторые важные нюансы стратегии компании. Несколько ключевых инсайтов ниже, но я всегда рекомендую смотреть такие выступления в оригинале, чем читать их саммари, в которых часто упускаются детали, имеющие именно для вас большое значение.
Альтман в очередной раз недвусмысленно намекнул на то, что новое устройство, которое они разрабатывают, сделает очередную революцию в интерфейсах (о чем я подробно писал в начале мае).
Поскольку цель OpenAI сделать из ChatGPT универсального ассистента и в чем-то ИИ-агента для каждого человека на земле, то по мере того как он будет узнавать каждого из нас лучше, он сможет и помогать нам все лучше.
Они готовят к релизу опенсорную и очень компактную модель, которая, по его словам, превзойдет все наши ожидания. Насколько я помню, вскоре за этим продуктом и должна появиться GPT-5.
И в очередной раз прозвучала очень важная мысль про Айвенторов:
...и я думаю, одна из вещей, которая будет ощущаться наиболее выдающейся в ближайшие 10 лет, по сравнению с тем же прошлым десятилетием, это то, как много может сделать один человек или небольшая группа людей с той свободой действий, которая у них будет (ну т.е. большим количеством ИИ-агентов)
Также Альтман употребил термин just in time software в новом контексте, о смысле которого я писал дней 10 назад, что если каждый сможет прямо на лету создавать под свою задачу требуемые алгоритмы. По сути, высокий уровень персонализации в функционале софта, да еще и создаваемого на лету, будет сильно конкурировать с текущей моделью SaaS продуктов, о чем и упомянул Альтман.
=> Создание надежных мультиагентных систем в 2025 году все еще нерешаемая задача, особенно если параллелить процессы,пишет исследователь и разработчик ИИ-агента Devin, Вальден Ян. Но по факту все зависит от решаемой задачи, и как вы строите когнитивные пайплайны. Он просто не читал мою книгу 😉
Предыдущие материалы и выпуски июньских дайджестов, в которых нет банальных ИИ-новостей, там до сих пор много интересных инсайтов для вас.
Это заключительный эпизод курса «Паттерны и практики написания кода». В нём бэкенд-инженер Юра Афанасьев расскажет про истоки возникновения паттернов, а также объяснит, как урбанизм и проектирование городов помогли в создании книги «Паттерны проектирования». Напоследок Юра также разберёт два фундаментальных правила, описанных в книге «Design Patterns».
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Вы знаете этих людей. Вроде умные, вроде опытные. Говорят правильные слова про 'стратегию', 'масштабируемость', 'долгосрочную перспективу'. Но почему-то через полгода таких разговоров оказывается, что:
баг, который 'уже почти пофиксили' никуда из прода не девался фича, которую 'вот-вот запустим' — всё ещё в черновиках команда уже тихо ненавидит слово 'архитектура'
А техлид? Техлид как будто ничего не замечает. Как это работает (точнее, не работает) Слова вместо кода
вместо пулл-реквестов - диаграммы. демо нет - зато вот вам слайды. вместо решений 'опять' 'давайте обсудим' (читай: 'я не хочу отвечать').
Бесконечный 'анализ'
'Надо подумать над архитектурой' = 'Я не уверен, но боюсь признаться' 'Это нетривиальная задача' = 'Мне лень разбираться'
Ответственность - это не про нас Любимый приём - щедро размазать вину:
'Это комплексная проблема' (на самом деле: 'виноваты все, а значит — никто').
Реальный кейс (чтобы было не абстрактно)
В одном проекте (Node.js, если важно) техлид 2 месяца 'прорабатывал подход' к рефакторингу. Провёл 8 митингов, написал 50 страниц документации.
А потом... уволился.
Оставив после себя: красивые схемы в Confluence ни одной строчки кода команду, которая теперь на рефакторинг смотреть не может
Как понять, что ваш техлид центральная часть системы самообмана?
главный результат его работы - не код, а презентации коронный вопрос - 'А как мы это будем масштабировать?' (но не сам масштабирует) после разговора с ним хочется или закодить, или закопать
Что прикажете с этим делать?
тупо запретить 'стратегировать' без кода* нет пулл-реквеста - нет права говорить про архитектуру.
ввести 'день испанского стыда' раз в месяц техлид показывает руками, что сделал. Не слайды - код.
Задавать всего один вопрос
'Что конкретно изменится после твоего решения?' Если ответ начинается со слов 'теоретически....' - это тревога.
Вывод Хороший техлид — не тот, кто красиво говорит о проблемах. А тот, кто их решает.
Если ваш 'архитектор' только генерирует документы, но не генерирует код - возможно, он уже ИИ.
P.S. Если после этого текста кто-то узнал своего техлида - это не совпадение
1️⃣ Текущий прогресс по xsoulspace.dev привел к тому, что обнаружил что есть закономерность какие именно модели хороши для использования в проектировании layout страницы (спойлер - не записал какие 🤦♂️ кажется использовал Claude 4.0 thinking + Gemini 2.5 Pro).
Что попробовал сделать : нарисовал простой wireframe image -> сконвертировал в ACSII art, и затем скормил LLM для более корректного восприятия layout.
Оказалось что так проще, но относительно (за счет убирания лишних элементов проще понять что где расположено), но с другой стороны LLM все так же тяжело воспринимать layout (если он чересчур кастомный).
2️⃣обновил все flutter библиотеки, last answer, word by word, budget app до flutter 3.8 - пользовался агентами в окошках. В некоторых случаях правил руками, но в большей части работал по принципу PDSA (Plan Do Study Act), где я разрабатывал план, а агент по нему шел, потому изучал результаты и т.д. Вывод - нужно сильнее нарабатывать промпты.
3️⃣внезапно получил спам-рассылку-письмо с возможностью потестить on device API для того чтобы запускать модели. Чтобы потетстить решил запилить новое приложение для работы с промптами - действовал по принципу:
Идея и этические принципы
Палитра и дизайн система на основе идеи и принципов
План работы
Имплементация через агентов + доп ресерчи чтобы агенты понимали какую информацию брать.
Удалось собрать прототип за 12 часов (рабочую, включая все экраны и дизайн систему). Следующий этап - буду модифицировать чтобы можно было тестировать на реальных промптах в проектах.
Опыт: понял как создавать и работать с ролями (опишу в следующем посте про MVP), разобрался как запускать LLM на устройстве. Недостатки: нужно более точно прописывать тех стак, особенно ключевые места, такие как - синхронизация данных, тип хранилища и т.д. И хорошо если изначально можно давать wireframes, или подгенеривать на основании дизайн системы.
Хотелось сделать нечто среднее между игрой и обычным интерфейсом, но пока не получилось.
4️⃣Создал детальный план и начал прорабатывать новую систему сохранения данных. Для меня это оказалось большой проблемой - потому что Hive, Isar на flutter перестали поддерживаться, а другие библиотеки неудобно использовать (где-то перешел на Sembast).
В результате на мой взгляд завязка на том, что данные хранятся непонятно где для конечного пользователя опасна тем, что в случае прекращения работы с приложением теряются все данные. Это оч больно.
Поэтому решил объединить все идеи и написать одну библиотеку которая будет из коробки давать синхронизацию с гитом, github и папками. Так надеюсь удастся побороть проблему долговечности и надежности хранения данных. Пока агенты имплементировали 4 этапа из 5 (основную логику провайдеров данных), и как итог - собрал отдельное тестовое приложение (todo), чтобы протестировать работу (отдельный скриншот), понять недостатки и как можно быстрее завершить библиотеку чтобы начать интеграцию во все проекты. Это важно, потому что при одновременной интеграции сразу будет понятно что работает, а что нет, и таким образом будет проще получать feedback и развивать библиотеку качественно.
Спасибо за ваше время и хорошего дня!
p.s.:
Бумаги которые claude нашел по теме и одновременно не по теме)
Последние из группы Поведенческих паттернов: Хранитель и Шаблонный метод
В одиннадцатой серии курса «Паттерны и практики написания кода» вместе с бэкенд-инженером Юрой Афанасьевым завершаем тему Поведенческих паттернов. Последние два подхода, которые разберем в эпизоде: Хранитель и Шаблонный метод. Подробнее про их реализацию в коде, преимущества и недостатки — в эпизоде.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Всё о назначении и применимости Наблюдателя и Цепочки Обязанностей
Это десятая серия курса «Паттерны и практики написания кода»: вместе с бэкенд-инженером Юрой Афанасьевым продолжаем изучать тему Поведенческих паттернов. В новом эпизоде разбираем два подхода, связанных с отправкой и обработкой событий: Наблюдатель и Цепочка Обязанностей.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
