Александр Ламков — Friendly Frontend

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

😏 Надоело платить за приложение — сделал своё за час Несколько лет я платил за приложение для трекинга силовых. Минималистичное, вроде норм, но какие-то мелочи раздражали постоянно — где-то UI кривой, где-то фич не хватало. Я даже писал разработчику на почту, просил добавить пару вещей. За все годы использования так ничего и не появилось. Когда подписка кончилась (полтинник $ в год, если что), я как-то не нашёл в себе желания продлевать ради приложения, которое устраивает меня наполовину. И тут до меня доходит, что я же сейчас целыми днями вожусь с вайб-кодингом. Наболтал агенту минут пятнадцать голосом, накидал скриншотов старого приложения в качестве референса — и он мне в один промпт собрал PWA с деплоем на GitHub Pages, офлайн-режимом и бесшовным переносом данных из старого приложения. Со всеми моими хотелками, включая ровно те места, которые меня годами бесили. Бесплатно. По сути самопальный форк, хотя даже не форк — разработка с нуля, просто за образец взял знакомый мне интерфейс и дошлифовал больные места. Пятнадцать минут я болтал только потому, что многословный до идиотизма и переливаю из пустого в порожнее. Нормальный человек уложился бы минут в пять. Сама сборка заняла минут тридцать-сорок: я сходил попил кофе, вернулся — готово. Открыл задеплоенный сайт с телефона, добавил иконку на рабочий стол, и всё. Неделю уже пользуюсь, полёт нормальный. К чему это. У меня тут весь канал в последнее время пропитан AI, и кейс до дебильного очевидный, но всё же хочется его подсветить. Раньше собственное приложеньице под свои хотелки — это недели возни, поэтому обычно ты просто машешь рукой и живёшь с чужим кривым. Сейчас цена того, чтобы взять любую надоевшую штуку и переделать под себя — буквально час: наговорил, накидал что-то вроде ТЗ, дождался, проверил. Всё, что бесит, теперь можно молча пойти и переписать. И я, если честно, реально этому рад — не надо больше убивать недели на элементарную приложуху, которая просто пишет веса, подходы и рисует пару графиков. Кому интересно само приложение — тык сюды (ПВАшка, вы фронтендеры, разберётесь как ставить). Исходники — тут (забавно, что я их даже не смотрел).

Последний день Fable 5 в подписке - вот на что его потратить, пока не поздно С завтрашнего дня Fable 5 уходит из подписок - останется только за кредиты: $10 за миллион входных и $50 за миллион выходных токенов. Anthropic обещает вернуть его в тарифы, когда нарастят мощности, но когда это будет - неизвестно. 🪼 Так что сегодня я его выжала по полной. И самое ценное применение оказалось - разобрать мои прошлые сессии в Claude Code и найти то, чего я сама не замечаю: повторяющиеся действия, лишнюю ручную работу и места, которые давно пора превратить в skill, автоматизацию или отдельного агента. И вот это прям вау 😍 🪼 Вот запрос: # режим аудита, ничего не менять Изучи мои прошлые сессии Claude Code и найди все, что стабильно съедает время: повторяющиеся задачи, одинаковые цепочки команд, места, где я каждый раз заново объясняю контекст. Разведи анализ по под-агентам, сигналы бери из расшифровок сессий. Сгруппируй находки и по каждой реши: новый skill, автоматизация, точечный фикс или не трогать. Все варианты с приоритетами запиши в отдельный md-файл. В проекте ничего не правь, пока я явно не разрешу. 🪼 Он не выдал общие советы, а разложил все по сессиям: где нужен новый навык, где автоматизация, где исправление, а где лучше не трогать, чтобы не усложнять систему. Самое ценное - не один красивый ответ, а карта улучшений, которую можно внедрять постепенно. Успейте прогнать по своим сессиям сегодня, пока это входит в подписку, а завтра покажу, что я успела собрать руками Claude Code, пока разгребала свои процессы 😉 @NeuralProfit

Не могу не поделиться. На одном из личных проектов сработало шикарно — за 30 минут Fable 5 на Ultracode ризонинге составил 15 мощных пунктов с автоматизацией моментов, при которых я часто орал на ИИ в стиле "да ты задолбал, сделай уже нормально, ну" — те мелочи, которые агент держал в какой-то глобальной памяти и всякий раз переизобретал велосипед. Думаю, и Opus 4.8 справился бы на ура с такой задачей, но раз уж последний день с "почти халявным" Фейбл, чего бы и не выжать из него все соки.

📱 ИИ нагенерил — а на созвон идёшь ты Снобы спрашивают: а может ли ИИ писать хороший код, или это всё нейровысер? Но и это, честно говоря, не самый интересный вопрос. Вопрос в другом: кто отвечает за результат? После экспериментов с попыткой сделать игру с помощью ИИ я очень хорошо почувствовал разницу между «что-то сгенерировалось» и «получился продукт». Генерация — это легко. Дальше начинается работа. Потому что код — это только видимая часть. За ним стоит куча вещей, которые модель не знает и знать не может: бизнес-контекст, реальные ограничения проекта, договорённости команды, легаси, где будет больно через полгода, почему одно решение здесь нормальное, а другое — мина замедленного действия. ИИ не знает, что важно пользователю и что важно бизнесу. Он знает только то, что ты ему сказал. Если модель нагенерила плохое решение, на созвон объяснять, почему всё сломалось, придёшь ты. Ответственность пока не автоматизировали. Разработчик ценен не тем, что умеет писать синтаксис — это давно не дефицит. Ценность в другом: понять задачу, задать неудобные вопросы, увидеть риск, который не очевиден, упростить решение, принять решение и ответить за него. ИИ в прод не мёржит. Это делаешь ты. Мне кажется, это хорошая новость для тех, кто понимает, что делает. Роль разработчика не исчезает — она смещается. От «напиши вот это» к «разберись, что вообще нужно, и сделай так, чтобы потом не было мучительно больно». ИИ здесь хороший помощник. Но помощник, а не тот, кто несёт ответственность.

Топ-6 советов по эффективному использованию AI coding 1. Всегда используйте feedback loop. Чтобы агенты писали надёжный код, им необходимо дать в руки подходящие инструменты для проверки - линтеры, type-check, тесты, сборка, E2E. 2. Карта местности. Собирайте знания о проекте в AGENTS.md. Как только файл станет большим, делите его на модули в директории, напр. docs, а в AGENTS.md оставьте оглавление к этой директории. 3. Сначала обсуди задачу, потом реализуй. Обязательно обсудите с AI вашу задачу и убедитесь что он вас понял; соберите требования по задаче в .md файлик, а потом приступайте к реализации. Иначе, с большой вероятностью агент сделает не то, что вам нужно. 4. Используйте subagents правильно. Отправляйте одного агента писать код, а второго делать ревью этого кода. Так один будет проверять другого и качество кода вырастет. 5. Автоматизируйте только то, что уже проходили вручную. Если процесс не понятен и не описан, автономные циклы агентов будут дорогой лотереей. 6. AI лучше всего помогает там, где ты сам разбираешься. Особенно, в проектах, где цена ошибки высока. AI умножает ваши знания. Ему необходим человек, который разбирается в теме, направляет его и во время бьёт по его электрическим ручкам! Если было полезно, сохраняйте себе, делитесь с друзьями и подписывайтесь на тг-канал автора – Тимур Хахалев про AI Coding. Реклама. Хахалев Т.А. ИНН 263409721346. erid: 2W5zFH62end

Есть одна мысль про ИИ, которую не очень приятно слышать: он не уравнивает всех. Скорее наоборот. Во фронтенде я работаю с ИИ довольно уверенно — понимаю код, могу проверить результат, вижу, где модель ошиблась, могу встроить решение в реальный проект. Когда я полез делать игру — область, где у меня нет нормальной базы, — разница стала очень ощутимой. Не потому что ИИ внезапно стал хуже, просто я перестал понимать, хороший результат передо мной или нет. Прикол в том, что сильный специалист с ИИ точнее формулирует задачу, задаёт правильные ограничения, быстро замечает, где модель поехала не туда, понимает, временное решение или нормальное, и может взять ответственность за результат. ИИ в его руках реально ускоряет работу. Человек без понимания области получает код — но не понимает его качества. Может принять красивую генерацию за хорошее решение. Может не заметить архитектурную проблему. Может часами двигаться в сторону, которая никуда не ведёт, и не знать об этом. Это не вина ИИ — он сделал, что попросили. Самая опасная вещь здесь — иллюзия компетентности. Код появился, файлы создались, проект как будто развивается. Ощущение, что всё под контролем. Но если ты не можешь проверить результат, ты не контролируешь работу — ты просто наблюдаешь за ней. Это вовсе не значит, что новичкам не стоит пользоваться ИИ. Как раз наоборот — как инструмент для обучения он очень мощный. Но опасно думать, что он компенсирует отсутствие базы. Нейронка не выдаёт тебе опыт вместе с ответом. Экспертиза не становится менее важной с появлением ИИ. Она становится важнее — потому что теперь главный навык не написать запрос, а оценить, можно ли доверять тому, что пришло в ответ.

Со стороны работа с AI-агентами выглядит красиво: описал задачу, получил код, сэкономил несколько часов. Иногда так и есть. Но иногда это выглядит совсем по-другому. Особенно хорошо я это прочувствовал, когда полез делать игру — область, где у меня не было нормальной экспертизы. Агент что-то генерирует, ты запускаешь, что-то работает не так. Просишь исправить — модель чинит одно и ломает другое. Уточняешь, ждёшь, снова проверяешь. Через пару часов понимаешь, что не ведёшь процесс, а просто тыкаешь палкой в чёрный ящик и смотришь, что выпадет. Самое утомительное в этом цикле — не писать запросы. А пытаться понять, приближает ли очередная генерация к нормальному результату или просто создаёт новый слой проблем. Файлы появляются, код пишется, проект меняется — а продукт почти не двигается. Это иллюзия движения, и она выматывает сильнее, чем просто ничего не делать. Причина обычно не только в модели. Если нет плана, нет критериев качества и нет понимания, что вообще считать хорошим шагом — агент начинает бескнечно чинить последствия предыдущей генерации. Ты не можешь сказать, где именно пошло не так: модель ошиблась, ты плохо поставил задачу или весь текущий подход изначально тупиковый. Без экспертизы эти три варианта практически неотличимы. Осознанная итерация отличается от брутфорса одним: ты понимаешь, зачем делаешь следующий шаг. У тебя есть гипотеза, ты её проверяешь, видишь результат и делаешь вывод. Брутфорс — это «а попробуй так», «а теперь перепиши это», «а почему опять сломалось». Выглядит похоже, но это разные вещи. ИИ реально может ускорить разработку. Но он с таким же успехом ускоряет хаос, если процесс ведёшь не ты. Агент не знает твою цель лучше тебя. Он просто очень быстро делает то, о чём его просят.

HAR-файл: как QA может сэкономить разработчику полдня Хочу рассказать про штуку, которая экономит мне кучу времени на разборе багов, но почему-то про неё знают далеко не все, особенно ручные тестировщики. Называется HAR-файл. По сути это выгрузка всех сетевых запросов со вкладки Network в DevTools — большой JSON, в котором лежит вся история клиент-серверного общения: что страница запросила, что ответил бэкенд, какие данные ушли с фронта, какие пришли обратно. Полная картина взаимодействия, а не пересказ своими словами. К чему это вообще. Есть классическая боль: прилетает баг, а в описании — видосик с экрана и фраза «вот тут сломалось, пофиксите». Ни ожидаемого результата, ни что именно происходит, ни на каких данных. И ты сидишь и гадаешь, что человек имел в виду и при каких условиях оно вообще воспроизводится. А если баг хоть как-то завязан на данные — что пришло с бэка, что улетело на бэк, какой статус у запроса — HAR закрывает добрую половину этих вопросов сразу. После нормального текстового описания это, наверное, вторая по полезности вещь, которую можно приложить к таске. И самое приятное — снять его это пять секунд. Открываешь DevTools, идёшь во вкладку Network, перезагружаешь страницу, повторяешь действия, которые всё ломают, и жмёшь кнопку выгрузки — стрелочка вниз прямо на панели. Скачается всё, что в этот момент в Network висит. Дальше файл можно просто отдать разработчику или скормить нейронке — она по нему отлично находит, где именно отвалилось, потому что контекст узкий и конкретный, без лишнего шума. Кстати, читать его вручную никто не заставляет. HAR импортируется обратно в тот же Network — рядом с экспортом есть импорт, перетянул файл в панель и смотришь все запросы в нормальном удобном виде, а не вычитываешь мегабайтный JSON построчно. Я как фронт обычно так и делаю: получил HAR от QA, закинул себе, прокликал запросы, нашёл, где данные поехали. Про безопасность. Раньше HAR реально мог утащить с собой куки, токены и заголовки авторизации. Но начиная с Chrome 130 (осень 2024-го) браузеры на хромиуме по умолчанию вычищают из выгрузки куки, Set-Cookie и Authorization. То есть обычная кнопка экспорта теперь отдаёт уже подчищенный файл, и чтобы запихнуть туда чувствительное, надо специально лезть в настройки и включать галку. В обычном сценарии «QA снял HAR и кинул разработчику» паниковать не из-за чего. В абсолют я бы это всё же не возводил: токен или персональные данные могут прилететь в теле ответа, поэтому в публичный чат такое лучше не выкладывать, а коллеге или нейронке — спокойно. Короче, передайте это своим QA. Один раз показать — дальше люди сами цепляют HAR к багам, и жить разработчикам становится гораздо проще.

Есть такая вера в ИИ-тусовке: если результат плохой, значит промпт недостаточно хороший. Напиши подробнее, добавь контекст, уточни формат, разбей на шаги — и всё заработает. Отсюда целая индустрия: гайды по промптингу, шаблоны, курсы, треды с «магическими формулировками». Я не говорю, что это бесполезно. Формулировать задачи для ИИ действительно важно. Но после месяца экспериментов с попыткой сделать игру я очень хорошо прочувствовал одну штуку: проблема часто вообще не в промпте. Проблема в том, что у тебя нет понимания продукта. Можно написать запрос на три экрана, подробный, структурированный, с примерами и ограничениями. Но если ты сам не знаешь, как должна работать архитектура, что считать хорошим результатом и где граница между «ок» и «не ок» — модель не вытащит это из воздуха. Она не умеет читать мысли. Она работает только с тем, что ты сумел сформулировать. Каша на входе — красиво оформленная каша на выходе. Это касается не только игр. Во фронтенде, в дизайне, в текстах, в архитектуре бэкенда — везде одно и то же. «Сделай хороший интерфейс», «напиши нормальную архитектуру», «сделай красиво» — для специалиста за этим стоит опыт, вкус и куча контекста. Для модели без утчнений это просто абстрактные слова. Чем лучше ты понимаешь, что строишь, тем точнее можешь поставить задачу. Чем хуже понимаешь — тем сильнее надеешься, что правильный промпт всё исправит. Хороший промпт — это следствие экспертизы, а не её замена. Учиться формулировать задачи для ИИ полезно. Но ещё полезнее понимать, что именно ты строишь.