Одержимый кодом🔥

Rust язык будущего? Строгость побеждает? Думаю, многим я уже успел надоесть с ИИ-разработкой, но я снимаю и пишу только о том, что со мной происходит прямо сейчас. Реальность такая, какая есть. Небольшие наблюдения, которые я сделал при активной разработке с LLM. К сожалению, как фанат и адепт PHP, я всё чаще задумываюсь о выборе языка — и чуть позже вы поймёте почему. Если планировать выбор стека вместе с LLM, то в 90% случаев вам предложат Python или JS, в крайнем случае — Go. В целом последние проекты у меня и варьировались в этом стеке. Если взять Python и JS (это касается и PHP), то, на мой взгляд, они НЕ подходят для работы с LLM, а LLM рекомендует их в первую очередь потому, что обучалась в основном на них. Но это гибкие языки со свободой, а значит — с непредсказуемыми сюрпризами в рантайме. Это боль. Сложная экосистема — тоже боль и лишний контекст. Я не верю, что выживет язык, которому нужно сверху обмазаться кучей инструментов для проверки качества, создавая лишний шум в коде. Выживет язык с нативной строгостью, у которого в коробке есть весь набор инструментов для контроля качества и поведения. Понимая это, я решил попробовать Rust. Зная его строгость и богатый набор инструментов «из коробки» — чуть меньше, чем у Go, но через Cargo добавить форматер и линтер проще некуда на старте конфигурирования. LLM меня отговаривала, но я протестировал теорию на двух проектах. Это нативные десктопные приложения: одно — набор серверов, на которых можно быстро воспроизводить готовые рецепты и ставить Docker, Git и прочий джентльменский набор; второе — приложение, которое воспроизводит воркфлоу дистилляции идеи с дальнейшим проходом по пайплайну и получением документации по системному дизайну, UI, оценке аудитории и всему, что требуется на старте (оба на скринах). И знаете что? В процессе я не столкнулся ни с одним фиксом логики. Просто ноль. Язык строгий, и уже на уровне линтера и предварительной компиляции LLM видит все проблемы, фиксит их в цикле и выдаёт рабоч

Спека > инструмент На днях OpenAI выпустили Symphony - handoff-систему для оркестрации агентов. Но зацепил меня не сам проект, а идея внутри него. Там нет "готового серебряного инструмента". Есть спецификация и фоном - пример реализации. И кажется, это очень точно описывает, куда вообще движется разработка. Сейчас инструменты растут как грибы. Выходит один проект - через пару дней уже десятки аналогов. Сегодня день рождения проекта CutCode - ему уже 5 лет. Из них 4 года я делаю MoonShine, и его разработка сводилась к тому, чтобы угодить всем: кому-то не нравится цвет, кому-то расположение блоков, логика… У каждого своё мнение. Мы пытались делать универсально - увеличивая хаос в кодовой базе. Разработка стала доступна почти каждому. Сейчас пользователь вряд ли будет тратить время на чужой инструмент. Но вместе с этим пришла новая проблема: люди всё чаще собирают решения под себя, быстро, красиво, с дофамином… а потом получают: • проблемы с безопасностью • невозможность нормально поддерживать код • архитектурный хаос Мы уже видим это в продуктах вайбкодинга вроде openclaw, zeroclaw и им подобных. И вот здесь появляется, как мне кажется, главный тезис нового этапа: Спека > инструмент Не готовый инструмент становится центром ценности. Ценностью становится спецификация: • какой стек выбрать • как продумать инфраструктуру • где будут архитектурные риски • какие ограничения нужны сразу А всё остальное уже можно достроить поверх. То есть разработчик будущего, возможно, продаёт не сайт и не админку, а хорошо продуманную спецификацию, по которой ИИ и команда потом собирают решение под конкретный контекст бизнеса. Что если Symphony - это только первый шаг? И скоро мы будем продавать не инструменты, а спеки?

Удачи, веселья, не сдохни! Всем хороших выходных. Хочу просто порекомендовать фильм, который посмотрел вчера — «Удачи, веселья, не сдохни!» Как говорит один мой друг: жанр — «грибной». И это, кажется, лучшее описание. Фильм странный, но цепляет. Смотришь и ловишь себя на мысли: а мы вообще далеко от этого всего? Как будто сами уже где-то рядом со шлемом, который подключает к другой реальности. А может уже подключились. А может, и не отключались никогда. В общем, кино своеобразное, но мне зашло. Гляньте на выходных, а потом расскажите, как вам.

Понял, что в последнее время перед ревью мне не хватает понимания, кто именно писал реализацию. Похоже, теперь во всех моих open-source проектах появится такой PULL_REQUEST_TEMPLATE.md. Мне ведь тоже важно понимать, какую модель использовали и насколько тщательно подходить к ревью. Мало ли, вдруг там всё на дипсиках генерировалось 😂.

Стало грустно, значит надо писать код! Последние N месяцев не пишу код руками. N - потому что уже забыл, сколько. Оттупел, возможно. Все это время где-то внутри присутствует тоска. Как будто у меня на балконе стоит офигенный велосипед, который я обожаю: я продолжаю за ним ухаживать, мыть, но не вижу смысла на нем гонять, когда есть тачка. Нет задач, чтобы пойти и покататься на велике - все, что требуется, решает тачка. Да, так бывает, когда ты не в найме😊 Но внутри тоска и постоянное ощущение: а что, если я разучусь кататься на велосипеде? Я ведь столько лет потратил, чтобы кататься хорошо. Вообще любые циклические мысли тратят кучу энергии. Мы обретаем силу, когда наши мысли чисты и нас не отвлекает лишний шум. В общем, я тут недавно за день получил три краша от PhpStorm, разозлился и снес все продукты JB, установил Zed. Что хочу сказать? Ну, во-первых, как хорошо я умею соскакивать с одной темы на другую в одном посте😀 Но нет! Zed - кайф при генерации кода с AI. Но я все-таки решил достать велосипед и погонять на нем - в общем, самому пописать код, и именно в Zed. Поддержка PHP тут близка к нулю, автокомплит - ад, автоперехода нет. И в таких условиях - прям кайф. В общем, буду периодически устраивать такие вылазки с тачки на велосипед и кататься на нем по квартире (ну, в смысле, кодить в Zed вместо PhpStorm). Или просто пора работу искать 😀

На днях провел эксперимент с LLM. Занимался реализацией задачи в проекте, где генерировать код LLM-кой запрещено. Сам проект абсолютно не готов для работы с ИИ, хотя глобально там есть общие универсальные скиллы по тестам, качеству кода, архитектуре и т.д. Они общие, но индивидуального контекста под проект нет. Суть эксперимента была в том, что я со своими знаниями и экспертностью попробую дать на вход максимум контекста и в итоге оценю результат. Контекст я готовил половину рабочего дня: делал референсы из ТЗ, собирал контекст из переписок, саммари из созвонов. Было подготовлено много артефактов. Дальше я запустил генерацию и через 30 минут получил готовый код: покрытый тестами, полностью рабочий. Если отправить его в прод, никто даже не заметит подвоха. QA отчитается, что все кейсы выполнены и все гуд. Но код LLM-кой писать запрещено, значит, прежде чем отправлять его на ревью, мне нужно было поревьювить его самому. Что в итоге? Как вы думаете? Я полностью его переписал. Начиная от структуры таблиц и заканчивая кодом. Это был рабочий мусор. Думаете, вывод такой: «ха-ха, LLM делает мусор»? Нет. Эксперимент на самом деле завершился так, как я и предполагал. ИИ — это просто инструмент. Качественный контекст по задаче даст рабочее решение, но он не выполнит все ваши внутренние соглашения сам по себе. А вот чтобы все было так, как вы хотите, хотя бы приближенно, нужно потратить кучу времени на подготовку проекта к работе с LLM: выстроить harness, дать примеры того, как нужно писать, и постоянно их поддерживать. Причем это нужно внедрять не только на уровне разработки. Аналитики тоже должны сразу готовить контекст по задаче в едином стиле, желательно в кооперации с LLM, чтобы на вход уже попадал нормальный сформированный инпут, а не набор разрозненных сообщений, созвонов и догадок. То есть задача должна приходить не в формате «ну там в переписке все есть», а в виде готового артефакта: что делаем, зачем, какие ограничения, какие кейсы, какие спорные места,

От скучной генерации к инженерии с ИИ ИИ быстро генерирует код, но без контекста, декомпозиции и проверок работа с агентами превращается в ожидание и бесконечные правки. В докладе поговорим об AI-разработке как об управляемом инженерном процессе. Данил Щуцкий — backend-разработчик с опытом более 15 лет, автор Laravel-сообщества и YouTube-канала CutCode. Консультирует команды по архитектуре и высоконагруженным системам, развивает open source и инструменты для работы с ИИ. На примере AI Factory и AI Workspace Данил покажет, зачем нужны отдельные этапы исследования, планирования, реализации и проверки — и как превратить работу с кодинг-агентами в повторяемый процесс с понятными правилами и контролем результата. 🌿 Присоединиться к Пыхнику

Решил всё-таки закинуть неизданный ролик про бизнес, построенный на AI😄 Почему неизданный? Я скидывал его нескольким людям — никто не засмеялся. В общем, теперь ваша очередь. Возможно, проблема была в людях. Или всё-таки в ролике 😁

Опа, Тейлор Отвелл говорит, что issues — это уже что-то из мира динозавров 😄 Нашли баг? Не создавайте issue — берите агента, чините и отправляйте PR. Следующий логичный шаг: закрыть все open source-проекты и написать в README: «Если вам чего-то не хватает — возьмите агента и напишите сами». Куда катится этот мир? 😂 А если серьёзно — как вам такой подход? Issues действительно становятся не нужны в эпоху AI-агентов или Тейлор немного разогнался?

Пыхник’26 — целая неделя PHP! С 28 сентября по 2 октября пройдёт Пыхник’26 — онлайн-конференция для PHP-разработчиков. В программе 10 докладов о современной PHP-разработке: AI, архитектура, асинхронность, компиляция и тестирование. Доклады распределены на всю неделю — не нужно выпадать из работы на целый день! До конференции проводим еженедельные встречи «У костра» — обсуждаем PHP, AI и будущее разработки. Темы предлагают и выбирают сами участники. • 28 сентября — 2 октября • Прямой эфир + записи • 5 дней по 2 доклада: утром и вечером • Билет — 3 000 ₽ Скидка 15% по промокоду CUTCODE-26! 👉 Программа и билеты