Хочу обсудить с коллегами разработчиками один вопрос, чтобы понять — это лично моё восприятие ситуации или нет, и если да — нашёл ли кто-то для неё решение?
Чем занимается настоящий™ программист?
Если сильно упростить картину мира и не вдаваться в детали, любой программист какую-то часть времени обязательно делает две вещи:
Продумывает, как решить поставленную задачу с помощью написания кода, разделяя его на слои, сущности, системы, модули, классы, методы и т.п.
Пишет этот код
Только вот в реальности разделение на эти два этапа это очень эфемерное. Многие разработчики на первом этапе продумывают реализацию очень поверхностно, и большинство решений принимаются уже в процессе написания кода. Безусловно, баланс между размышлениями «до» и «во время» написания кода для разных проектов, людей и задач разный, но даже в самом идеально продуманном решении при написании кода продолжают приниматься десятки микро-решений, вплоть до банального «а как назвать переменную».
В общем, для многих людей во многих ситуациях программирование это не «сначала думаю, потом пишу», это «пишу и думаю одновременно». Можно долго ломать копья на тему того, насколько это правильно или неправильно, но в этом процессе очень легко словить то самое знаменитое «состояние потока». Именно этим, а также относительно коротким циклом обратной связи от своей работы (написал — собрал — протестировал — исправил) программирование и привлекало немало людей ещё в те времена, когда программирование ещё не стало мейнстримовой профессией, в которой есть какие-то деньги.
А потом пришёл «ИИ»
Если говорить об использовании «ИИшки» в виде эдакого чата-справочника, помогающего нащупать решение или там проанализировать крэшлог — ничего в описанной схеме не меняется, просто на этапе продумывания решения и анализа появился новый инструмент. Но стоит перейти к написанию с помощью LLM’ок больших кусков кода, целых модулей и систем… тут начинается совершенно иная картинка.
«ИИшка» требуется приложить гораздо больше усилий на первом этапе (продумывание решения), полностью забирает себе второй этап (написание кода и продумывание на ходу микрорешений), да ещё и добавляет третий этап, «ревью полученного кода». Нет, понятно, что отрефлексировать качество своей работы перед релизом или поревьюить чужой код — задача тоже типичная, но фокус работы в целом сильно меняется, «своего» кода у такого программиста больше нет. Свои у него спецификации, промты, контексты для LLM’мок и много что ещё, но не код.
И вы можете спросить, а в чём проблема то собственно? «Семь раз отмерь, один раз отрежь» же! Наконец то разработчики будут вынуждены детально продумывать решения до начала реализации, это же явно пойдёт на пользу финальному продукта, верно? Кроме того, всегда существовали программисты, для которых этап набора кода был пыткой, «я же всё уже продумал, осталась самая скучная часть — буковки печатать». И вот, ура, скучный этап отдан машине! Красота же, нет?
Ну… возможно. Но есть два нюанса.
Первый этап часто был именно что этапом «продумывания», на бумаге/файлик/схемке фиксировались только опорный пункты, большая часть идеи оставалась в голове. Но теперь «думанье» и «реализацию» делают разные сущности, нельзя прямо из головы передать LLM'ке свои мысли. А значит фиксировать план нужно на порядок тщательней и подробней. Раньше такая фиксация просто не требовалась, да и формат этой деятельности сильно изменился, и теперь это диалог на человеческом языке, больше похожий на менеджерскую постановку задачки.
Ну и во-вторых, в этом формате пропадает «потоковая» часть работы, теряется прелесть короткого цикла «сделал — проверил — исправил». После постановки задачки система уходит на раздумья и написание кода на минуты, а то и десятки минут. Местами возникает ощущение, что вернулся цикл отклика от ЭВМ до-PC-шного периода. И скорость отклика эта неконтролируемая, не всегда предсказуемая, и пока ты ждёшь — переключаешься на другую задачку, а вместе с ней меняешь и контекст в голове. Но когда бот вернётся за следующей порций задач или с вопросами — придётся переключать контекст опять, да ещё и вычитывать ту гору кода, что он написал. А постоянные переключения контекста это нифига не бесплатно...
Ну а как дела у вас?
Выше описана моя субъективная картину мира, но картина мира != реальности. Поэтому я хотел бы повторить вопрос из начала поста: ощущаете ли вы ту самую потерю потока при разработке с LLM'ками? И если да — нашли ли вы решение, как словить поток и ритм, используя «ИИ» как инструмент?
P.S.
КДПВ действительно моё. Я по-быстрому сфоткал руки на клавиатуре... и увидел на ней гору пыли, которую не замечал ранее. Протереть то я её протёр, но так лень было перефотографировать заново, фотоаппарат на подвес возвращать, в розетку его втыкать (он у меня через заглушку батареи работает), потом файлы по кабелю перекидывать... И решил я провести эксперимент - попросил GPT-шку убрать пыль с фото. И тот справился идеально. Даже слишком идеально, получилось рекламно-стерильно. Настолько, что в начале я решил оставить оригинальное фото)
Комментарии (23)
a3d
14.08.2026 05:56Я проходил все этапы
----
1. Программирование без llm,
а) по книжкам во времена бейсика, паскаля до интернет эпоху.
б) с инетом: гугление доков, чтение спеков языка/библиотеки и т.д.
2. Кодинг с llm в чате, который просто отвечает на вопросы, помогает оформить функцию красиво, написать сложный математический алгоритм, сделать по быстрому пасинг входных данных (это я больше никогда в ручную делать не буду, даже под дулом, ллм делают это супер эффективно и качественно) и т.д. То есть только кусочки на ллм, остальное всё на мне. Сборка руками через консоль в ИДЕ.
3. С агентом.
а) постановка только глобальных задач для агента, а потом правка глюков доработка с помощью агента, по циклу, пока не наступит сингулярность.
б) постановка задачи приложения + задание базовых алгоритмов функций, констант, классов, связи их и т.д.
--------
3.а - я уже не могу назвать программированием вообще, это промпт инжиниринг какой-то с попытками юзера угадать что получится у ллм а ллм угадать что именно надо юзеру.
3.б - это уже эффективное программирование, но понимание кода и возможность потом его править и модифицировать очень минимальная.
2. - для самый прикольный вариант кодинга эффективность/скорость по сравнению с 3 - в разы хуже, но зато масштабируемость и оптимальность полученного кода и его понимание очень хорошее.
1 а и б. - ну это я похоронил уже с год назад, мало кто к этому вернётся толко в очень узких задачах или совершенно твердолобые конченые консерваторы, наверное уже большинство юзают 3.б. Об 3.а. - нечего разговаривать даже, это и порождает нейрослоп низкого качества.
Так вот мне нравится 2., в нём есть поток есть большое влияние на то как код выглядит, понимание его в голове, но после того как знаешь скорость и эффективность достижения того же с агентом, выстроенные нейросвязи в голове для получения более короткого дофамина всегда стараются идти снова по ним же и выбирать 3.б.
a3d
14.08.2026 05:56з.ы. Но исходное фото с клавой, все равно слишком идеально ;) , нехватает, кусков чипсов, печенек, засохших капель кофе и молока, жирных отпечатков. И вообще под пробелом должны быть запасы еды на случай ядерной войны минимум на 2-3 недели.
з.з.ы. заметил почему-то нампад не достаточно отполирован, у меня и верхние цифры и цифры нумпада одинаково глянцевые. О, еще esc смещён, интересно чем руководствовались создатели этой раскладки...
Newbilius Автор
14.08.2026 05:56Но исходное фото с клавой, все равно слишком идеально ;)
Просто я умею кадрировать фото (без ИИ), так что всё лишнее сдвинуто на край стола :D
А про нампад - я им ерально не пользуюсь, цифры использую те, что над буквами. Привычка)
pfemidi
14.08.2026 05:56IMHO нампадом пользуются только бухгалтерши и секретарши, которым невдомёк что есть ещё и цифры над буквами, пользоваться которыми реально удобнее. Так что плюсую!
kukovik
14.08.2026 05:56Вы правы и не правы одновременно. В первой половине фразы правы, но не только они, но в основной массе. Во второй части фразы вы сильно и грубо ошиблись с причиной. Она в том, что им, работающим в основном с цифрами, безусловно гораздо удобнее вслепую долбить по нампаду. Наверное вы просто ни разу не видели их за работой, а показанное вами пренебрежение к этой категории пользователей ПК подцепили где-то в интернете.
pfemidi
14.08.2026 05:56Я прекрасно видел их за работой -- у меня жена работала в центре авторизации и ей единственное что требовалось набирать на клавиатуре, так это цифры, цифры и ещё раз цифры. И да, набирала их вслепую, долбя по нампаду. Но чтобы тому, кто набивает тот же код, было удобнее постоянно двигать рукой туда-сюда набирая буквы на клавиатуре, а цифры исключительно на нампаде... Знаете ли, для меня это нонсенс и реально какой-то мазохизм. Это как не выучить горячие клавиши и по каждому чиху тянуться за мышкой чтобы требуемую операцию не нажать не глядя каким-нибудь Ctrl-Alt-G, а выбирать из списка контекстного меню, выпадающего из меню, которое вызывается из меню.
amazingname
14.08.2026 05:56На сегодня в энтерпрайзе проекте у меня это выглядит примерно так. Описываю задачу, минут 20 жду вариантов как ее впереть в существующую архитектуру. Обсуждаю варианты и минут 20 жду базового решения. Обсуждаю чего ещё не хватает и 20 минут жду очередной доработки. В итоге процентов 50 времени уходит на обдумывание и активное обсуждение и процентов 50 тупо на ожидание долгих доработок. Потом с POC иду к лидам и вайбкожу с нуля ещё раз все по-другому. В итоге код выдаваемый за неделю раз в 10 превосходит то что выдал бы вручную. Но 80 процентов из него это POC и тесты. Ревью занимает все меньше времени, по мере того как набивается рука что проверять - по сути только архитектуру, в мелочах недочётов у LLM все меньше.
И да, половину времени ждёшь результата, читая новости и выпадая из потока. Что с этим делать пока не понял.
kukovik
14.08.2026 05:56Ну то есть вы в него все же попадаете. Как и я, впрочем. Проваливаюсь с головой в обсуждение. А автор вот жалуется.
tarielx
14.08.2026 05:56На работе обычно
- сначала вайбкодинг плана доработки, несколько итераций правок с LLM.
- затем агенты в цикле реализуют план
- и в конце ревью кода и переписывание руками участков, чтобы был аккуратный стиль, соответствие конвенциям и человеко-читаемость
LLM слишком часто либо забывает ньюансы, либо наоборот переусложняет. Не знаю, недостаточные ли это инструкции или так и должно быть.
Если в промежутках ожидания просто ждать результата, то к концу дня возникает ощущение, что день прошёл впустую. Поэтому стараюсь параллельно делать другие задачи, писать документацию, руками ли или через LLM.
Для себя через LLM делаю только то, что выходит за пределы моих компетенций, вроде ansible плейбуков. Код стараюсь писать сам, руками, чтобы не потерять навык. Используя LLM только для помощи и изучения нового. Тут с состоянием потока проблем нет.
yar3333
14.08.2026 05:56Только сегодня об этом задумывался. Состояния потока больше нет. Соответственно, падает внутренняя удовлетворённость от работы. По факту - постановка задачи, более мелкие промты для доработки и правки багов. Ощущение - что я теперь больше ручной тестировщик при нейросети. Но был и элемент оркестрации, когда кажется, что рулишь несколькими разрабами. Согласен, что это временный этап. Жутко любопытно, что будет дальше :)
Necessitudo
14.08.2026 05:56А это все реально повышает скорость разработки?
Akon32
14.08.2026 05:56В определённых сценариях да. Поиск багов, оптимизация - делаются практически мгновенно. Какие-то типичные приложения (crud) и алгоритмы (от перекладывания json до олимпиадных) тоже быстро. А вот на нетипичных системах (например, обработка пространствннных данных) легко получить "не то" в первых нескольких попытках, и тогда уже неясно, не лучше ли сделать всё самому.
nrth18
14.08.2026 05:56повышает драматически. Делегация задач (самые противные, которые не хочется делать) вроде поиска багов в кодобазе с логами - это просто небо и земля по сравнению с тем, что было ещё год назад. Задачи в жире закрываются очень быстро. Минусы - код уже не наш. Нет, ревью конечно всё ещё есть, и код ты отсматриваешь перед пушем, может, даже что-то просишь исправить, что ещё не успели внести в скиллы. Но будем честными, такой поток задач качественно уже не отревьюить, и тут тоже на помощь кожаным приходят железные, остаётся только просматривать уже их замечания и понимающе кивать. Не знаю, куда нас выведет такая разработка.
a3d
14.08.2026 05:56Минимум в разы, иногда на порядки. О программировании совсем без ллм, можно забыть... Ну то есть можно вспоминать, да были времена, больше их не будет. Всё.
ferosod
14.08.2026 05:56Раньше такая фиксация просто не требовалась, да и формат этой деятельности сильно изменился, и теперь это диалог на человеческом языке, больше похожий на менеджерскую постановку задачки.
Буквально недавно поймал себя на мысли, что до LLM мог легко кодить под музыку и даже фоновые видосы иногда, а с LLM приходится ставить на паузу, иначе теряется фокус. Как будто для мозга чтение и написание кода не конфликтует с человеческой речью, а вот чтение и написание промптов - да.
wl2776
14.08.2026 05:56В первом этапе ИИ тоже есть. Есть такая штука openspec, я пользуюсь, очень удобно.
Кто-то из великих, то ли Кнут, то ли Дейкстра, сказал ещё лет 60 назад, что сосредоточиться надо не на том, чтобы объяснять компьютеру, что мы от него хотим, а на том, чтобы людям объяснить, что мы хотим от компьютера. Появление кодирующих агентов наконец вытащило эту необходимость на поверхность.
AlexSit79
14.08.2026 05:56Сейчас этап перестройки многолетних привычек. Когда появится новые с "ощущением", а не "пониманием" новых возможностей, то можно браться за более амбициозные задачи и получать удовольствие от красивой концепции а не непосредственно кода.
Тотальное ревью за нейросетью - это временно. В итоге явно проверки будут более косвенные.
Страшнее, если AGI таки придумают - тогда не очень понятно, а вообще для чего люди в целом то нужны.
PS Фото мой клавы ) Только клавиша вправо не стертая.
Wesha
14.08.2026 05:56Эти руки пишут код.
И вот в этом-то и проблема. А я вот код пишу головой. Руками я его всего лишь переношу из головы в компьютер.
Advixum
Потока давно нет. Из программиста стал ревьюером и ручным тестировщиком. Думается, что это временный этап. До совершенствования системного промта приходилось ещё кучу однотипных ошибок выгребать. Нейросети очень мощный инструмент, мы просто ещё не научились им правильно пользоваться.