Комьюнити о практическом применении ИИ в разработке.
LLM, агенты, Cursor, LangChain, кейсы, вебинары и вот это вот всё.
Про нас — https://spectr.dev/
Учиться — https://ai-academy.spectr.dev/
По сотрудничеству — в ЛС канала
Post #106
27
Код пишется быстрее, а релизы нет. Два взгляда на одну проблему
За последние дни на Хабре вышли два материала, которые стоит прочитать вместе. Один про месяц работы с coding-агентом на реальном проекте, второй — про команду, где Claude Code делает вообще всё, а инженеры работают по 12–13 часов, просто нажимая Enter.
Обе статьи приводят к выводу, что скорость написания кода перестала быть главным ограничением, им становится понимание того, что этот код делает.
В первой статье автор месяц смотрел не на количество сгенерированного кода, а на полный цикл изменения от постановки задачи до релиза.
Локально агент действительно быстр: протянуть новое поле через модели и сериализаторы, сделать миграцию по шаблону, обновить однотипный API-клиент — всю работу, на которую раньше уходила львиная доля времени, агент почти уничтожает.
Проблемы начинаются, когда локальный успех принимается за готовность всей задачи. Diff стал дешёвым, а понимание — нет.
Если разработчик писал функцию двадцать минут, он понимает её устройство, но когда агент за пару минут приносит сотни строк, картину приходится восстанавливать заново. В итоге работа смещается с написания на проверку.
Во второй статье противоположная крайность. Разработчик устроился в компанию, где Claude Code создаёт спецификации, код, тесты, задачи и отчёты.
Руководство требует ускорения, потому что «написание кода больше не бутылочное горлышко».
Люди работают по 12–13 часов, но по сути только нажимают Enter: никто не читает код и не исправляет баги. Цитата из статьи: «никто больше не думает. Всё делает LLM. Это так изматывает».
Автор подчёркивает: проблема не в самом ИИ, а в том, что у инженеров нет времени изучать сгенерированный код, понимать архитектуру и проверять качество. Руководство оценивает работу по числу выпущенных функций и пул-реквестов и не заботится об эффективности результата для пользователя.
Получается, ценность разработчика теперь не в быстром кодинге, а умении понимать, что именно было написано, и решать, стоит ли это выпускать.
Первая статья показывает, как это понимание становится узким местом на уровне отдельного разработчика, вторая — что происходит, когда компания это узкое место игнорирует.
В обоих случаях написание кода перестаёт быть ограничением, но само ограничение не исчезает, а перемещается.
AI в разработке
За последние дни на Хабре вышли два материала, которые стоит прочитать вместе. Один про месяц работы с coding-агентом на реальном проекте, второй — про команду, где Claude Code делает вообще всё, а инженеры работают по 12–13 часов, просто нажимая Enter.
Обе статьи приводят к выводу, что скорость написания кода перестала быть главным ограничением, им становится понимание того, что этот код делает.
В первой статье автор месяц смотрел не на количество сгенерированного кода, а на полный цикл изменения от постановки задачи до релиза.
Локально агент действительно быстр: протянуть новое поле через модели и сериализаторы, сделать миграцию по шаблону, обновить однотипный API-клиент — всю работу, на которую раньше уходила львиная доля времени, агент почти уничтожает.
Проблемы начинаются, когда локальный успех принимается за готовность всей задачи. Diff стал дешёвым, а понимание — нет.
Если разработчик писал функцию двадцать минут, он понимает её устройство, но когда агент за пару минут приносит сотни строк, картину приходится восстанавливать заново. В итоге работа смещается с написания на проверку.
Во второй статье противоположная крайность. Разработчик устроился в компанию, где Claude Code создаёт спецификации, код, тесты, задачи и отчёты.
Руководство требует ускорения, потому что «написание кода больше не бутылочное горлышко».
Люди работают по 12–13 часов, но по сути только нажимают Enter: никто не читает код и не исправляет баги. Цитата из статьи: «никто больше не думает. Всё делает LLM. Это так изматывает».
Автор подчёркивает: проблема не в самом ИИ, а в том, что у инженеров нет времени изучать сгенерированный код, понимать архитектуру и проверять качество. Руководство оценивает работу по числу выпущенных функций и пул-реквестов и не заботится об эффективности результата для пользователя.
Получается, ценность разработчика теперь не в быстром кодинге, а умении понимать, что именно было написано, и решать, стоит ли это выпускать.
Первая статья показывает, как это понимание становится узким местом на уровне отдельного разработчика, вторая — что происходит, когда компания это узкое место игнорирует.
В обоих случаях написание кода перестаёт быть ограничением, но само ограничение не исчезает, а перемещается.
AI в разработке
