Человек не сможет открыть новые океаны, пока не наберётся смелости потерять из виду берег
Андре Жид
Меня зовут Александр Гирев, я тимлид в мобильном приложении WB Partners. Изначально я хотел поделиться опытом написания unit-тестов с помощью ИИ. Но по мере написания статьи она превратилась в целую историю изменения взглядов на использование нейросетей. И как отсутствие энтузиазма и в какой-то степени отрицание сменились, если не оптимизмом, то увлечённостью и любопытством.
Все задачи будут рассматриваться применительно к проекту под Android и с использованием локальной LLM или модели в контуре компании.
Те читатели, кому интересны практические детали, а не рефлексия и история автора, могут начать читать с соответствующей части статьи.
Статья не является туториалом или исчерпывающим руководством, в ней намеренно опущены некоторые технические детали и объяснение терминов. Вместо этого в ней вы найдёте ссылки на источники, в которых сможете найти необходимую информацию, если вдруг что-то окажется незнакомым.
Может случиться так, что к моменту прочтения статьи часть информации или ссылки безвозвратно устареют и будут признаны орудиями труда первобытного программиста. Таков этот ваш ИИ, всё меняется слишком быстро.
Вдох. Выдох. Начинаем.
Пролог
Как и у многих, моё знакомство с генеративным ИИ произошло в 2023 году. Первые сеансы общения с чатом GPT казались магией, словно джинн наконец-то покинул бутылку и навсегда поселился в цифровом пространстве. Любопытство и восторг сменились страхом: а вдруг эта штука в какой-нибудь прекрасный день займёт моё место?
Но бояться было некогда. Нужно было закрывать задачи, исправлять баги, изучать новые технологии. Чат с цифровым джинном был очень эффективным помощником, ускоряющим поиск информации. Несмотря на то, что ответы были не всегда точны, а предложенный код часто не компилировался и состоял из функций вымышленных библиотек. Быть может, в стране джиннов распространяется другая версия Kotlin.
В то время использованию нейросетей в работе сопутствовало лёгкое чувство стыда. Зачем мне просить что-то сделать у чата, неужели я не могу справиться с задачей сам? Торжество синдрома самозванца, которое не имело места в эпоху StackOverFlow. Хотя суть действий не поменялась, мы изучали и использовали код, который для нас написал кто-то другой.
В таком режиме я прожил до прошлой осени. Иногда что-то спрашивал у чата, когда заходил в тупик или просто чтобы ускорить поиск информации. К тому времени я даже успел немного поиграться с Cursor, но ощутимого вау-эффекта не достиг. Ведь как можно восхищаться цифровым джинном, который рисует розовых пони в UI не многим лучше меня?
Иногда меня всё же посещала тревога. Было чувство, будто вокруг происходит технологическая революция, а я сижу дома, пью чай с баранками и слушаю вальсы Шостаковича на патефоне. Когда смотрел доклады ребят про ИИ, казалось, что они познали какую-то истину, как приручить джинна, а мне этот секрет оставался неизвестен. Впрочем, в моём ближайшем окружении не было кого-то, кто превратился в пресловутого x10 программиста и начал пилить по 300000 фичей в наносекунду одной левой. А периодические посты на тему «пока мои ИИ-агенты пишут код, я изучаю язык эльфов» я списывал на маркетинг и хайп.
Глава 1. Я знаю, что ничего не знаю
Что же случилось прошлой осенью? Я познакомился с Алексеем Утеповым, Android-разработчиком из команды QazCode. Он выступал на конференции с докладом про ИИ-агентов. На их проекте во всю использовались чудеса от фирмы Anthropic. И настолько эффективно, что макеты из Фигмы лёгким движением руки самым волшебным образом перемещались в приложение. Точность работы ИИ вы можете оценить сами.
К слову, зал, где выступал Лёша, был забит, поэтому я вместе с другими неравнодушными уютно уместился на полу, чтобы впитать как можно больше магических знаний.
Конечно, оставались вопросы безопасности и конкретных метрик, которые и были заданы Лёше после доклада. Но ощущение, что ящик Пандоры безвозвратно открыт, стало полным и ясным.
Чуть позже масла в огонь подлил мой бывший руководитель и друг, которого мы с семьёй навещали в Грузии. Мы гуляли по вечернему Батуми, разговор зашёл про ИИ, я попытался отмахнуться от этих знаний, мол, справлюсь и без них. Но ведь ты же руководитель, заметил мой друг. Тебе нужно разбираться в сути вопроса. Что ИИ может и чего не может. Ведь не ровен час, и к тебе придут с вопросом, а сколько человек мы можем заменить фич мы сможем выпускать, если тоже выпустим ИИ-джинна из бутылки.
И вот я ясно ощутил себя в этой точке. Сидящим у патефона дома, пока вокруг происходят чудеса техники. Обнадёживало, что всё меняется слишком быстро, чтобы безвозвратно отстать от прогресса. Ведь те знания, которые люди рассказывали про ИИ всего год назад, уже в большей степени устарели. А ещё я подумал, что изучить Java и Kotlin вечерами и ночами после работы было тоже не самым простым испытанием. Значит, справлюсь и с цифровым джинном. Синдром самозванца перешёл в режим энергосбережения, а я начал погружаться в суть вопроса.
Глава 2. Истина где-то посередине
И вот я начал читать и смотреть всё, что мог считать подходящим к теме ИИ. Статьи на Хабре, доклады и туториалы. Новости. Исследования. Каналы и тематические чаты. Я искал ответы на свои вопросы. Насколько эффективен ИИ в реальных командах разработки? Что он может и чего не может? Правда ли, что все вокруг сейчас используют ИИ в работе? А главное, с чего мне нужно начать?
Оказалось, что истина находилась где-то рядом. Чаще всего авторами статей с одами ИИ были служители культа в лице тех, кто этот самый ИИ разрабатывает. Или имеет процент с продажи видеокарт или ИИ-курсов.
Совсем без программистов в разработке в реальной жизни обходиться можно было тоже до поры до времени. Точнее, до момента, когда MVP нужно было превращать в что-то, что действительно приносит деньги. Или хотя бы запускается без багов после презентации.
В коммерческой разработке были компании, которые использовали ИИ в работе. Но информация о «своей разработанной модели» чаще всего была описанием того, как кто-то форкнул опенсорсную модель и переименовал немного её обучил русскому языку. Реальные цифры подтвержденного прироста эффективности превращались из «99.8% кода пишется при помощи ИИ» в +10-20% к эффективности. Речь о проектах с уже существующей кодовой базой. Вот пример:
Что ж, новости были хорошими. За три недели импровизированного ИИ-интенсива я понял, что почти ничего не пропустил. Как сказал участник одного из круглых столов по теме ИИ, разница между джуном и сеньором в области использовании нейросетей составляет 3-4 месяца. Этого времени, со слов спикера, было достаточно, чтобы погрузиться в тему с головой и научиться делать что-то полезное. Время показало, что этот человек был прав.
Глава 3. Начинаю тереть лампу с джинном
Я продолжил погружение в тему ИИ. С общеразвивающей информации перешёл на более прикладную. Чтобы слова MCP-протокол, RAG, протокол Open AI, системный промпт, ИИ-агенты перестали быть для меня магическими заклинаниями и превратились в понятные рабочие термины. К слову, если для вас они всё ещё звучат магически, можно посмотреть это видео, в нём вы найдёте нужную базу.
Перевернул моё сознание момент, когда я при помощи Cursor написал чат-бота на Python. Сам язык я до этого видел только на картинках, на нём никогда не писал. Проверить результат работы модели мог только по итоговому результату. Код написанной программы был для меня чёрным ящиком: в общих чертах я мог понять, что написано, но исправить или продебажить — нет. Странное пугающее чувство, словно ты теряешь управление и контроль над автомобилем и вынужден довериться на малознакомому роботу-водителю.
В какой-то момент я понял, что настолько преисполнился в своём познании узнал достаточно, чтобы применить полученные знания в своей работе. Какой-нибудь скептически настроенный читатель может подумать: «И ты, Брут. Тоже перешёл на сторону машин». Возможно. С другой стороны, если этого не сделаю я, рано или поздно это сделает кто-то другой, кто сидит рядом. Теория игр в действии.
Глава 4. Выбор первого желания
И вот я сижу перед своим ноутбуком. В готовности и решимости совершить цифровую революцию в отдельно взятой команде. Я немного ограничен в выборе средств и способов. Корпоративная тайна, информационная безопасность и все дела.
Момент спорный, есть ли меры от реверс-инжениринга в эпоху ИИ. Но в нашей компании правила игры были определены, я решил их принять. Поэтому в работе над задачей использовал инструменты, которые живут локально на моей машине или на серверах компании.
Вопрос, какой конкретно моделью я пользовался, видится мне не сильно существенным, поскольку не особо влияет на последовательность и сущность описанных далее шагов. Кроме того, новые релизы моделей происходят чуть ли не каждую неделю, привязка статьи к конкретной модели может не выдержать испытание временем. Поэтому деталь, из какого племени был мой цифровой джинн, я опущу. Очевидно лишь, что он прибыл с Востока.
Вернёмся к сути вопроса и конкретизируем задачу. Мне предстояло выбрать инструмент, через который я могу общаться с локальной или корпоративной LLM. Т.е. подключить свою модель через протокол OpenAI.
Вот какие варианты я пробовал и рассматривал:
Плагин Continue. Удобное расширение для IDE, джинна можно поселить прямо в Android Studio. Настройка не требует больших усилий, можно настроить автокомплит. Но добиться устойчивой работы модели через этот плагин у меня не получилось. Судя по оценке Continue в маркете плагинов, не у одного меня. Под устойчивостью здесь я подразумеваю запуск объёмной задачи и автономную работу модели в течение 5 минут и более.
Встроенный агент Android Studio. Такое благо от «корпорации добра» вышло в релиз в начале 2026 года. Я возлагал на этот релиз большие надежды. Ведь казалось классным иметь, так сказать, родное, нативное для Android-разработчика решение. Здесь тоже были проблемы с устойчивостью работы модели, хотя местами результат был получше, чем у Continue. Я решил, что Google тестировали своего агента при использовании Gemini, поэтому в моей ситуации могли всплыть какие-то неучтённые моменты.
Cursor. Для тех, кто не знаком с этим чудом технологий, Cursor представляет собой форк VS Code с
о своим блэкджекомполной интеграцией ИИ в процесс разработки. Мне он показался не очень удобным именно для разработки под Android, потому что изначально VS Code не задумывалась как IDE для Android-разработчиков. Я имею в виду инструменты для сборки и запуска приложения, отладки и прочие прелести. Главный минус Cursor в моём случае — несмотря на возможность подключения своей модели, проект индексируется и отправляется на сервера Cursor, где и происходит вся магия производительности. Привет от отдела ИБ и пока, Cursor, двигаемся дальше. Но справедливости ради, при работе над pet-проектами и примерами кода для докладов Cursor был очень даже. К слову, это единственный платный ИИ-продукт, на который у меня оформлена подписка.RooCode, ClioCode и другие расширения для VS Code. Слышал много хороших отзывов, но так и не попробовал эти решения в деле. Быть может, из-за того, что натерпелся неудобств с Cursor.
Claude Code. Наверное, это вариант для настоящих джедаев в мире программирования, кто чувствует себя в терминале как рыба в воде. Поскольку главным интерфейсом в работе с Claude Code является консоль. Поначалу я отнёсся к такому варианту со скепсисом, мои навыки работы в терминале нельзя назвать выдающимися. Но потом втянулся, всё оказалось очень нативно и удобно. Пожалуй, в моём окружении количество лестных отзывов о Claude Code может посоперничать разве что с Codex. Поверю и тем, и другим на слово, поскольку в итоге Claude Code я себе так и не установил. Решил не делать лишних приседаний, чтобы настроить адаптер между протоколами Open AI и Anthropic. Ну и вроде как были нюансы с установкой этого чуда в Беларуси и РФ.
OpenCode. Про него я узнал на Mobius от ребят из VK RuStore. По сути это опенсорсный аналог Claude Code. У них даже схожие интерфейсы. Разницу в производительности между ними я не измерял, но в целом все возможности настройки модели через агентов и скиллы в OpenCode есть. Подробное сравнение Claude Code и OpenCode можно посмотреть в этом видео. Имелись некоторые проблемы с устойчивостью, например, по началу я использовал модель без поддержки reasoning, поэтому запросы часто падали с ошибкой.
Оказалось, проблема была не у одного меня.
А вариантов решений было два: сделать форк OpenCode и внести фикс или откатиться до определённой версии OpenCode. Я выбрал второй вариант, он казался мне более логичным. К тому же через время я перешёл на модель с поддержкой reasoning и проблема отпала сама собой.
Как вы, наверное, догадались, в итоге я выбрал OpenCode.
И вот теперь я здесь. Держу в руках тёплую блестящую лампу, внутри дремлет волшебник-джинн, готовый исполнить моё желание. А чего, собственно, я хочу? Мне нравится моя работа, я люблю писать код, к счастью, моя текущая роль позволяет совмещать менеджерские и технические задачи.
Я начинаю размышлять, что бы я предпочёл, чтобы за меня в работе сделал кто-то другой. Есть ведь много рутинной работы. Переводить модели из API в DTO. Добавлять Compose Preview. Писать unit-тесты…Точно. Тесты. Все, кто работал на проекте Альфа-Мобайл (ребята, всем пламенный привет), знают, что хуже, чем писать unit-тесты, может быть только писать unit-тесты на Groovy. Хотя нет. Есть кое-что хуже. Переписывать их с Groovy на Kotest))).
Это была шутка, надеюсь, никто из адептов TDD среди читателей не пострадал. Тесты кажутся важной штукой, и наверняка есть люди, которым нравится их писать. Одного я даже знаю). Но сам к их числу не отношусь. Поэтому жребий был брошен. Первое желание готово. Тогда я ещё не знал, что впереди меня ждут два месяца экспериментов, чтобы полученный результат был действительно магическим…
Глава 5. Первый тест комом
Что нужно сделать, чтобы всё получилось? Нужно дать модели побольше контекста, подумал я. Тогда я ещё не добрался до этой замечательной статьи про context rot.
Я накидал большой системный промпт, куда уложил кучу информации о проекте. Написал md-файл с описанием агента. Подробно описал шаблонный промпт для написания unit-тестов. И с чувством выполненного долга и лёгким волнением от предстоящего эксперимента приготовился нажать на кнопку «Пуск». Было приятно хотя бы мгновение чувствовать себя Илоном Маском. Пусть и в не самый счастливый момент его жизни. Ведь моя первая ракета тоже стартовала, но не взлетела. Пусть обошлось и без взрывов.
Что же пошло не так, спросите вы?
Во-первых, время. Я ожидал, что моя модель будет отставать в скорости от платной. Но не думал, что настолько. Тест на небольшой маппер мой джинн писал около 20 минут.
Во-вторых, это было не совсем то, чего я ожидал. Вместо готового рабочего теста я получил алую зарю из предупреждений о некомпилируемом коде или ошибках импорта.
В-третьих, джинн явно проигнорировал мои инструкции. Как раз таки из-за слишком большой их подробности. Переизбыток информации был ничем не лучше её нехватки, модель запуталась и начала ловить галлюцинации.
Проблему со скоростью я пытался решить путём параллельного запуска нескольких сессий Opencode в терминале. В итоге через 20 минут вместо одного некомпилируемого теста я получал 5, время на отладку и правки увеличивалось пропорционально.
А почему бы не попросить модель проверять тест перед завершением задачи, подумал я? От этого стало только хуже. Выводы задач Gradle после запуска теста или проверки компиляции забивали контекст, в итоге модель либо уходила цифровое забвение в вымышленный мир несуществующих методов тестирования, либо падала из-за превышения размера контекстного окна.
Ну и стоит ли говорить о том, что правки такого теста вручную — это долго, нудно и больно, проще всё удалить и написать самому?
И это только с unit-тестами для малышей-мапперов. Когда я попробовал в один заход написать тест на большую вьюмодель с кучей логики, всё закончилось полным фиаско. Модель галлюцинировала, не понимала, какие инструменты для тестирования ей применять. Максимум, чего я смог добиться на этом этапе — чтобы мой цифровой джинн проанализировал код вьюмодели и набросал скелет будущего текста, который я уже потом написал. Словно у меня был рядом подмастерье, способный выполнить только самую грубую несложную работу.
Как назвать человека, который делает одни и те же действия, надеясь получить другой результат? Верно, программист. Если конкретнее, то автор статьи. Около двух недель я пытался добиться жизнеспособного решения, надеялся, что вот сейчас ещё немного я улучшу промпт, БОЛЬШИМИ БУКВАМИ пропишу самые важные моменты, и джинн всё поймёт. И тесты заработают. Но нет. Кажется, я упустил какие-то важные нюансы в настройке модели. И позже я понял, какие.
Глава 6. «Он ожил!»
Так сложилось, что на некоторое время плотные эксперименты с ИИ мне пришлось отложить. У нас была объёмная задача, которую мы делали вдвоём с разработчиком из моей команды. Время от времени я делегировал небольшие моменты модели, но это было не то, о чём я думал. В своих мечтах я видел готовые рабочие unit-тесты в один клик.
За это время вышло пару опенсорсных моделей, более мощных и умелых, чем жила до этого у меня. В сообществе появилось больше информации о настройке системы агентов и создании навыков для них. А ещё другой мой сотрудник затащил на проект классные расширения для тестов, используя всю мощь и красоту Kotlin DSL. Всё было готово к тому, чтобы сделать вторую попытку достичь вершины.
И я снова начал своё восхождение. Начал я с того, что у меня уже давно чесались руки завести RAG с проиндексированным проектом, чтобы ускорить модель в поиске и изучении нужных файлов. Для этой цели можно сделать своё решение или воспользоваться чем-то готовым. Например, затянуть к себе ast-index.
Второй момент, которыйне давал мне покоя — как научить модель саму проверять и исправлять тесты. Для начала здесь предстояло решить проблему с бесполезной информацией при запуске Gradle. Т.е. настройка Opencode должна быть такой, чтобы в промпт модели попадала только нужная информация, без всех этих подробностей о том, какой модуль был собран из кэша и т.д. Как и в прошлом вопросе, здесь нужно было написать своё решение или воспользоваться плодами труда других. Например, использовать rtk.
Итог манипуляций выше: уменьшился размер передаваемой в модель информации без потери её качества. Отлично, можно двигаться дальше.
Следующим логическим шагом было добавить структуру в файлы с настройками модели. Например, выстроить систему из саб-агентов и скилов. Подробнее можно почитать об этом в документации. Принцип здесь практически идентичен настройке Claude Code и других инструментов.
Сакральный смысл этих манипуляций со скилами я для себя объяснял так. Если дать мне инструкцию на 100 страниц, заставить прочитать, а потом попросить что-то сделать по ней, я запутаюсь. Если дать мне закладки на страницы, где находится инструкция для конкретного действия, у меня будет больше шансов сделать всё правильно.
Вся настройка, о которой речь пойдёт ниже, осуществлялась не в ручную, а через активное использование модели. Я просил модель обновить конфигурационные файлы после каждой итерации замечаний. В итоге джинн обучал и настраивал сам себя. Одним словом, магия.
Для начала я разделил задачу по написанию тестов между 3 ролями, 3 субагентами:
Планировщик. Его задачей было изучить контекст тестируемого класса и подготовить md-файл с todo-листом, детальным планом того, что нужно сделать, какие методы протестировать, на каких корнер-кейсах сосредоточить внимание.
Писатель тестов. Непосредственный исполнитель, задачей которого было реализовать все пункты в todo-листе.
Ревьюер. Его задачей было проверить компиляцию и полноту тестов, соответствие теста описанным требованиям и code style.
Оркестрация сабагентов происходила через основного агента для написания кода. Также у каждого из саб-агентов были свои навыки, в которых подробнее были описаны инструкции для конкретного шага. Меня тоже мучил вопрос, как OpenСode поймёт, какого сабагента нужно вызвать в конкретный момент или какой навык использовать. Оказалось, что достаточно было прописать это в файл с агентом. Возможность вызвать нужного саб агента в ручную в OpenСode также присутствует.
К слову со временем я пришёл к выводу, что тесты на маленькие классы основной агент вполне может написать и без своих помощников. Поэтому соответствующий пункт был прописан в файле с основным агентом для тестов.
Последним штрихом для для настройки промпта было замечание от моего коллеги из кор-команды:
Что ж, замечание по существу, поэтому я внёс соответствующие инструкции в файл агента. Естественно, через делегирование этой почетной миссии моему джинну:
Наконец всё было готово к запуску, я выбрал подходящие тесты и, затаив дыхание, потёр лампу нажал на кнопку.
Результат:
Я получил готовый тест на небольшой маппер, полностью работающий и компилирующийся. Merge request прошёл ревью с замечанием по стилю теста, это замечание было сразу внесено в соответствующий skill. И, естественно, замечание было исправлено самой моделью. Но приглядитесь, уверен, вас смущает одна небольшая деталь.
Глава 7. 19 минут на тест
19 минут на тест… Скорость всё ещё не выросла. Это не похоже на феноменальный рост производительности. Но здесь важно отметить, что пока модель писала тесты, я проводил 1:1 с сотрудником. В таком случае 19 минут — это ок. Хотелось бы быстрее, но пойдёт.
Вдохновлённый успехом, я решил поручить модели небольшой баг. Сам я специально не особо продумывал решение. Лишь указал модели класс, в котором имелась проблема. И примерно что нужно исправить. Удивительно было то, что агент примерно повторил шаги, которые я предпринял бы для исправления этого бага. Неужели оцифровал мою идентичность?)
Как и в прошлом случае, модель выполняла задачу, пока я находился на созвоне.
Очевидно, что мощности локальных моделей или моделей на серверах компаний отстают от типовых игроков рынка. Разве что если бы я не прикупил на блошином рынке списанный дата-центр и не разметил его по соседству с плантацией клубники в деревне у нашего дедушки. Но нет, по соседству с клубникой у нас растёт картошка, поэтому приходится обходиться имеющимися мощностями.
С другой стороны, я и не гнался за скоростью. Я проверял гипотезу, как и насколько ИИ-джинн сможет увеличить мою эффективность. Я хотел делегировать машине часть работы, которую не хотелось бы делать самому. Или пока я нахожусь на звонках. И в конечном итоге она с этой задачей справилась. С учётом того, что токены были бесплатными (если не считать счета за электричество), а правила игры от ИБ были соблюдены, я решил, что результат был более чем удовлетворительным. (UPD: за время написания статьи удалось протестировать сформированную систему на больших мощностях, время на один тест сократилось примерно до 5-10 минут).
И напомню свою главную цель. Развить экспертизу применения ИИ. И применить полученные знания на реальной рабочей задаче. Здесь всё тоже получилось и для первого раза вышло неплохо.
Вместо заключения: будущее уже здесь
Если вы читаете эти строки спустя полгода после публикации статьи и или позже (автор уже ушёл в сельское хозяйство, передайте привет Джону Коннору), вполне возможно, что ИИ с присущей геометрической прогрессией развилось настолько, что все описанные выше шаги кажутся бесполезными и лишними. Но если вы дочитали до этого места, значит, статья всё же показалась вам любопытной.
Но я не об этом.
Всего 4 года назад страшилки про замену программистов казались чем-то опасным, вероятным, но не очень близким. У нас даже состоялся джентельменский спор с классным автором Костей Рисковым на эту тему:
И вот сегодня генеративные модели и ИИ-агенты одна за одной проникают в компании. Конечно, пока полной заменой человека на машину и не пахнет. А громкие новости о том, что какая-то из компаний сократила штат из-за внедрения ИИ, можно прокомментировать словами героя фильма «ДМБ»: они свой недуг определяют в подвиг.
Собственно, не кто-то, а сам Сэм Альтман подтверждает эту гипотезу:
Некоторые впечатлительные менеджеры, начитавшись статей от ИИ-диллеров, мечтают, как будут фиксить баги без разработчиков или как в команде останется ПО/ПМ и пару вайб-кодеров. Что ж, если у них получится, буду рад послушать доклад про передовой опыт и оказаться в числе этих двух выживших среди всех программистов счастливчиков.
Но вот то, что многие уже не представляют себе процесс разработки без ИИ — это факт. Медленно или быстро, но верно ИИ-агенты распространятся по компаниям.
Рискну сравнить это процесс (пусть сравнение и очень грубое, да простят меня читатели) с распространением Kotlin Coroutines и Jetpack Compose. И сегодня есть достаточно проектов, где вьюшки верстаются на xml, а отличать и не путать observeOn от subscribeOn — ежедневный must have навык для разработчика. Но стандартом рынка от законодателя мод стали корутины и Compose. Кто знает, может, вслед за разделом для верстки вью на xml из Android Studio исчезнет и возможность вручную изменять код.
Среди программистов достаточно скептиков, считающих, что ИИ плохо пишет код, а они будут держаться до последнего в числе тех, кто пишет код сам. У меня были похожие мысли чуть больше полгода назад. А потом я вспомнил, что естественный отбор — это не всегда про то, что выживает сильнейший. Эволюция — это когда в живых остаётся тот, кто сумел лучше адаптироваться к резкому изменению среды.
Погружение в настройку ИИ-агентов показалось мне интересным делом, в котором можно удовлетворить потребность в самореализации как инженера. Если вдруг вы всё ещё скептически настроены к нейросетям, попробуйте и вы решить какую-то осязаемую проблему с помощью ИИ. С готовностью приложить весь свой инженерный опыт, чтобы добиться результата. Попробуйте. Вдруг вам тоже понравится?
