На днях провел эксперимент с LLM.

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

Суть эксперимента была в том, что я со своими знаниями и экспертностью попробую дать на вход максимум контекста и в итоге оценю результат.

Контекст я готовил половину рабочего дня: делал референсы из ТЗ, собирал контекст из переписок, саммари из созвонов. Было подготовлено много артефактов.

Дальше я запустил генерацию и через 30 минут получил готовый код: покрытый тестами, полностью рабочий. Если отправить его в прод, никто даже не заметит подвоха. QA отчитается, что все кейсы выполнены и все гуд.

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

Что в итоге? Как вы думаете?

Я полностью его переписал. Начиная от структуры таблиц и заканчивая кодом.

Это был рабочий мусор.

Думаете, вывод такой: «ха-ха, LLM делает мусор»?

Нет.

Эксперимент на самом деле завершился так, как я и предполагал. ИИ — это просто инструмент. Качественный контекст по задаче даст рабочее решение, но он не выполнит все ваши внутренние соглашения сам по себе.

А вот чтобы все было так, как вы хотите, хотя бы приближенно, нужно потратить кучу времени на подготовку проекта к работе с LLM: выстроить harness, дать примеры того, как нужно писать, и постоянно их поддерживать.

Причем это нужно внедрять не только на уровне разработки. Аналитики тоже должны сразу готовить контекст по задаче в едином стиле, желательно в кооперации с LLM, чтобы на вход уже попадал нормальный сформированный инпут, а не набор разрозненных сообщений, созвонов и догадок.

То есть задача должна приходить не в формате «ну там в переписке все есть», а в виде готового артефакта: что делаем, зачем, какие ограничения, какие кейсы, какие спорные места, какие примеры, какие связи с текущей системой.

А дополнительную информацию модель уже должна получать через внутренний MCP: документацию, схемы, соглашения, примеры кода, контракты, историю решений и все остальное, что нужно для нормального погружения в проект.

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

Все это невозможно без смены мышления у всей команды.

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

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

Пока как-то так.

P.s. Манифест "AI Native - Новая культура мышления" уже доступен - https://ai-native.cutcode.dev

Решил всё-таки закинуть неизданный ролик про бизнес, построенный на AI😄

Почему неизданный?
Я скидывал его нескольким людям — никто не засмеялся.

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

Опа, Тейлор Отвелл говорит, что issues — это уже что-то из мира динозавров 😄

Нашли баг? Не создавайте issue — берите агента, чините и отправляйте PR.

Следующий логичный шаг: закрыть все open source-проекты и написать в README:
«Если вам чего-то не хватает — возьмите агента и напишите сами».

Куда катится этот мир? 😂
А если серьёзно — как вам такой подход? Issues действительно становятся не нужны в эпоху AI-агентов или Тейлор немного разогнался?

Коллеги, небольшой личный релиз 🎧

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

В общем, я сгенерировали трек — и мне реально интересно, что вы скажете.

Послушайте, поддержите, если зайдёт, добавьте к себе и помогите загнать его в топ 😄
Ну и особенно буду рад честной обратной связи.

https://music.yandex.ru/album/43767542/track/155325684?ref_id=53646F22-06F0-4066-9CE6-D8B28753AF3D&utm_medium=copy_link

Пыхник’26 — целая неделя PHP!

С 28 сентября по 2 октября пройдёт Пыхник’26 — онлайн-конференция для PHP-разработчиков.

В программе 10 докладов о современной PHP-разработке: AI, архитектура, асинхронность, компиляция и тестирование.

Доклады распределены на всю неделю — не нужно выпадать из работы на целый день!

До конференции проводим еженедельные встречи «У костра» — обсуждаем PHP, AI и будущее разработки. Темы предлагают и выбирают сами участники.

• 28 сентября — 2 октября
• Прямой эфир + записи
• 5 дней по 2 доклада: утром и вечером
• Билет — 3 000 ₽

Скидка 15% по промокоду CUTCODE-26!

👉 Программа и билеты

Топ-1 преимуществом Laravel всегда была документация.

Теперь она будет для агентов.

Помянем 🥲

Теперь документация по Laravel пишется для ИИ-агентов. И скорей всего ИИ-агентами 😁

Пыхник’26 — 2 октября расскажу про осознанное использование AI.

Скидка 15% по промокоду CUTCODE-26!

👉 Программа и билеты

Но все еще скидка 15% по промокоду CUTCODE-26!