Архив рубрики ‘технический долг’

История одной IT‑разработки: как мы создали софт по рассылке деловых писем

Всем привет! Я Дмитрий Шихаев, маркетолог для IT‑компаний. Сейчас работаю с крупными IT‑заказчиками, помогаю выводить технологические продукты на рынок и развиваю направление ABM‑маркетинга в России. Но путь к этому был далеко не сладким. Когда‑то мы с товарищем Гошей, у которого за плечами были базовые знания BASIC и опыт работы с конструктором BAS, решили практически без денег и опыта создать собственный софт для массовой отправки качественных персонализированных деловых писем.

ИТ‑шаманизм — когда айтишники старой волны замыкают на себя как можно больше процессов, чтобы их не уволили

У меня немного подгорела жопа, простите. Это случилось давно, поэтому постараюсь быть объективным.

Не ИИ заменит людей, а люди заменят ИИ. И это уже происходит

Как перестать ревьюить правки, о которых никто не просил

С приходом ИИ‑агентов в разработку, кода стало больше, а вместе с ним и шума. Пулреквесты растут, держать агента в рамках задачи становится сложнее, а через голову человека проходит всё больше кода. Ревью превращается в основную нагрузку и зелёные цифры добавленных строк в заголовке начинают напрягать ещё до того, как его откроешь. Типичная картина: пулреквест на небольшую фичу, а в нём правки в десятке файлов, которые к задаче не относятся. По отдельности они […]

Почему мы нанимаем сотни людей, чтобы писать код медленнее

Есть два проекта в двух разных компаниях — оба о том, как затащить дело в крупных корпоратах. Первый: 50 человек персонала, результата практически нет, еле успели доделать всё за год. Второй: людей втрое меньше, и по успешности всё сильно лучше, чем в первом проекте. Давайте посмотрим на суровую реальность. График роста численности персонала в первой […]

Агент пишет быстрее, команда релизит медленнее: 30 дней с coding agent на реальном проекте

Первые несколько дней с AI агентом легко создают ощущение, что разработку наконец‑то «сломали». Даёшь задачу, через несколько минут получаешь diff на несколько файлов, тесты и уверенный отчёт о том, что всё готово. Если мерить производительность от момента, когда ты сформулировал prompt, до появления кода, результат действительно впечатляет. Примерно через неделю я заметил другую вещь: код стал появляться заметно быстрее, а задачи не начали с той же скоростью […]

Хватит считать токены: почему KPI в эпоху ИИ превратились в фикцию

В одной продуктовой команде рейтинг разработчиков строился по количеству сожжённых токенов за день. Менеджеры выделялись зелёным, отстающие — красным. В комментариях к тикету менеджер писал: «Ваня, ты сегодня потратил всего 80 тысяч токенов, а Петя — 400. Подтянись». Ваня, если что, закрыл за день две сложные интеграции. А Петя — весь день гонял агента по […]

ИИ частично ускорил разработку. А что насчёт всего остального?

Разработчик раньше тратил на задачу три дня, а с ИИ справляется за день. Кажется, производительность выросла втрое. Но после разработки задача всё ещё должна пройти ревью, тестирование, интеграцию и выкатку. Если эти этапы не ускорились вместе с написанием кода, быстрее стал только один участок системы. За последние годы ИИ заметно изменил мою работу. Больше не […]

Почему нельзя измерять разработчика строками кода — и что мы делаем вместо этого

Измерить работу разработчика хочется так же, как работу производственной линии: взять понятный счетчик, сравнить план с фактом и получить одно число. Но в разработке самый доступный показатель почти всегда оказывается самым опасным. Количество коммитов можно увеличить, разбивая изменения на части. Число строк растет от копипаста и падает после хорошего рефакторинга. Закрытые задачи ничего не говорят […]

От хаоса к порядку: как управлять техдолгом

Привет! Меня зовут Ира, я тимлид проекта по развитию чатов поддержки в компании «Совкомбанк Технологии». Уже более пяти лет я занимаюсь фронтенд‑разработкой и часто сталкивалась с проектами, где накопленный технический долг замедляет работу команды и усложняет развитие продукта. Этот опыт научил меня не просто исправлять код, а выстраивать стратегию его постепенного и безопасного улучшения без остановки основной разработки.

123.5