Transcription
Давайте немного поговорим о том, что я подразумеваю под "агентной инженерией". И, возможно, начнем с вопроса. Если бы я спросил вас прямо сейчас, как вы используете ИИ в своей работе? Смогли бы вы на самом деле это объяснить? Не просто, знаете, это помогает мне быстрее писать код. Он может писать код очень быстро, но как реальный рабочий процесс. Что вы передаете, что оставляете себе, как вы решаете между этим. Большинство инженеров не могут, и это меня немного поражает, потому что 90% инженеров уже используют инструменты ИИ или использовали их. Возможно, только половина из них использует их регулярно, но это число постоянно растет. И это текущее состояние. Итак, вопрос не в том, использует ли ваша команда ИИ, они используют. Вопрос в том, получаете ли вы от этого максимум пользы или вы просто как бы автодополняете свой день. Этот разрыв между использованием ИИ и способностью сформулировать, как вы с ним работаете, — вот о чем этот разговор. И действительно, я думаю, это представляет собой смену парадигмы в том, как мы думаем об ИИ. И знаете, история ИИ и программной инженерии развивается очень быстро. Она также удивительно коротка, верно? В начале 2020-х годов у нас появились инструменты, которые могли закончить строки за вас. Вы набираете, знаете, половину сигнатуры функции, и модель угадывает остальное. Знаете, вроде автодополнения на стероидах. Это классный трюк. А затем в 2022 году модели начали предлагать целые функции, верно? Вы могли описать, что хотите, и пообщаться с моделью, и, возможно, получить рабочую реализацию обратно. И вот здесь впервые появился GitHub Co-pilot, прорвался, и миллионы разработчиков начали его использовать. И впервые стало казаться, что, возможно, ИИ — это не новинка, возможно, он общеполезен. Но затем в 2025 году что-то действительно сломалось. Это то, в чем мы живем сейчас, в 2026 году. Модели не просто предлагают, они могут выполнять. Они могут взять задачу, разбить ее, выяснить, какие файлы нужно изменить, внести изменения, запустить тесты самостоятельно, а затем вернуться с реальным запросом на слияние. И это не просто модное автодополнение. Это не просто более быстрая лошадь. Это соавтор. Это другой способ работы. И Армин, создатель Flask, для тех, кто здесь из Python-сообщества, сказал, я думаю, идеально. Мы больше не просто используем машины. Мы теперь работаем с ними. И, я думаю, эта формулировка отражает этот реальный сдвиг. Верно? Инструменты — это то, что вы берете и кладете. Вы используете молоток. Вы не работаете с молотком. Но ИИ-агенты для кодирования, которые у нас есть сегодня, они как бы где-то посередине, и они, возможно, больше похожи на работу с другим инженером. Теперь просто так получилось, что это инженер, который прочитал каждый ответ Stack Overflow, когда-либо написанный. И я думаю, что это требует смены ментальной модели. И это та ментальная модель, которую я хочу, чтобы вы пронесли через остальную часть этого видео и, честно говоря, через оставшиеся несколько лет вашей карьеры в работе с этими инструментами. Я действительно думаю, что это все еще инструменты, но мы должны думать о них по-другому. Вы должны думать о своем ИИ-агенте как об энергичном, восторженном, чрезвычайно начитанном, часто уверенно ошибающемся младшем разработчике. Этот младший разработчик невероятно быстр. Он не устает легко. У него нет никакого эго по поводу своего кода. Он с радостью перепишет что-то шесть раз, если вы попросите. И у него поразительная широта знаний. Он видел много языков. Он видел много фреймворков. Он видел много паттернов. Но, и это критически важно, у него нет суждения. Он не знает контекста вашего бизнеса. Он не понимает причин, по которым вы приняли это очень конкретное архитектурное решение 3 месяца назад. И он будет уверенно писать код, который технически правильный, но контекстуально неправильный. Арман также сказал, что он сэкономил более 30% своего времени в день, потому что машина выполняет большую часть работы. Это реальная выгода. Но он получает эти 30%, потому что знает, что он может передать, а что должен оставить себе. Он не просто слепо принимает каждое предложение. Он руководит работой. И в этом разница между использованием ИИ и работой с ИИ. И именно это на самом деле означает агентная инженерия. Итак, давайте перейдем к тактике. Если вы инженер, как нам действительно стать в этом хорошими? Я думаю, первое, о чем стоит подумать, — это контекстная инженерия. И здесь Карпати говорит, знаете, контекстная инженерия — это тонкое искусство и наука, знаете, заполнения контекстного окна именно тем, что нужно, чтобы у агента был правильный контекст для правильной итерации для следующего шага. Я думаю, это действительно важно по нескольким причинам. Во-первых, контекст дорог, верно? Каждый токен, который вы добавляете в контекст, будет добавлять стоимость, потому что все эти вещи, вся история чата, отправляется обратно как входные токены каждый раз, когда вы ее отправляете. И это, знаете, может довольно быстро накопиться. И другое ключевое — это то, что больше контекста не всегда означает лучшие результаты. И на самом деле, это может сделать модель глупее. Верно? Дело не только в деньгах. Качество может ухудшаться, когда вы достигаете более 50% заполнения. И здесь есть много вещей, которые могут вас загнать в ловушку. И не в последнюю очередь, знаете ли, тот факт, что серверы MCP стали настолько популярны, что у нас сейчас много из них включено постоянно. Ну, каждый из них загружает все больше и больше контекста. Больше и больше входных токенов кода в контекст. И это может быть реальной проблемой, если вы начинаете попадать в эту "глупую зону" около 50% контекста. И это тоже не единственная проблема, потому что не только больше контекста может быть проблемой, но и плохой контекст может быть проблемой и может все испортить. Верно? Это происходит, когда вы, возможно, смешиваете две разные задачи, которые на самом деле не пересекались. Или у вас есть устаревшие комментарии либо в коде, либо сделанные агенту. Или, что еще хуже, я видел, как многие люди делают: они начинают идти по пути с агентом, а затем понимают: "Эй, мы идем по неправильному пути. Мы приняли много неправильных решений." И они пытаются вернуть агента. Но проблема снова в том, что агент не рассуждает по-настоящему, как вы и я, как люди. Верно? Он каждый раз берет весь этот контекст. И он может потеряться посередине или даже увидеть некоторые из этих негативных вещей, которые были раньше, как все еще часть контекста. И вы видите, как эти негативные паттерны снова проникают, если вы не будете осторожны. Вот почему лучше, знаете ли, не давать этим вещам накапливаться. Но также, знаете ли, всегда начинайте новую сессию, как только вы поймете, что все идет не так. Верно? Потому что не только контекст дорог, большее его количество не всегда означает лучшее качество. На самом деле, в определенный момент есть переломный момент, когда это означает худшее качество. И плохой контекст может испортить вывод. Итак, самое важное для инженеров — это управлять контекстом. И что это значит? Ну, во-первых, я думаю, это означает сохранение большого количества информации вне контекстного окна, чтобы мы могли ее использовать, верно? Итак, это такие вещи, как черновики для того, над чем мы работаем, файлы памяти, agents.md, такие файлы, которые помогают агентам иметь контекст того, над чем вы работаете. Нам также нужно быть очень избирательными при выборе этого контекста. Итак, это означает, что мы должны включать только то, что актуально для этого этапа проблемы, верно? Не просто включайте все, что может быть полезно. И это может означать, знаете ли, такие вещи, как включение правильных упоминаний файлов, на которые мы ссылаемся. Это может означать, что мы убедимся, что у нас не включены ненужные серверы MCP. И это означает, знаете ли, что агент имеет правильные данные, и мы, как люди, курировали эти данные для агента. А затем, по мере того как он становится больше, и это окно становится больше, мы хотим обобщать, обрезать и сжимать этот контекст, верно? Если мы прошли через полное глубокое погружение и сеанс отладки с агентом, и теперь мы думаем, что у нас есть проблема и решение, ну, это здорово. Возможно, пришло время сжать этот контекст и просто сосредоточить агента обратно на: "Хорошо, теперь мы понимаем эту проблему. Мы собираемся ее исправить." А затем самое важное — это изолировать контекст. И я думаю, именно поэтому мы видели этот огромный рост за последние шесть или восемь месяцев параллельных агентов, потому что разделение работы между несколькими агентами или несколькими сессиями может помочь вещам не накапливаться. И действительно стимулировать это разделение задач. И снова, если вы подумаете об этом, разве это не все те же вещи, которые я бы сказал новому менеджеру по инженерии о работе с младшим инженером? Как история, которую я рассказываю здесь: когда я был в начале своей карьеры, я много времени провел в качестве менеджера по инженерии и менеджера по продуктам, прежде чем перейти к темным искусствам связей с разработчиками. И на моей первой работе в качестве менеджера по инженерии я работал в компании, занимающейся медицинским программным обеспечением. И появилась новая вещь под названием iPad. И это немного выдает мой возраст. Но он был выпущен на рынок, и мы подумали, что это может быть отличное место для сбора истории болезни, знаете, той формы, которую вы должны заполнять каждый год у врача. Это очень важно для оценки многих ваших рисков заболеваний. Но заполнять ее каждый раз с нуля — это не весело. И поэтому я разработал другой архаичный инструмент, о котором некоторые люди, возможно, слышали, называемый Balsamiq, по сути, инструмент для создания каркасов, каркас того, как это будет выглядеть. Теперь этот инструмент для создания каркасов использовал такие вещи, как Comic Sans и глупые иконки смайликов в качестве заполнителей. И много других подобных вещей, которые вы ожидаете от простого каркаса. И я передал это группе стажеров, которые работали у нас этим летом, думая, что это отличный проект с чистого листа, над которым они могут поработать. И вот, через несколько недель я получил рабочий прототип, и шрифт был Comic Sans, и были глупые эмодзи-заполнители. И это потому, что именно это было в спецификации. И чья это вина? Очевидно, это не вина стажеров. Это была моя вина как менеджера по инженерии, который не предоставил правильный контекст этим младшим инженерам относительно того, что важно, что нет, на чем нам действительно нужно сосредоточиться и какую проблему мы решаем. И поэтому я думаю, что привычки, которые могут связать все это вместе, это то, что вам не нужно думать обо всех четырех вещах для каждой задачи, вам просто нужно думать о выполнении одной задачи за сессию, следить за своим счетчиком контекста, и если вы сомневаетесь и чувствуете, что все идет не так, вы, вероятно, правы. Так что начните новую сессию, попросите ее обобщить сессию для нового агента. Оказывается, ИИ действительно хорош в написании промптов для ИИ. Так что, если вы долго работали над чем-то с агентом, попросите этого агента обобщить, где вы находитесь, вы можете теперь прочитать это, убедиться, что это соответствует вашему пониманию, а затем начать новую сессию только с этим правильным контекстом. Опять же, это немного искусство и немного наука. Так как же нам применить это на практике? Ну, я думаю, есть много рабочих процессов, есть много написанных материалов, которые вы можете прочитать. Я даже собрал много из них на path.kilo.ai. Там вы можете найти все эти тенденции, идеи и шаблоны рабочих процессов, о которых говорили. Но я думаю, что я постоянно возвращаюсь к, возможно, одному из самых простых, и это цикл "исследование — план — реализация". Верно? И я думаю, что это действительно помогает нам решить многие классические ошибки, которые люди совершают, когда впервые берутся за агентную инженерию или используют ИИ для помощи в инженерии. И то, что делают большинство людей, это говорят: "Эй, помоги мне реализовать эту функцию. Я хочу, чтобы она делала X и Y." И, знаете ли, эти большие языковые модели очень хороши в выводе большого количества кода. На самом деле, когда я присоединился к Kilo Code более года назад, я сделал заявление, что наш веб-сайт никогда не будет просто промптом и кучей пролетающего кода. Это отлично подходит для демонстрации, и вы видели множество кодирующих агентов, которые, возможно, показывают это так. Но я думаю, что реальность такова, что прыжок прямо в код таким образом может привести к множеству неверных предположений, он может потратить еще больше времени, а не сэкономить время, и просто создать много разочарований. И это действительно создает ту парадигму, которую мы видели, когда люди как бы анти-ИИ или думают, что ИИ — это не полезный инструмент, потому что они прыгнули прямо в него и получили, знаете ли, ввели мусор и получили мусор. Или, возможно, прошло много времени с тех пор, как они им пользовались, верно? Я имею в виду, если вы подумаете о видео с Уиллом Смитом, поедающим спагетти, когда дело доходит до ИИ, это прошло долгий путь всего за последние два, три, четыре года. Знаете, то же самое верно и для ИИ-моделей кодирования, но вы должны делать то, что работает, чтобы дать им наилучший шанс получить отличный результат. И это, во-первых, очень хорошо понять проблему и убедиться, что вы и ИИ-агент очень хорошо понимаете проблему. Затем наметить явные шаги для реализации этих изменений или исправления этой проблемы. И только тогда мы переходим к фазе реализации, где мы пишем код. И Декс Хорти имеет отличную фразу, которую он говорит здесь: "плохая линия исследования может потенциально привести к сотням строк плохого кода". И поэтому мы действительно сосредоточимся на том, как мы можем получить исследование и план, чтобы дать себе наилучший шанс получить отличный код. Итак, на первом этапе мы будем использовать инструмент, который будет сосредоточен только на исследованиях. И поэтому для Kilo мы называем это "режим запроса". И причина, по которой мы так его называем, заключается в том, что режим запроса на самом деле ничего не может сделать. Он может только общаться. Он не может писать файлы. Он может, возможно, читать файлы, если вы позволите ему, но он не может, знаете ли, начать пытаться кодировать решение. И поэтому вместо того, чтобы пытаться кодировать решение с самого начала, мы сначала попытаемся понять систему. Знаете, как она на самом деле работает сегодня? Где находятся правильные файлы, которые будут задействованы? Какие правильные парадигмы мы хотим отразить, или как это отличается от чего-то, что у нас уже есть? И, знаете ли, просто узнайте, где в кодовой базе это будет происходить, и знаете ли, как данные будут проходить через систему и как она изменится с нашим изменением, а также какие крайние случаи нам нужно учитывать, верно? ИИ действительно хорош в мозговом штурме, и поэтому он может помочь вам в этом и убедиться, что вы действительно охватили все свои базы. А затем, как только вы закончите это исследование, результатом будет фактический выходной документ, который показывает детали этого исследования, который вы затем можете прочитать и, по сути, согласиться и понять: "Эй, это соответствует моему пониманию проблемы. Я думаю, мы готовы перейти к плану." И поэтому, как только мы просмотрели это как люди, теперь мы можем сказать: "Хорошо, давайте наметим следующие шаги. Какие, знаете ли, файлы мы собираемся создать или изменить? Возможно, есть некоторые фрагменты кода, но не всегда хорошая идея иметь фрагмент кода в плане. Мы определенно включим, как мы будем проверять и знать, что это изменение правильно? Какие тесты, либо изменения, либо дополнения, мы собираемся сделать, чтобы это узнать? И мы также будем очень явными на этапе планирования о том, что входит и что выходит из области действия, что изменится, а что не изменится. И снова, результатом будет очень четкий файл плана, верно? Вы увидите, что многие репозитории сегодня имеют папку под названием "планы". И мы хотим, чтобы этот файл плана содержал пошаговые инструкции с конкретными изменениями, которые мы собираемся внести, с командами для проверки, со стратегией понимания того, как это изменит систему. И это будет очень ясно, чтобы мы могли даже использовать, возможно, меньшую, более быструю или более дешевую модель для ее реализации, потому что мы потратили время на этапах исследования и планирования, чтобы действительно понять, что мы будем делать, когда перейдем к реализации изменения. И когда мы перейдем к реализации изменения, мы теперь можем начать новую сессию и дать ей только выполнение плана. Это позволяет нам поддерживать контекст в этой сессии на очень низком уровне. Это позволяет нам тщательно просматривать каждое изменение и, я думаю, часто фиксировать. Теперь я много лет работал в компании под названием GitLab. Так что, возможно, я немного предвзят к Git, но я думаю, что Git может быть огромной помощью здесь, когда дело доходит до того, чтобы помочь вам медленно итерировать и понимать изменения, которые вносят агенты. Я отношусь к Git на своей локальной машине как к своему собственному первому обзору запроса на слияние с моими агентами, прежде чем, возможно, выставить реальный запрос на слияние для моих коллег. Но я думаю, опять же, критически важно понять здесь, что человеческое исследование на этапе планирования или, простите, человеческое время на этапах планирования и исследования — это действительно самое высокоэффективное использование вашего времени. К тому времени, когда вы реализуете, вы хотите, чтобы все это тяжелое мышление было сделано. И это действительно критично, потому что, опять же, возвращаясь к Дексу Хорти, который много говорил на эту тему, и я очень рекомендую вам посмотреть его видео на YouTube, где он говорит об этом. Он очень метко говорит, что ИИ не может заменить мышление. Он может только усилить мышление, которое вы сделали, или отсутствие мышления, которое вы не сделали, или, знаете ли, тот факт, что вы не продумали это. Итак, давайте поговорим о том, как мы можем настроить наших агентов, как бы на один шаг ниже этой парадигмы "исследование — план — реализация", чтобы действительно убедиться, что мы делаем это. Во-первых, мы говорили о режимах и настройках. Мы уже говорили об этих режимах: запрос, код, архитектор. Эти режимы, которые специализированы и сосредоточены на том, что мы пытаемся сделать. Архитектор, возможно, для планирования. Режим запроса — для исследований. Режим кода — для фактической реализации. Затем мы также хотим иметь набор правил, которые имеют смысл для нашего рабочего пространства. Для репозитория, в котором мы находимся. Или, возможно, глобально на нашей машине, чтобы мы понимали, что у нас есть определенный набор правил, которым мы всегда хотим следовать. И агенты довольно хорошо загружают и понимают эти правила. Но мы должны записать их, чтобы они имели их в своем контексте. И поэтому я думаю, что многие из поведений агентов — это то, что мы хотим настраивать по мере обучения. Хотим ли мы использовать несколько агентов одновременно? Хотим ли мы, чтобы эти агенты использовали рабочие деревья, чтобы мы могли затем снова объединить их в наш локальный репозиторий локально, прежде чем фиксировать их в запросе на слияние? Насколько мы хотим автоматически одобрять? Итак, большинство агентов имеют возможность настраивать, какие вещи они могут делать самостоятельно. Какие инструменты они могут использовать самостоятельно? Могут ли они читать файлы? Могут ли они читать файлы внутри или вне рабочего пространства? Могут ли они запускать тесты? Знаете, что агент может делать автономно без вашего вмешательства, а что вы должны одобрить? Да, я думаю, это то, с чем вам нужно быть комфортным в начале, а затем вам также нужно быть комфортным с изменениями по мере того, как вы учитесь использовать эти инструменты. А затем, я думаю, хорошая ментальная модель для этой конфигурации агента — это, возможно, три отдельных блока. Мы говорили о режимах. Это та ролевая конфигурация, поведение агента, которое мы хотим. Но есть еще две действительно ключевые вещи: agents.md и skills.md, о которых вы услышите. И в чем разница между ними? Ну, agents.md сейчас быстро становится де-факто стандартом для всех агентов, как их readme, для всегда включенных правил и деталей о проекте. Поэтому я думаю, что критически важно, чтобы ваш проект имел agents.md с минимальным объемом информации, который нужен агенту, чтобы знать, какие у нас есть соглашения, какие команды мы используем для его сборки или тестирования, и какие требования к тестированию или требования, которые мы должны проверить перед фиксацией. А затем навыки — это скорее конкретный рабочий процесс. Это многоразовые, так сказать, плейбуки для агентов. Так что, если есть что-то, что вы делаете часто, вы часто создаете моушн-графику, или вы, знаете ли, выполняете какую-то ежедневную или еженедельную или ежемесячную компиляцию журнала изменений, такие вещи отлично подходят для того, чтобы включить их как навыки, которые агент затем может использовать, когда ему это нужно для выполнения этих конкретных видов рабочих процессов. И поэтому обычно они по запросу, и вы говорите: "Эй, давайте используем этот навык для этой задачи." В отличие от агентов, которые почти всегда загружаются в контекст агента, поэтому он знает, что происходит. А затем, конечно, я работаю в Kilocode, и поэтому у меня есть несколько советов для продвинутых пользователей, но я думаю, что многие из них применимы независимо от того, какой агент вы используете, но я думаю, что они критически важны, когда вы осваиваетесь с этими первыми парадигмами. Как мне теперь настроить это и заставить это работать для меня? И одно из них — это упоминание для контекста. Так, упоминание файлов или коммитов или, знаете ли, вывода из терминала. Такие вещи и быстрое их включение в контекст очень полезны. Использование команд слэш для таких вещей, как начало новой задачи, когда нам это нужно, или сжатие контекста, когда он становится слишком полным. Такие быстрые команды могут помочь нам двигаться намного быстрее. Мы также можем, если мы работаем в VS Code с Kilocode, выбрать раздел кода, щелкнуть правой кнопкой мыши и сказать "добавить в Kilocode", и тогда этот контекст будет включен прямо туда, и я смогу затем говорить или задавать вопросы об этом коде, или просить агента изменить определенную часть этого кода. А затем, конечно, у нас также есть автодополнение, которое, я думаю, по-прежнему полезно, особенно потому, что у нас оно есть не только в коде, но и при составлении промптов. А затем, за пределами IDE, я думаю, мы также видим, что в этом году происходит сдвиг в том, где еще я хочу иметь возможность использовать это. В CLI, с моего мобильного телефона, в облачном агенте, непосредственно в Slack. Возможность использовать этих агентов везде, где вы находитесь, — это то, что становится все более ожидаемым от всех и от всех агентов. И я думаю, что это хорошо. Я думаю, это означает, что мы начинаем учиться, как мы можем использовать этих агентов снова больше как соавтора, который находится везде, где нам нужно быть. И еще одна вещь, о которой я хочу поговорить, — это получение других контекстных вещей. Прежде всего, протокол контекста модели, верно? Контекст прямо в названии. Идея этого заключается в том, что, в принципе, эти модели изначально могут только получать входные токены и создавать выходные токены, верно? И медленно, но верно мы даем им возможность использовать инструменты, где они могут, знаете ли, делать вызовы инструментов и влиять на вещи в окружающей среде, такие как запуск тестов. MCP, концепция MCP, по сути, расширяет это, говоря: "Эй, я хочу дать другие инструменты." Например, GitHub MCP дает агенту много инструментов для взаимодействия с API GitHub, поиска запросов на слияние, поиска комментариев, поиска проблем и понимания гораздо большего о вашей среде GitHub, верно? Или контекст семь помогает ему искать актуальную документацию по фреймворкам, потому что, как вы знаете, у LLM есть дата отсечки, где их знания заканчиваются, а затем все, что улучшилось с тех пор, они не знают. Так что эти серверы MCP могут быть очень полезны, и их тысячи. Но беспокойство заключается в том, что каждый из них добавит как минимум некоторую информацию, верно? Детали об этих инструментах, которые он имеет, в системный промпт, который отправляется каждый раз, когда вы взаимодействуете с агентом. И поэтому вы хотите убедиться, что если вы на самом деле не используете это, отключите это, верно? Допустим, у меня есть Postgres MCP, который подключается к моей базе данных, и я выполняю много фронтенд-работы, которая вообще не связана с базой данных. Ну, этот Postgres MCP будет просто пустой тратой токенов, и, возможно, даже хуже, токенов, которые помогают, знаете ли, как бы запутать агента и не понять, что он не должен сейчас трогать базу данных. Так что мы хотим быть очень осторожными, чтобы не злоупотреблять MCP. И еще одна вещь, которую мы часто слышим от предприятий: как мы работаем с внутренними API платформы? И я думаю, что есть четыре разных способа сделать это. Во-первых, если для этого уже есть спецификация OpenAI OpenAPI или спецификация Swagger, используйте ее. Если нет, то преобразуйте ее в markdown, чтобы вы могли сохранить этот markdown, знаете ли, в agents.md или где-то еще в репозитории для ссылки. А если это что-то, что меняется немного чаще, возможно, вам понадобится ссылка на URL, которую вы можете получить и попросить агента получать каждый раз, чтобы видеть последнее и самое лучшее. А затем мы видели некоторых клиентов, которые, знаете ли, имеют сложные многоэтапные, многосистемные рабочие процессы, где создание собственного сервера MCP может быть правильным выбором. Но, знаете ли, так или иначе, я думаю, что главное — это при работе с Kilo или любым из этих агентов, знаете ли, изолировать свою работу от работы агента, а затем просматривать работу агента как запрос на слияние, верно? Это помогает вам понять, знаете ли, как я могу лучше всего просмотреть код, точно так же, как я бы просмотрел код младшего инженера. И это, собственно, презентация, которую я имею по Kilo. У нас есть несколько захватывающих новых функций, у нас есть расширение по всем этим поверхностям. У нас также есть большой фокус на Openclaw и Kiloclaw и создании очень безопасного способа использования агентов Openclaw. И поэтому, если вы еще не ознакомились с Kilo, я просто немного рекламирую в конце: посетите kilo.ai, и мы будем рады получить ваш отзыв о том, что мы создаем. И, знаете ли, просто чтобы дать вам, знаете ли, куда мы идем дальше? Опять же, я думаю, вам придется выбрать инструмент и получить много практики. Мы говорили ранее, что это частично искусство и частично наука, и я думаю, что это просто означает, что вам нужно много практики, чтобы получить ощущение того, чему я могу доверять моделям, а чему нет. А затем попробуйте этот цикл "исследование — план — реализация — обратная связь". Посмотрите, как это работает для вас. И я думаю, возможно, вы окажетесь такими же, как некоторые из этих других старших инженеров, которые сказали: "Слушайте, я получаю больше удовольствия от программирования сейчас, чем за многие-многие годы." Поскольку мы, знаете ли, передаем часть этой утомительной работы ИИ-агентам и позволяем нашим мозгам работать над более сложными инженерными задачами. Спасибо.