Кажется, мы приближаемся к моменту, когда генерация кода перестанет быть игрушкой и станет обычным инструментом разработки. Уже сейчас можно попросить модель написать API, SQL-запрос или даже кусок архитектуры сервиса. Но что будет дальше, когда такой подход станет стандартом? Изменится ли профессия разработчика или просто появится ещё один инструмент вроде IDE?
В этой статье я попробую разобрать, как генерация кода может изменить сам процесс разработки. Не в теории, а с инженерной стороны: архитектура, поддержка, технический долг, debugging и то, как вообще читать код, который писал не человек.
Пару месяцев назад я решил провести небольшой эксперимент. Попробовать писать сервис почти полностью через генерацию кода. Не просто отдельные функции, а прямо весь сервис: API, базу данных, обработчики.
Честно говоря, в какой-то момент стало немного странно. Ты вроде разработчик, но код пишет не совсем ты.
Возникает ощущение, будто ты больше архитектор или редактор кода.
И тут появляется вопрос.
Если генерация станет стандартом, кем вообще будет программист?
Тем, кто пишет код?
Тем, кто проверяет код?
Или тем, кто придумывает системы, которые этот код потом генерируют?
Попробую поделиться наблюдениями.
Программирование постепенно превращается в редактирование систем
Сейчас мы привыкли к модели:
человек → пишет код → код работает.
Но когда появляется генерация, процесс становится другим.
человек → описывает задачу → система генерирует код → человек редактирует результат.
То есть разработчик начинает работать на уровень выше.
Если раньше ты писал контроллер руками:
# Python from fastapi import FastAPI app = FastAPI() @app.get("/users/{user_id}") async def get_user(user_id: int): user = await database.fetch_one( "SELECT * FROM users WHERE id = :id", {"id": user_id} ) if not user: return {"error": "User not found"} return user
то теперь ты скорее опишешь структуру сервиса:
нужен endpoint
нужна проверка пользователя
нужна интеграция с базой
нужна обработка ошибок
И генератор сделает остальное.
В какой-то момент я заметил интересную вещь.
Время написания кода почти исчезает.
Но время понимания кода наоборот растёт.
Потому что теперь тебе нужно читать код, который ты сам не писал.
И вот это, как мне кажется, одна из самых больших будущих проблем.
Самая недооценённая проблема — чтение чужого кода
Если вы когда-нибудь открывали legacy-проект, вы знаете это чувство.
Ты смотришь на файл и думаешь: кто вообще это написал?
А теперь представьте, что код генерируется постоянно.
Каждый разработчик генерирует его по-своему.
Каждая система генерирует его немного иначе.
И в итоге кодовая база становится огромным зоопарком стилей.
Вот пример типичной функции, которую может сгенерировать модель.
// JavaScript (Node.js) async function processPayment(userId, amount) { const user = await db.users.findOne({ where: { id: userId } }) if (!user) { throw new Error("User not found") } if (user.balance < amount) { throw new Error("Insufficient balance") } const transaction = await db.transactions.create({ userId: user.id, amount: amount, status: "pending" }) try { await paymentGateway.charge(user.cardToken, amount) transaction.status = "completed" await transaction.save() } catch (err) { transaction.status = "failed" await transaction.save() throw err } return transaction }
Код вроде нормальный.
Но через год может появиться другой генератор.
Он будет писать немного иначе.
Через два года — ещё один.
И кодовая база постепенно превращается в смесь разных стилей.
А теперь вопрос к вам.
Как читать проект из 20 миллионов строк, если половину писал человек, а половину — разные генераторы?
Мне кажется, именно здесь появятся новые инструменты.
Не генераторы кода.
А анализаторы кода, написанного ИИ.
Архитектура становится важнее кода
Чем больше я экспериментировал с генерацией, тем сильнее замечал одну вещь.
Самая сложная часть разработки — это вообще не код.
Это архитектура.
Код можно сгенерировать.
Но архитектуру сгенерировать почти невозможно.
Например, представим простой сервис рекомендаций.
// Go type RecommendationService struct { userRepo UserRepository itemRepo ItemRepository } func (s *RecommendationService) Recommend(userId int) ([]Item, error) { user, err := s.userRepo.GetUser(userId) if err != nil { return nil, err } history, err := s.itemRepo.GetUserHistory(userId) if err != nil { return nil, err } recommendations := calculateRecommendations(user, history) return recommendations, nil }
Сам код тут не сложный.
Сложно другое.
где хранить данные
как масштабировать систему
как строить pipeline данных
как кэшировать результаты
как обрабатывать миллионы запросов
Это уже архитектурная задача.
Поэтому мне кажется, что разработчики постепенно будут двигаться в сторону системного мышления.
Меньше писать код.
Больше проектировать системы.
Дебагинг станет новым искусством
Есть ещё одна интересная проблема.
Баги.
Когда код пишешь сам, ты хотя бы примерно понимаешь, где может быть ошибка.
Но когда код сгенерирован, всё становится страннее.
Ты читаешь функцию и думаешь:
логика вроде правильная… но почему это падает?
А потом находишь какой-нибудь такой кусок.
# Python def normalize_score(score): if score is None: return 0 if score > 100: score = 100 if score < 0: score = abs(score) return score / 100
На первый взгляд всё нормально.
Но если score = -50, результат будет 0.5.
А должен быть 0.
Такие вещи появляются постоянно.
И чем больше генерации — тем больше таких багов.
Поэтому debugging становится ключевым навыком.
И вот тут у меня к вам вопрос.
Что сложнее:
написать код или понять, почему код ведёт себя странно?
Мне кажется, второе.
Возможно появится новая профессия
Иногда кажется, что мы движемся к новой роли.
Не совсем программист.
И не совсем архитектор.
Скорее что-то вроде инженера генерации кода.
Человек, который:
проектирует структуру системы
описывает требования генератору
проверяет результат
оптимизирует архитектуру
Похоже на то, как появились DevOps-инженеры.
Раньше их просто не существовало.
Теперь это отдельная специализация.
Возможно через несколько лет появятся люди, которые вообще почти не пишут код.
Они проектируют систему так, чтобы код генерировался правильно.
Итог
Мне кажется, программирование никуда не исчезнет.
Но изменится фокус.
Меньше ручного кода.
Больше архитектуры.
Больше анализа систем.
Больше debugging.
И возможно самая ироничная вещь.
Навык номер один будущего разработчика — это умение читать код.
Даже если его писал не человек.
Кстати, интересно ваше мнение.
Если генерация кода станет стандартом — станет ли программирование проще?
Или наоборот сложнее?
Комментарии (30)
Kot_na_klaviature
12.03.2026 14:17Сегодня писал фичу руками и прямо кайфанул. Полный контроль, никакого иишного идиотизма, напряжения от рулетки, никакого ревью, исправлений, раздражения.. Да, медленнее значительно. Но код на 100% такой, как мне нужно и удовольствие от работы. Уже забыл что это такое. ЛЛм вроде избавляет от рутины, но с ревью больше устаешь, пытаясь итерациями довести код хотябы до приемлимого уровня. Все говорят про производительность, а про то, что нравится или нет эта новая работа ревьюером, редактором, менеджером ллм - никто. Качество кода/архитектуры и ощущение разработчика тоже важно.
house2008
12.03.2026 14:17Тоже прихожу к мысли что от ИИ агентов нужно уходить (только как чат использовать для коротких кусков кода). Написание хорошого подробного промпта занимает примерно 30% времени если бы самому с нуля писать, я говорю про настоящий промпт который создает фичу за один проход и потом пару мелких правок остается доделать. То есть хороший подробный промпт это 2-3 часа, потом кодогерация 20 минут, потом ревью и добивка до финального состояния еще полчаса-час, в итоге задача готова за 4 часа, но это всё выматывает настолько (читка тонны чужого кода) что лучше бы я сам потратил на написание кода 10 часов на лайте под музыку. Думаю скоро настоящие разрабы с ИИ (не вайбкодеры кто не смотрит в код) будут получать массовое выгорание очень быстро и скорость разработки будет полностью этим нивелирована.
MrBrooks
12.03.2026 14:17Система заставила думать. Неприятно, согласен.
Можно оставаться на том же месте и продолжать ничего не менять.
А если серьезно, то это тяжело только на первых порах. Потом придут идеи, как оптимизировать одно. Потом второе, третье. На выходе вообще получится так, что оно само там пыхтит, скребёт, работает, и получен годный результат.
Вы же в универе тоже по началу страдали и думали)
house2008
12.03.2026 14:17Так проблема упирается в проверку корректности кода созданного ИИ, человек никак быстрее думать не сможет, ему все равно нужно будет смотреть код ИИ. Человек пишет фичу 8 часов, за эти 8 часов он итеративно строку за строй сразу же и валидирует и проверяет код, и это размазывается на 8 часов и ментально человек не устает. Когда нужно отревьюить 8 часов кода, но за один час, это создает очень сильную нагрузку и выгорание уже где-то на пороге при такой нагрузке. То есть без ИИ было просто 8 часов кодинга по ТЗ, стало 3 часа описание подробного тз и 1 часа ревью 8 часового кода, что равно = 11-12 часовая нагрузка.
Если вы не проверяете код за ИИ у меня для вас плохие новости.
Согласен с вами, что время покажет, посмотрим, что из этого выйдет
MrBrooks
12.03.2026 14:17Как уже сказано было кем-то и где-то. Если вы каждый шаг проверяете за ИИ, значит, вы где-то упустили возможность что-то автоматизировать.
По своему опыту скажу, что ИИ очень круто автоматизируется и обучается. Особенно, клод и его Опусик с Соннетом. Это прям потрясающие ИИ, которые работают идеально, если правильно научить их работать с вашим кодом.
Kot_na_klaviature
12.03.2026 14:17Ещё ни разу не видел, чтобы модель инициативно создавала архитектуру. С цепочкой классов с интерфейсами с правильно огранизованным наследованием, с фасадами, с внедрением зависимостей.. Чтобы логически правильные конструкторы и размещение атрибутов и параметров. Агент всегда решает задачу "здесь и сейчас". Всегда прямолобый код у всех топовых моделей. А если начинать расписывать где какие классы нужны с какими методами, это уже понеслась работа, на этом вайбкодинг заканчивается. И потом, когда сформировано подробное ТЗ с примерами (а это тоже мягко говоря не сразу), все равно огромное количество тупости. От организации методов до передачи данных. Ну логика страдает постоянно. Может загружать отношения по нескольку раз в разных местах или связать классы одной функциональностью (и в чем тогда смысл разделения). Или переменные по тупому организовать или синтаксис из прошлого десятилетия, усложнения в читабельности, постоянные дублирования логики, не использование возможностей фреймворков (и какой тогда в них смысл), фоллбэки везде где только можно, что никакую ошибку не поймать.. Все на многократных исправлениях. А исправления бывают тупее чем первоначальные варианты и это все надо обьяснять, постоянно печатать тк много ссылок, названий итд.. выхватываешь раздражение в итоге и усталость. Я абсолютно точно знаю, что большинство забивает на такие "мелочи" т.к. у самих код всегда был не лучше. Максимум пробегутся глазами вертикально с видом, что все в порядке. Но у меня проекты долгосрочные с постоянным развитием, качество и поддерживаемость кода на первом месте т.к. любые костыли всегда порождают новые и по цепочке. Техдолг сразу себя не проявляет, но это всегда растущие проблемы.
Shoman
12.03.2026 14:17Конечно важно, и даже пока это все использует мало людей, ничего страшного. Но когда начнете проигрывать на рынке со своей производительностью, (не вы конкретно возможно, но в целом) то и выбора не останется.
Kot_na_klaviature
12.03.2026 14:17Производительность за счет качества нужна только тем у кого нет денег или кому плевать на свой продукт. До ллм можно было нанять за почтибесплатно 10 начинающих "индусов" вместо одного нормального разработчика - было бы тоже очень производительно.
Shoman
12.03.2026 14:17Ага им еще пару менеджеров и то шанс что они что-то путное родят, резко падет. А вот когда будет ситуация когда один нормальный разработчик делает 1.5-2-3 раза больше, с «ии» чем нормальный разработчик без «ии», вот тогда будет интересно
Kot_na_klaviature
12.03.2026 14:17В 3 раза больше производительность - это значит он в 3 раза больше ревьюит код, что отнимает время и энергию. А частенько он будет просматривать его вертикально (работает и ладно), без каких-то идей по архитектуре и тд которые часто приходят во время написания руками. Плюс объяснять все это ллм геморойно. Т.е. будет производительность за счет качества. Плюс далеко не всем компаниям нужна "сумасшедшая производительность". Там где важен продукт и его поддержка - качество всегда будет на первом месте. Я не говорю, что ии не нужно юзать. ИИ хорош для коротких явных генераций - например есть абстрактный класс от которого уже один сервис отнаследовался и тебе нужно написать второй точно такой же. Вот такое можно сгенерировать. А вот в разработке прям фич, ну хз, что-то я подустал от такого..
Shoman
12.03.2026 14:17Но ревью когда занимает меньше времени ведь так? Нагенерило посмотрели. Поехали дальше.
>>А частенько он будет просматривать его вертикально (работает и ладно)
И в чем тут проблема? Люди не делают ошибки? Вы не видели багов готовые живут годами? вопрос лишь в том к какой вероятностью она будет их делать, если меньше чем человек-то..
>>без каких-то идей по архитектуре и тд которые часто приходят во время написания руками.
Лично мне идеи по архитектуре проходят вообще в основном не тогда когда я пишу код. Вообще написание кода далеко уже не основное на что уходит время.
Или вы когда приходите на проект который до вас писали пару лет, вы его весь ревьюите? Или все же «верите что оно работает» и начинаете добавлять фичи, улучшать архитектуру? Так и тут.
Самому конечно прикольно писать в тоже люблю, но сейчас в основном делаю уж какие-то совсем интересные задачи. Как я написал выше пока это работает и влияние на рынок не заметно, как только 20-30% начнут активно использовать, то и остальным придется. Компаний которым надо качество где супер задачи и они будут за это готовы переплачивать не так и много.
Kot_na_klaviature
12.03.2026 14:17Нагенерило посмотрели. Поехали дальше.
Если плевать на свой продукт, то наверное да. У меня опыт с ллм немного другой.. Уже писал насчет быстроты. Она не для всех на первом месте. Тем более за счет качества. Мне нужна архитектура, долгосрочная поддержка, качество и получать удовольствие от работы. Работать в соревнованиях на скорость не планирую.
IVA48
12.03.2026 14:17Кто ратует только за быстроту создания программного кода с помощью текущих возможностей автогенераторов в ущерб перечисленных Вами требований, то, как говорится, бог им в помощь. Ответственные разработчики это прекрасно понимают и полностью разделяют Вашу позицию, а на поднятый по этой теме хайп смотрят не иначе как на попытки (сознательные или нет - это отдельная тема) их деквалифицирования (профессионального обнуления) и лишения способности самостоятельно думать и принимать решения.
Shoman
12.03.2026 14:17Так вот то что качество потеряется, это лишь домыслы. если на этапе нагенерил-посмотрел что-то не устроило, никто не мешает «исправить». И со временем исправлять приходится все реже.
А архитектура продумывается и так, а написание кода лишь реализация.
Я же не говорю что оно заменяет разработчика, думать то всеравно нужно, а вот потребность написания кода руками потихоньку отпадет все больше и больше. И именно это повлияет на рынок
IVA48
12.03.2026 14:17Верификация стороннего программного кода (неважно кем созданного, человеком или ИИ-роботом) по трудоемкости соизмеряется с его разработкой с нуля, начиная с порога в 1000 строк на ЯП. Причём не только требуется его тщательное тестирование, но и документирование всей логики для последующей поддержки другим разработчиком, облегчая ему работу. Если речь пойдёт о десятках и сотнях тысяч строк такого кода, то можно только представить об"ем и сложность такой работы. Причём нужно учитывать, что сама специфика воспринятия и верификации чужого программного кода НЕ проще (а в некоторых случаях и сложнее) его непосредственной разработки и НЕ каждому специалисту под силу делать её квалифицированно. Прежде всего требуется большой практический опыт именно самостоятельной разработки. Поэтому, если смотреть с этих профессиональных позиций, то как говорится, "ещё бабушка на двое сказала" будет ли все проще и лучше работать с таким готовым "на блюдечке" кодом.
Было бы точно и значительно лучше ровно наоборот: текст программного кода разработанный человеком проверяет ИИ-робот, находит ошибки и выявляет уязвимости. Вот тогда это действительно бы ускоряло процессы отладки и тестирования, а в целом сокращало время разработки сложного ПО.
Pshir
12.03.2026 14:17До ллм можно было нанять за почтибесплатно 10 начинающих "индусов" вместо одного нормального разработчика - было бы тоже очень производительно.
Так ведь именно так до LLM и делали :) условному Майкрософту на качество кода вообще с высокой колокольни наплевать. Почти никто же не откажется от Windows или Office, что бы там индусы или LLM ни наворотили.
atues
12.03.2026 14:17Ну ладно, программисты в обычном понимании станут вымываться из процесса. Несомненно появятся инструменты верификации кода, написанного ИИ. Вопрос первый: кто напишет эти инструменты? Тот же ИИ? Волк будет служить сторожем в овчарне и охранять овец от самого себя? Вопрос второй: программисты - ладно, они все-таки (пусть не все) как-то перестроятся на новые форматы работы. А что делать продакт-менеджерам, аджайл-кришнаитам и вообще - всей той обвязке, что существует (пока) в разработке ПО? Я, к слову, из программистов, так что вроде как проблемы индейцев шерифа волновать не должны, но все-таки любопытно )))
Pshir
12.03.2026 14:17А что делать продакт-менеджерам, аджайл-кришнаитам и вообще - всей той обвязке, что существует (пока) в разработке ПО?
У них всё будет прекрасно. Это ведь они оценивают эффективность вашей работы, а не вы - их.
badsynt
12.03.2026 14:17Когда код начинают писать машины: что реально изменится в программировании
Сегодня Вы ( и машина) пишете код на языке высокого уровня, который придуман человеком и для человека. Предположим, что завтра машина придумает язык программирования для машин. Который, опять предположим, будет гораздо эффективнее и безопаснее нынешних языков. Листинг , очень возможно, будет выглядеть так - 0110000101000.... Что реально измениться в программировании? "А скрипач не нужен, родной …"
misha_ruchk0
12.03.2026 14:17скрипач, возможно, и не нужен, но дирижер и копазитор, навреное, пригодятся.
Evil_Punker
12.03.2026 14:17Не нужно будет читать код. Никто сейчас не лезет в сгенерированный машинный код и не разбирает инструкции. Будете решать задачи "по месту" на один раз без поддержки, и все превратиться в сбор и формализацию требований.
bm9
12.03.2026 14:17Недавно решил провести эксперимент - вместо ручной пилы взял станок с ЧПУ и сделал деталь почти без ручного вмешательства.
И тут появляется вопрос.
Если станок станет стандартом, кем вообще будет столяр?
SmirnGreg
12.03.2026 14:17В реальности пролетариат перешёл в офисы и в услуги. Несколько сейчас офисным работникам останется хоть какая-то работа, или все будет заменено роботами, это вопрос.
Pshir
12.03.2026 14:17Программу для ЧПУ кто составлял? Вы или сам станок по словесному описанию? Разница же лежит именно в этой плоскости: вы машине свои требования передаёте на формализованном языке (обычное программирование) или на естественном (вайбкодинг).
IVA48
12.03.2026 14:17Для профессионального разработчика (!!! не путать с кодером, вайбкодером и т.п) создание серьезного ПО это по сути и этапам процесс 1в1 проектирования и изготовления сложного технического изделия. Пониманию этого вот уже как полвека. Процесс непосредственного написания программного кода соотносится с этапом изготовления деталей изделия на станках по разработанным техпроцессам. Добавляется только то, что программный код каждой процедуры (не говоря уже о всем проекте) должен быть задокументирован его автором, если он разрабатывался не по заранее строго задокументированному алгоритму и имеет варианты реализации. То есть программный код "пишется" (не люблю это слово в этом контексте) не только для ЭВМ, но или других людей, которые впоследствии должны его быстро воспринять и внести необходимые коррективы для продолжения жизненного цикла ПО. Это первое.
Верификация стороннего программного кода (неважно кем созданного, человеком или ИИ-роботом) по трудоемкости соизмеряется с его разработкой с нуля, начиная с порога в 1000 строк на ЯП. Причём не только требуется его тщательное тестирование, но и документирование всей логики для последующей поддержки другим разработчиком, облегчая ему работу. Если речь пойдёт о работе с десятками и сотнями тысяч строк такого кода, то можно только представить об"ем и сложность такой работы. Причём нужно учитывать, что сама специфика воспринятия и верификации чужого программного кода НЕ проще его разработки и не каждому специалисту под силу делать её квалифицированно. Прежде всего требуется большой практический опыт самостоятельной разработки. Если смотреть с этой позиции, то как говорится, "ещё бабушка сказала" будет ли все проще и лучше. Это второе.
Было бы неоценимо, если бы ИИ-робот по тексту программного кода отдельной процедуры мог бы сделать её проверку и указать на ошибки, уявимости или возможное их появление при работе кода. То есть наоборот: верифицировать программный код разработанный вручную. Тут я двумя ногами за такого бесценного ИИ-помощника. Но как сказано выше, модели ИИ построенные на LLM, могут делать только то, чему обучены, а точнее на что настроены. Смогут их такому их научить (а может уже и умеют !) тогда, как говорится, "пример в студию" и я снимаю шляпу.
amazingname
12.03.2026 14:17Пока ничего принципиально не меняется. Раньше замысел нужно было описывать кодом, сейчас замысел и код надо описывать словами. Суть не меняется - нужно производить как можно быстрее работающий код, так чтобы не терять контроль и не утонуть в хаосе и неопределенности.
До тех пор, пока АИ недостаточно умён, чтобы взять на себя всестороннюю ответственность за развитие продукта, программист по сути занимается тем же самым что и раньше, пропуская через мозг понимание что как работает и куда это все идёт.
Что возможно станет приятнее, это укрупнение задач отдельного разработчика, когда целую фитчу или модуль пишет один человек. Раньше наниматели старались этого избежать, опасаясь рисков - медленно, риск прочесть если человек уволится. Теперь становится быстрее и с АИ намного легче оперировать чужим кодом.
И ещё - невероятно дешевые POC. Теперь вместо того чтобы просить коллегу рассмотреть возможность что то добавить в его модуль я могу добавить это сам с АИ за пол часа и прийти на митинг с готовым вариантом решения.
Cobalt
Что вам мешает задать правила кодстайла и реализовать авточек написанного по задаче кода на кодстайл? Что мешает проработать архитектуру на уровне диаграм и полного описания? И да, согласен что профессия в том виде в котором была изменится. Мы не будем писать код, мы будем задавать правила для его написания и контролировать результат
1VK
"Мы не будем писать код, мы будем задавать правила для его написания и контролировать результат" - не хватает картинки с Шариковым
ToniDoni
Вы сейчас многих лидов обидели