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

Преподавать — это намного сложнее, чем кажется. Многие думают, что если человек крутой специалист, то он автоматически сможет учить. Нет. Очень часто происходит наоборот: чем умнее человек в теме, тем хуже он может объяснять новичку. Потому что для него уже всё «очевидно». Помню это ещё со школы. Новая тема по математике. Сначала всё понятно. Идёшь за преподавателем. Ловишь мысль. Решаешь примеры. А потом — в какой-то момент — ты не понял один маленький кусок. Один. И всё. Преподаватель уже пошёл дальше. Поток не остановился. А у тебя в голове как будто отвалился один винтик — и вся конструкция перестала собираться. Ты сидишь на уроке ещё 20–30 минут, но по факту уже не учишься. Ты просто физически присутствуешь. Вся оставшаяся часть урока проходит мимо. В школе нас хотя бы делили по уровням. Начальная. Средняя. Старшая. Не идеально — но попытка выровнять темп. А как быть сейчас, когда ты делаешь современный урок или воркшоп? Вот я планирую воркшоп по разработке с ИИ. И там могут быть одновременно: — разработчики — не разработчики — люди с опытом — новички — те, кто живёт в словах "workflow", "prompt", "context" — и те, для кого даже слово workflow — уже стоп-сигнал И тут легко словить «горе от ума» преподавателя. Тебе кажется, что ты говоришь базу. А для части людей именно здесь уже потеряна нить. Это важное напоминание для любого, кто учит других: Преподавание — это не «знать тему». Это уметь постоянно проверять, не потерял ли ты людей по дороге. Потому что иногда весь урок ломается не на сложной формуле, а на одном нерасшифрованном слове. Сильный преподаватель — не тот, кто быстро и умно объясняет. А тот, кто умеет держать поток так, чтобы люди из него не выпадали. И да — всё учесть невозможно. Но именно поэтому преподавать — действительно сложно.

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! 👉 Программа и билеты