О проблемах с ИИ-кодингом на Хабре написано уже много. Но хочется перейти к конструктивному подходу: да, наломать дров с ИИ легко, а вот как работать с ним наиболее профессионально?

Известные разработчики вроде Митчелла Хашимото (создателя Terraform и Ghostty) всё чаще говорят вещи в духе «вот тут уже ни строчки кода не написал вручную». При этом Хашимото — противник слопа, и он подчёркивает, что добился от ИИ качественного кода. А что помогает добиваться?

Мы в проекте Kodik подобные вопросы ощущаем особенно остро, потому что в редакторе кода с ИИ делаем… собственно, сам этот редактор кода с ИИ. Так что для нас все проблемы ИИ-кодинга особенно наглядны, а их решения — особенно важны.

Поэтому мы собрали вместе идеи и из опыта мировой IT-индустрии, и из нашего собственного. Это не какая-то «окончательная истина»: сейчас вся планета только разбирается, ни у кого ещё нет полных ответов, и полезно обмениваться опытом. Так что смело дополняйте в комментариях: интересно узнать, что помогает вам, и собрать «общехабровую кладезь знаний». А если захочется конструктивно возразить, такие обсуждения тоже полезны.

Перечисленные дальше варианты — это полезные практики, но не «серебряные пули», магически создающие идеальный проект. И самое важное в этом списке — не какой-то «тайный промпт», а последние пункты, которые и до ИИ всегда были главными:

Оглавление

  • TDD

  • SDD

  • Экономия контекста и токенов при чтениях

  • Выбор стека: типизация и «стандартизация»

  • Подход к Git

  • Риск-менеджмент

  • Понимание ИИ

  • Понимание программирования

  • Обучение программированию

TDD

Как бороться с ошибками ненадёжной машины? С ходу напрашивается вариант «с помощью тестов» (они не дают полной гарантии, но с ними явно лучше). А дальше начинаются интересные уточнения: например, можно ли поручать машине тесты, проверяющие код от неё же?

В подобных случаях возникает проблема «reward hacking». ИИ-модели неплохо натренированы на то, что нужно «достигать результата»… но могут понимать это как «любой ценой». И если модель знает, что тесты должны проходить, может «срезать углы». Захардкодить что-то или даже удалить — лишь бы избежать «тест упал». В общем, буквально воплощает старый мем:

Мы встречали подобное в своей практике. Однажды при сочинении юнит-тестов для функции модель попросту использовала как «источник истины» саму реализацию, а не бизнес-логику. При этом в коде оказалась ошибка, вызванная погрешностью floating-point арифметики. И тесты просто закрепили это неправильное поведение: они проверяли не правильность, а повторяемость бага.

Заметив это, у нас в команде исправили ошибку и добавили property-based тесты, которые проверяют инварианты, а не конкретный результат. Но что делать, чтобы таких ситуаций и не возникало?

Задолго до ИИ-кодинга возник подход TDD: «Сначала писать тесты, а уже потом код, который они проверяют». Кент Бек и Роберт «Uncle Bob» Мартин пропагандируют его уже десятилетиями. А что, если применить его здесь, чтобы машина не могла перенести в тесты ошибку из реализации?

Использовать TDD с ИИ действительно стали — и многие нашли это очень полезным. Тот же «Дядюшка Боб» сейчас разбирается, как именно это эффективнее делать. А Саймон Уиллисон (создатель фреймворка Django) уточняет, что полезен «красно-зелёный TDD» — то есть стоит не просто «сначала написать все тесты», а действовать по такому циклу:

  • Новый тест сначала должен падать (иначе что он проверяет?)

  • Затем требуется сделать минимальное изменение кода, чтобы тест начал проходить.

  • А дальше надо рефакторить, превращая код из «просто срабатывающего» в «полноценный».

Это может ощущаться нудным: «Мне надо сначала писать “плохой код” без рефакторинга? А можно сразу хороший напишу?» Но хорошая новость в том, что у ИИ-модели нет ощущения «нудно», и она в целом понимает «use Red/Green TDD», так что возможно привлекать здесь её.

Наш опыт показал, что с reward hacking возможно столкнуться даже при TDD, но от этого возможно защититься.

История выглядела так: сначала написали тесты, один из которых явно задавал правило «неделя начинается в понедельник». После этого попросили AI реализовать функцию next_business_weekday(start_date). Один тест не прошёл: реализация исходила из предположения, что неделя начинается с воскресенья. И тогда вместо того, чтобы исправить код и привести его в соответствие с нашей спецификацией, ИИ взял… и тихо изменил сам тест, чтобы он соответствовал поведению кода.

После этого в команде решили изменить процесс. ИИ больше не может в подобной ситуации менять тесты (если считает это необходимым, то должен объяснить причину). А на случай, если это всё-таки произойдёт, добавили в CI хук, который попросту блокирует PR с такими изменениями.

В общем, использование TDD помогает, но и при нём нельзя «отключать голову». Модель охотно напишет какие-то тесты до кода, но точно ли правильные? Контроль остаётся за человеком.

SDD

Бывают эффектные демонстрации вайбкодинга: «Просто скажите “сделай тетрис”, и у вас готовая игра!» И новичкам может казаться, что теперь всё так и делается.

Но на Хабре всем ясно, что если в серьёзном проекте сказать просто «сделай фронтенд», то какой-то фронтенд ИИ может сделать… однако вряд ли тот, который нужен.

Машина делает «что ты сказал», а не «что ты хотел». Она не умеет читать мысли и может додумывать «недосказанное» как угодно.

Забавно, что нагляднее всего это передаёт «Энциклопедия профессора Фортрана», опубликованная ещё в 1991-м. В оригинале речь шла об обычных детерминированных алгоритмах, но и к промптингу ИИ это метко подходит:

Получается, чтобы добиться именно «чего хотел», необходимо и самому-то это как следует понять, и хорошо изложить. Декомпозировать масштабное на части, описать их все подробно, точно, недвусмысленно. Хмм, кажется, что-то подобное было и до ИИ…

Да, тут вспоминаются слова вроде «спецификация», «документация», «требования». И они становятся важнее прежнего:

  • Раньше многие знания распространялись «в курилках», а не в файлах. Но LLM не курят. Если знание о проекте не зафиксировано письменно хоть в каком-то формате, для модели его не существует.

  • В каждом новом диалоге модель «забывает» всё из предыдущего. Нужно уметь быстро вводить её в курс дела. И тут помогают уже готовые тексты.

В итоге популяризовалось целое понятие «Spec-Driven Development» (SDD), где спецификации ставят во главу угла. GitHub создал инструмент Spec Kit, также есть OpenSpec (первый более «энтерпрайзный», второй более «лёгкий»). На сайте Мартина Фаулера это явление разбирали ещё в октябре. А на Хабре с тех пор тоже появился целый ряд постов, так что совсем в детали вдаваться не станем.

Кто-то при слове «спецификация» скажет: «Это что же, возвращаем “водопад”? Будем прописывать до посинения гигантский талмуд, чтобы не оставить двусмысленностей, и только потом кодить? Но ведь если писать заранее талмуд, потом на практике выясняется, что его весь надо переписывать. Мы это уже проходили».

Но на самом деле никто не призывает забыть идеи agile. Даже наоборот: ИИ как раз «аджайлный», он позволяет быстро проверять гипотезы на практике и подстраиваться на ходу. «Сделай тут тремя разными способами, а мы сравним результаты “вживую” и выберем».

Всё значимое требуется фиксировать, но это не значит «только заранее». Когда понимаешь что-то уже на практике — можно добавлять или в ту же спецификацию, или в логи решений, или как вам удобнее.

Записывать всё может ощущаться скучной бюрократией. Хорошая новость: машины не боятся бюрократии, так что ИИ можно привлекать к этому.

При этом, конечно, и здесь нельзя «отключать голову». Модель согласится хоть написать всю спецификацию за вас, но может и в ней понаписать глупостей. А отвечаете-то за результат вы, так что его надо контролировать.

Экономия контекста и токенов при чтениях

Когда используешь ИИ не для вайбкодинг-проекта из двух файлов, а применяешь к рабочему проекту с большой кодовой базой, сразу вылезает ряд сложностей. Одна из них — агент начинает читать много лишнего. Поначалу кажется логичным: чем больше файлов он посмотрит, тем лучше поймёт задачу. Но на практике зачастую наоборот: контекстное окно забивается, важные детали тонут в шуме, а расходы на токены растут. Что делать?

По нашему опыту, тут полезнее мыслить не в формате «пусть агент сам разберётся в проекте», а в формате «дать агенту ровно ту часть системы, которая нужна для конкретного изменения». Конкретные действия при этом могут быть разными:

1. Формулировать задачу узко

Запросы вроде «разберись, что здесь происходит» или «исправь модуль» расширяют зону чтения. Агент исследует всё подряд, потому что не понимает, где заканчивается задача. Куда лучше узкие формулировки: «измени только валидацию в этом методе», «работай в пределах этих двух файлов».

2. Делать структуру проекта понятной и предсказуемой

Вообще говоря, хорошая организация кодовой базы важна и без всякого ИИ. Предсказуемые названия файлов, понятное разделение по слоям, внятные README — это ведь и людям помогает. Но агенты тоже так быстрее находят нужную часть системы.

3. Давать агенту карту проекта и ограничения

Помимо «разложить всё по полочкам», можно напрямую давать агенту краткую карту этих «полочек»: где находится нужный модуль, что считается точкой входа, где лежит бизнес-логика, а где тесты или вспомогательные части. И можно сразу уточнять, какая часть карты актуальна для текущей задачи: какой модуль трогать, какие директории релевантны, а где не нужно ничего менять.

4. Фиксировать архитектурные правила отдельно

Если в проекте есть важные инварианты вроде «этот слой не ходит напрямую в БД», «этот модуль не импортирует этот пакет» или «новую логику добавляем только через такой паттерн», агенту лучше знать это заранее. Тогда ему не придётся каждый раз заново выводить эти правила из кода, просматривая дополнительные файлы.

5. Разделять поиск, понимание и изменение

При проблемах с «чтением лишнего» можно не просить агента сразу переписывать код. Можно сначала дать задачу поиска релевантных файлов и посмотреть, не «увело» ли его. Затем — задачу понимания: что именно в них отвечает за нужное поведение. И только потом — задачу изменения. Это частное применение универсального принципа: «Если агент плохо справляется с задачей — попробуй её декомпозировать».

Выбор стека: типизация и «стандартизация»

Программисты вечно спорят «какой язык/фреймворк/инструмент лучше». На Хабре сломаны миллионы копий. А теперь у вопроса новый вариант: что лучше при работе с ИИ?

Возможно, даже возникнут новые языки: например, создатель Kotlin Андрей Бреслав сейчас работает над проектом CodeSpeak. Но пока посмотрим на привычные.

И здесь интересно получается с типизацией. Людям лень писать типы, и языки шли им навстречу: какие-то использовали динамическую типизацию, какие-то при статической начинали выводить типы автоматически.

А вот ИИ-моделям писать типы не лень. Зато они часто ошибаются. И статическая типизация может поймать некоторые ошибки. Поэтому возникло популярное мнение «для ИИ лучше статическая», и языки вроде TypeScript сейчас на подъёме. Хотя вокруг многих ИИ-практик сейчас идут споры, и для этого тезиса тоже можно встретить возражения.

Другой фактор: для LLM «удобнее», когда что-то часто встречалось в обучающем датасете. Если на GitHub есть тысячи «Тетрисов» на JavaScript, то агенту будет легко сделать ещё один, и динамическая типизация не остановит. А хуже обстоят дела с малоизвестными вещами и с совсем новыми, вышедшими уже после даты «knowledge cutoff» ИИ-модели. Там вероятность ошибок выше.

Поэтому некоторое преимущество получает всё «стандартное» и популярное. Даже если это звучит «скучно».

Это не значит, что теперь «оригинальничать» нельзя. Можно, когда на то есть причина. Но по умолчанию вопросы полезно решать самым напрашивающимся путём, а другими — только когда понимаешь, ради чего.

В общем-то, и без ИИ было полезно заботиться так о коллегах. Сделать что-то нестандартным образом можно. Но надо думать о том, кому во всём этом разбираться, когда ты уволишься или в отпуск уйдёшь. Поэтому «делать странно» без повода не стоит.

Подход к Git

Известный в ИИ-сообществе разработчик Стив Йегге и известный в DevOps-мире Джин Ким написали вместе целую книгу «Vibe Coding». Вопреки названию, она не про «бездумный вайбкодинг», а наоборот, призывает подходить разумно и ответственно. И один из советов в книге — «коммитить как можно чаще».

Потому что это как «сохранения в видеоигре»: никогда не знаешь, когда ИИ вдруг пойдёт вразнос, и чем свежее последний коммит, тем меньше прогресса можешь потерять. А кроме того, если всё как следует описано в commit messages, ИИ в будущих диалогах сможет понимать по ним много полезного контекста.

Обычно люди не жаждут сочинять про все мелочи отдельные commit messages, когда другие задачи ждут. Хорошая новость: ИИ не лень этим заниматься, можно поручать это ему (и при необходимости немного править его commit messages вручную).

Однако книга приводит и такой пример, где Стив даже с ИИ-коммитами и удалённым бэкапом чуть не потерял много наработанного. Дело оказалось в следующем. ИИ-агент насоздавал много разных временных ветвей, возникла запутанная структура ветвления. Когда всё вроде как было сделано, Стив сказал удалить лишние ветви. А позже обнаружил, что код за целую неделю куда-то делся… Оказывается, ИИ не вмёрджил всё в main, как ожидалось. А на удалённый сервер отправлялся только main.

В том случае код удалось спасти. Но общий вывод такой: хотя Git помогает защититься от потерь, а ИИ не лень часто коммитить, нельзя бесконтрольно доверять ИИ работу с ним. Где-то надо внимательно следить «на каком мы сейчас бранче», где-то надёжнее руками вбить гит-комманду.

Ещё одну особенность работы с Git описывали и Илья Бирман, и Саймон Уиллисон: ИИ очень помогает со «сложными командами». Даже опытным разработчикам непросто целиком уместить в голове логику и команды Git. Теперь в запутанной ситуации можно либо отдать команду «человеческим языком», либо попросить «сначала объясни, какие у нас варианты, там решу».

Также про Git людям пришлось задуматься в таких ситуациях: если несколько ИИ-агентов одновременно вносят в проект изменения, как это правильнее организовать, чтобы они поменьше «сталкивались»? А если хочешь поручить одну фичу сразу нескольким ИИ-моделям и потом выбрать «кто лучше справился», как это правильнее устроить? А если хочется хранить с помощью Git не только код, но и промпты?

Сейчас человечество экспериментирует для этого с worktrees, бранчами, надстройками «поверх» Git. Пока нет единого «окончательного рецепта». Но стоит поглядывать, что с этим будет происходить — тут явно будут устаканиваться новые нормы.

Риск-менеджмент

В далёком 2001-м группа разработчиков уехала в горы и пообщалась, а вернулась оттуда с «манифестом Agile» о том, как надо подходить к разработке «по-аджайлному». В их числе был Мартин Фаулер из Thoughtworks.

А в этом году, спустя 25 лет, компания Thoughtworks снова вывезла группу айтишников на ритрит: обдумать, как теперь подходить «по-эйайному».

В этот раз вернулись без уверенного манифеста, но выпустили PDF с некоторыми размышлениями. Первый пункт там такой: «Инженерное качество с ИИ не исчезает, а перемещается из кода в спецификации, тесты, ограничения и риск-менеджмент». Про спецификации и тесты мы уже поговорили, а теперь про риск-менеджмент.

Идея вот в чём. Когда машины быстро генерируют много кода, человеческое ревью становится одновременно «важным местом» и «узким местом». От его тщательности зависят и качество проекта, и скорость разработки. И эти две вещи противоречат друг другу.

А при этом у разного кода очень разная цена ошибки. Одно дело — быстрый прототип, который позже попросту удалят. Совсем другое — медицинские системы, баг в которых может стоить кому-то жизни.

Если расслабишься и доверишься ИИ в критической системе, это чревато большими проблемами. Но если долго провозишься с проверкой чего-то эфемерного, это тоже проблема. Впустую потратишь время, которое нужнее для другого, включая ту же проверку критических систем.

Получается, недостаточно быть «въедливым компетентным специалистом». Надо ещё и уметь регулировать в себе степень въедливости. Не прибивать гвоздями один подход «проверяем любой код вот так», а работать гибко. Постоянно задумываться: «Какими будут последствия ошибки в этом коде?»

Перефразируя известную «Молитву о душевном покое», можно сказать, что при работе с ИИ-кодом требуются:

  • Компетенции и прилежность тщательно проверить всё, что требуется.

  • Душевный покой принимать без излишних проверок то, где они не требуются.

  • Мудрость отличать одно от другого.

Вот эту мудрость и называют «риск-менеджментом».

Понимание ИИ

Вот забавный пример. Как известно, многие LLM могли ошибаться при запросах формата «сколько букв “r” в слове “strawberry”». Но порой та же самая LLM выдавала правильный ответ, если добавить в промпт «use python».

Почему? LLM видят текст не символами, а токенами из нескольких символов, поэтому считать буквы им бывает сложновато. Зато они умеют писать на Python. А Python умеет считать буквы. И получается, при некоторых запросах к LLM полезно понимать, как действует токенизация — это может улучшить промпт и его результат.

ИИ манит людей «песней сирены»: «Просто вбей запрос понятным языком и не думай, дальше всё сделает магия». Но для профессионального применения ИИ стоит понимать хотя бы в целом, как эта «магия» реально работает.

Например, чтобы лучше справляться с тем, что называют «context management». При лёгком вайбкодинге об этом можно вообще не думать. Но когда используешь ИИ в масштабном проекте, можешь быстро столкнуться с тем, что мы уже упоминали в части про «много чтений»:

  • для верного выполнения задачи машине нужен весь релевантный контекст

  • при этом окно контекста не бесконечное, да и то в середине «проседает»

  • поэтому не стоит «закидывать в ИИ всё возможное», надо «не мусорить»

  • фича «compaction» может «сжимать имеющийся диалог до главного»

  • но модель сама выбирает «а что главное», и может упустить важное

И когда понимаешь это, можешь учитывать в своих действиях: если окно контекста уже заполняется, а при compaction что-то может потеряться, какие вещи точно надо перенести в продолжение сессии? Стоит ли прямо сейчас сохранить их в файл, чтобы потом можно было восстановить из него?

В интернете есть много обсуждений в духе «Agent Skills лучше MCP, потому что не загружаются в контекст сразу, а только по необходимости». Из таких реплик можно извлечь пользу, но не стоит впадать в карго-культы вроде «всегда используем только Agent Skills и всё станет идеально». Главное тут — не зубрить конкретные техники, а понимать в целом, что значит «не загружаются сразу» и чем это хорошо.

Помимо принципов работы самих LLM, полезно разобраться и в том, как именно модели из простых разговорных «чатботов» превращают в деятельных «агентов». Об этом есть много материалов — например, Аллен Хатчинсон из Google DeepMind написал целую серию постов «The Agentic Shift».

При этом суть идеи несложная, и минимальную агентскую систему можно даже написать самостоятельно, чтобы разобраться. Но использовать в работе стоит всё-таки «полноценную» чужую: поверх простой базовой идеи возникло уже много улучшений и нюансов.

Ну а в целом тему «как работает ИИ» можно по мере сил копать сколько угодно. Чем различаются модели? Как измеряют их эффективность? Какие формы обучения к ним сейчас применяют? Как работает кэширование токенов? Как устроен «режим планирования»? По любому из этих вопросов можно было бы написать отдельный хабрапост (сообщайте, если какой-то из них действительно хотели бы прочитать).

Понимание программирования

Все предыдущие пункты — это полезно, но не главное.

Важнее помнить идею, которую Джоэл Спольски описал ещё в 2002-м:

Все абстракции «протекают».

ИИ манит новичков идеей абстрагироваться от кода вообще. И на простом уровне «сделай тетрис» это работает. Создавая иллюзию, что понимать про код уже ничего и не надо.

Но в сложном проекте всё это «протечёт». Вылезут проблемы на уровнях, скрытых за абстракцией. И окажется, что посреди ночи прод упал, а никто уже не понимает, почему. Так что, если хочется делать масштабные вещи, необходимость понимать «уровни ниже» совершенно не исчезла. Наоборот, к ним добавился ещё один.

Мы в Kodik при ревью ИИ-кода сами сталкивались с ситуацией, когда AI предложил «удобное» упрощение в критичном участке (где важна идемпотентность/проверки), и это могло дать прод-инцидент. Тогда поймали это на ревью, переписали логику и добавили регрессионный тест. Но очевидно, что мир ждёт много подобных случаев, где люди или вообще не сделают ревью, или не смогут во время него заметить проблему.

И главная-то идея получается простой: чтобы добиться от ИИ профессионального кода, надо самому быть профессионалом.

Но даже если человек опытный программист, а не излишне самоуверенный вайбкодер, для него тоже возникают новые вызовы. Например, если с ручного написания кода переключиться на сплошные ревью, не атрофируются ли со временем способности? И поэтому ещё один важный вопрос звучит так:

Как в новом мире не перестать понимать?

Здесь любопытен опыт Митчелла Хашимото. Зачастую он даёт ИИ-агенту задачу, которой тот может продолжительно заниматься в фоне — а сам тем временем садится писать код вручную для другой задачи, даже отключив агенту уведомления, чтобы не отвлекал. В результате и успевает больше прежнего, и хватку не теряет: «поручать код агенту» не означает автоматически «перестать писать код самому».

Не факт, что вам подойдёт воркфлоу Хашимото. Но вот более универсальная хорошая новость: ИИ полезен и для задач понимания тоже.

Ведь не обязательно говорить машине «разберись там сама». Можно наоборот: «я хочу разобраться сам, помоги вот так-то». Вы изучаете чужой репозиторий и застряли на непонятном месте? Можно показать репозиторий ИИ и позадавать вопросы — вполне возможно, разобраться вместе окажется проще.

Для подобного даже начали делать инструменты — вероятно, тут многое ещё изменится, поэтому пока что условный пример. Саймон Уиллисон создал маленький проект Showboat для создания текстовых пояснений/проверок к коду — «если запустить вот этот фрагмент, вывод получается вот таким». И этот инструмент сразу был задуман так, чтобы его можно было вручить ИИ-агенту вместе с каким-то непонятным кодом и попросить сделать «прохождение кода» с объяснениями.

Кто-то использует ИИ, чтобы отключить голову. Кто-то — чтобы включить её сильнее прежнего.

Обучение программированию

С текущим поколением разработчиков, у которого уже есть опыт, ещё ладно. А вот что будет со следующим, которому только предстоит учиться?

Как действовать, когда люди приходят в мир программирования, а там приложения уже «магически возникают», и разбираться с кодом нет мотивации?

И в случае с программированием, и вообще в целом как новым поколениям не превратиться в персонажей «ВАЛЛ-И», разучившихся понимать, что происходит вокруг?

Над этим сейчас думают многие. Например, Андрей Карпатый когда-то работал над первыми моделями GPT и возглавлял направление автопилота в Tesla, а затем ушёл заниматься собственным проектом Eureka Labs. В интервью он объяснял, что его как раз беспокоит перспектива «мира из “ВАЛЛ-И”». И что он хочет с помощью ИИ перепридумать процесс обучения.

Но Eureka Labs пока что не запущен, а всем остальным как-то уже нужно учить людей в новом мире. Как сделать, чтобы знание кода не пропало?

Первым рефлексом у многих может быть «отнять у учеников LLM, пока не научатся кодить нормально». Желание понятное, но обречённое. Этого джинна уже не запихнуть обратно. Логичнее научиться с ним обращаться.

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

Мы думаем над этим не первый день в рамках проекта Kodik Education. Взаимодействуем уже с целым рядом школ и вузов (их тоже очень интересует этот вопрос).

Наш подход ещё будет развиваться, но уже пришли к таким тезисам:

1. Главная проблема с LLM — они могут сразу давать правильный ответ, пропуская путь к нему. Значит, обучение должно быть выстроено так, чтобы не пропускать.

В новом мире задания не должны быть просто в формате «найди X». Они должны быть сосредоточены не на конечном X, а на том, как его искать и почему именно таким образом. Этому и надо учить, это и надо проверять.

Хорошая новость: ИИ могут здесь пригодиться, например, для помощи в проверках. Обычной детерминированной системой можно легко проверять «правильный ли X вписал ученик», но куда сложнее проверить «правильное ли объяснение он привёл». А LLM лучше подходят в подобных случаях. Конечно, при этом они не должны полностью заменять учителей — лишь дополнять как удобный инструмент.

2. ИИ может быть полезен в объяснении «обычного» программирования.

Да, у многих возникает соблазн никогда не думать «что там за объекты, стеки и хипы». И редактор кода, где возможно «просто ввести промпт», звучит как потворствующий этому.

Но процесс промптинга тоже может помогать разобраться в части «происходящего под капотом», например, если визуализировать происходящее. Что, если промптишь простую игру, но при её запуске сразу видишь «что сейчас происходит в памяти»? Насколько всё становится познавательнее?

Сейчас мы развиваем различные идеи, и позже расскажем подробнее о результатах. А если вы из сферы образования — можете связаться с нами и развивать вместе.

В заключение

С ИИ-кодингом у человечества появилась сложная штука, с помощью которой можно и натворить кучу ерунды, и сделать много крутого. И от всех нас зависит, сколько будет первого и сколько второго.

Хочется менять баланс в сторону «крутого», поэтому написали этот пост. Но мы не мним себя единственными гуру с тайным знанием о том, как именно этого достичь. Здесь важен обмен опытом всего сообщества. Поэтому тут может быть очень полезен вклад от вас.

У вас есть конкретные практики, помогающие избегать проблем при ИИ-кодинге? Или общие мысли, что ещё можно делать, чтобы с ИИ человечество не растеряло программистское понимание? Пишите в комментариях.****