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

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 к багам, и жить разработчикам становится гораздо проще.

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

🖥 Frontend с нуля до трудоустройства Путь до Frontend-оффера — это не только обучение, но и собеседования, резюме и ATS-фильтры. И у большинства кандидатов проблемы повторяются на одних и тех же этапах. 💼 Мы собрали материалы для каждого шага: — ATS и разбор резюме — база реальных Frontend собеседований — задачи с собесов в BigTech — System Design для Frontend — инфраструктура больших приложений — сообщество фронтендеров — курсы по React, TypeScript и FSD

📍 В закрепе найдёшь материалы для каждого этапа пути до оффера.

👉 Ссылка на канал

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

Компьютеры для любых целей — выбирайте в BAZA! • Офисный ПК — тихо и надёжно • Игровая машина — для самых требовательных • Рабочая станция — монтаж видео и 3D • Система для программирования и обучения Каждый винтик на своём месте, вольтаж и CMP-профили оптимизированы. Гарантия до 3 лет, поддержка на всю жизнь и сборка за пару дней!

🔴 Через 5 минут начинаем Вайбкодим личный сайт через ИИ-агента. 📍 [YouTube] и ре-стрим на [Rutube] Забегайте в чат

🔔 Сегодня в 20:00 МСК — стрим Буду вайбкодить личный сайт через ИИ-агента: скормлю ему резюме, наговорю цели и посмотрим, сможет ли он собрать что-то нормальное без ручного кода. 📍 [YouTube] и ре-стрим на [Rutube] 💬 Буду рад всех видеть в чате

Можно ли собрать личный сайт через ИИ-агента, если просто скормить ему резюме, голосом объяснить цели и не писать код руками? Вот это и проверим на стриме. Буду вайбкодить свой личный сайт: закину актуальное резюме, наговорю пожелания по структуре и дизайну, расскажу про стек и посмотрим, что из этого получится. Будет лампово: сайт на фоне, болтовня про фронтенд, ИИ, вайбкодинг, резюме и ответы на вопросы в чате. 🗓️ Когда: 10.06 (среда) в 20:00 МСК 📍 Где: [YouTube] и ре-стрим на [Rutube] ⏱️ Длительность: ~3 часа

Как строить карьеру в IT и не раствориться в работе. Я backend-разработчик и футбольный энтузиаст с системным подходом к спорту. Играю в разных странах и с разным уровнем соперничества: от локальных матчей до турниров в Азии. В канале пишу: — о личном опыте лида в IT и реальных технических решениях 👨‍🎓 — о развитии своих проектов и о том, чему они учат 📈 — о футбольных движухах в разных странах 🏃‍♂️ — о том, как не терять форму при плотной работе 💪 — о лайфстайле зимовщика 🧘‍♀️ Без мотивационных лозунгов. Без «успешного успеха». Только практика, дисциплина и честные наблюдения. 👉 Футбольный синьор Если вам близка идея баланса между карьерой и личной жизнью и интересно заглянуть за кулисы IT, добро пожаловать на канал.

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

👩‍💻 Всем программистам посвящается! Вот 14 авторских обучающих IT каналов по самым востребованным областям программирования: Выбирай своё направление: 👩‍💻 Frontend — t.me/frontend_ready 📱 JavaScript — t.me/javascript_ready 👩‍💻 IT Новости — t.me/it_ready 🤖 AI & ML — t.me/neuro_ready 👩‍💻 Python — t.me/python_ready 🤔 InfoSec & Хакинг — t.me/hacking_ready 🖥 SQL & Базы Данных — t.me/sql_ready 👩‍💻 C/C++ — https://t.me/cpp_ready 👩‍💻 C# & Unity — t.me/csharp_ready 👩‍💻 Linux — t.me/linux_ready 👩‍💻 Java — t.me/java_ready 📖 IT Книги — t.me/books_ready 🖼️ DevOps — t.me/devops_ready 🖥 Design — t.me/design_ready 📌 Гайды, шпаргалки, задачи, ресурсы и фишки для каждого языка программирования!

Месяц пытался сделать игру с помощью ИИ. Поделюсь, где сломался. В детстве я хотел делать игры. Не казуалки на вечер, а нормальные — с атмосферой, механиками, исследованием, погружением. Ближе к 18 годам у меня даже был наивный план: поступлю в универ, пойду в геймдев, буду делать свои миры. Потом примерно в 2014 году я столкнулся с реальностью: C++, математика, физика, движки, высокий порог входа. Нейронок тогда не было, нормальных материалов было меньше, настаника рядом тоже никакого не было. Всё это ощущалось не как «интересный челлендж», а как бетонная стена. Мечта тихо ушла в долгий ящик, а я в итоге пришёл во фронтенд — HTML, CSS и JavaScript на фоне геймдева выглядели как вход через нормальную дверь, а не через окно второго этажа. И вот появляются мощные нейронки, агенты, ассистенты в IDE — и мысль возвращается: а вдруг теперь можно? Не AAA, не клон GTA с одного запроса, я не настолько поехавший. Но хотелось попробовать сделать что-то, что хотя бы ощущается как настоящая игра: простенький 3D survival, что-то по вайбу Subnautica, может изометрический экшон. Не змейку, не кликалку, не браузерную игрушку на вечер. Около месяца я крутился вокруг этой идеи: смотрел в сторону Unity, пробовал разных ассистентов, гонял агентов, пытался понять, как вообще подступиться к такой задаче. И вот в чём прикол: я упёрся не в слабость ИИ. ИИ как раз мощный — объясняет, генерирует код, предлагает шаги, помогает быстрее влезать в незнакомую тему. Я упёрся в себя. У меня нет геймдев-экспертизы. Я не понимаю архитектуру игрового проекта, не понимаю жанровые механики на нужном уровне, не умею нормально разбивать разработку на маленькие проверяемые этапы. Во фронтенде я могу работать с ИИ осознанно, потому что понимаю контекст: могу проверить код, увидеть странное решение, остановить модель, направить её. В геймдеве я чаще оказывался в позиции человека, который смотрит на сгенерированный результат и такой: ну… вроде что-то происходит. Можно написать огромный промпт: сделай 3D survival с исследованием, базой, ресурсами, атмосферой и нормальным управлением. Звучит мощно. Но если у тебя в голове нет чёткой картины, как это должно работать, модель её за тебя не придумает. У неё нет телепатии. Каша на входе — красиво оформленная каша на выходе. ИИ снижает порог входа, но не отменяет путь. Чтобы сделать игру с ИИ, всё равно нужно учиться делать игры — понимать жанр, механику, архитектуру, этапы разработки, критерии качества. Большой промпт не заменяет экспертизу: он усиливает её, если она есть, и очень быстро обнажает её отсутствие, если её нет. Так что нет, игру мечты с одного промпта я не сделал. Зато хорошо прочувствовал одну мысль: чтобы сделать что-то стоящее, всё ещё нужно разбираться в том, что ты делаешь.

Решать технические задачи — самая простая часть работы в IT. Сложности начинаются там, где нужно договариваться со смежниками, выстраивать процессы в хаосе и осознанно управлять карьерой. В канале @ulshinblog Никита (руководитель разработки в Highload, 10+ лет в IT) разбирает эти темы через понятную логику и личный опыт: 📍 Как лоуперформеры уничтожают команду и сжигают мотивацию сильных инженеров; 📍 Защита от плохой обратной связи: как вежливо поставить на место коллегу с неконструктивным фидбеком; 📍 Инженерный конвейер самообучения: как перестать читать книги для галочки и внедрять знания в жизнь и карьеру; 📍 Как пройти секцию System Design? Пошаговый чек-лист от интервьюера; 📍 Как находить внутренние сайд-проекты, которые принесут пользу и бизнесу, и вашему карьерному росту; 📚 База 50+ авторских обзоров IT-литературы для сильного инженера: разработка, управление, архитектура, мышление. 👉 Присоединяйтесь erid: 2W5zFHezBVB

React | Frontend и ВАЙБКОДИНГ | Работа в BigTech | Сокращения | Накрутка опыта | Александр Ламков В гостях - Александр Ламков. Это уже второй подкаст с Александром, и в этот раз мы честно поговорили про современный найм в IT, как сейчас устроиться в BigTech, что происходит с сокращениями, почему все обсуждают вайбкодинг и как меняется React-разработка из-за ИИ. Без инфоцыганства и «успешного успеха»: 🔤 как реально искать работу в IT 🔤 почему рынок стал жёстче 🔤 заменят ли нейросети разработчиков 🔤 нужен ли React в 2026 году 🔤 как сейчас попасть в BigTech 🔤 правда ли, что без накрутки опыта стало сложно Где смотреть?🖱 📺 YouTube 📺 VK Video (загружается) Где слушать? 🔵 Wave 🎙Podcasts.apple.com 🎵 Подкасты на Яндекс 💳Звук Поддержите видео лайком, комментом или подпиской 💓

Поймал себя на мысли, что во фронте сейчас самое сложное — это вообще не новый фреймворк и не CSS. Это нормально продолжать учиться, когда ты уже как бы «в профессии». Рынок едет, инструменты меняются каждые полгода, ИИ лезет почти везде. А старая схема «прошёл курс — получил скилл — спокойно работаешь» как-то незаметно перестала работать. Не то чтобы сломалась — просто выглядит уже немного наивно. Почитал канал «На уровне системы». Его ведёт Валерий Ляшенко, пишет про образование, карьеру, ИИ и про то, как вузы, студенты и бизнес пытаются хоть как-то состыковаться. Подкупило то, что там не мотивационные лозунги, а разбор по сути: где обучение реально что-то даёт, а где просто красиво называется. Особенно зашли посты про то, что ИИ усиливает не всех подряд, а только тех, кто умеет думать. И про то, почему программы в ИТ надо обновлять постоянно, а не раз в пятилетку. Для нас это вообще не отвлечённая история — мы сами почти всё время в роли студентов, только без расписания и куратора. Канал тут: https://t.me/+B79yzkLfOdo5NDgy

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

⌨️ Я перестал печатать промпты Раньше я искренне считал, что текст — мой главный инструмент общения с нейронкой. Логика была простая: пять лет в разработке, куча технических постов, документация, сценарии для ютуба, посты в телегу. Печатаю быстро, мысли формулирую нормально — зачем мне вообще что-то наговаривать, если я могу написать это чище и точнее? К тому же мне казалось, что сам процесс печатания — это уже половина работы. Пока пишешь промпт, ты его перечитываешь, что-то поправляешь, и в итоге отправляешь нейронке уже более-менее осмысленную задачу, а не сырой поток мыслей. Поэтому когда друг рассказал, что почти не прикасается к клавиатуре и просто наговаривает всё агенту голосом, я отнёсся к этому скептически. Ну типа — окей, может тебе так удобнее, а мне норм и так. А потом до меня дошла довольно простая мысль. Нейронка ведь не умная. Вообще. Она не мыслитель, она обработчик информации. И её настоящая сила не в том, что она что-то придумывает, а в том, что она перемалывает огромный объём текста за секунды и вытаскивает оттуда суть. И если смотреть на неё под таким углом, то становится понятно: ей вообще пофиг, насколько красиво и структурно ты сформулировал запрос. Хоть запинайся, хоть перескакивай с мысли на мысль, хоть говори с ошибками — она всё равно соберёт из этого концентрат и сделает то, что тебе нужно. Промпт, пост, сообщение, разбор задачи — что угодно. И тут я вспомнил про эффект утки. Это когда ты берёшь резиновую уточку, ставишь её перед собой и начинаешь ей рассказывать задачу. Со стороны выглядит как лёгкая шиза, но работает на удивление хорошо — пока проговариваешь вслух, сам начинаешь понимать, где затык. Так вот нейронка — это уточка на стероидах. Она не просто слушает, она ещё и подхватывает твои полусырые мысли и вытаскивает их на нормальный уровень. Тебе достаточно довести идею до 30 процентов, остальное она доформулирует сама. В итоге я перестроился. Не полностью, конечно, текстом я тоже пишу, когда задача маленькая или хочется точности. Но большие, размытые штуки теперь чаще наговариваю. Получается быстрее и, что неожиданно, часто качественнее — потому что в голосе остаётся больше контекста и нюансов, которые при печатании я бы поленился расписать.

Какой идеальный возраст для входа в IT? 18, 20, 25 лет? Знакомьтесь — Иван. 39 лет. Всю жизнь работает в продажах. В 37 лет понял — надоело и пошел учить код. В таком возрасте нормальные мужики покупают мотоцикл, а он купил курс по PHP. Его жена в шоке) Рассказывает все публично — что пилит, что ломает, сколько зарабатывает. Спойлер: пока ноль. Но он не отчаивается и идет к своей цели. Интересно? Вот ссылка → // ToDo: офис подождет

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

👔 Ты не обязан любить программирование Большинство разработчиков, которых я знаю, не любят программировать. Они любят когда что-то работает. Когда задача закрыта, кнопка нажимается, данные отображаются. Сам процесс — часто скучный, иногда бесящий, редко вдохновляющий. И это нормально. Я не понимаю, откуда взялась идея, что надо прямо гореть кодом, засыпать с мыслями о замыканиях и просыпаться с желанием порефакторить что-нибудь для души. Это не про большинство людей в профессии. И те, кто так говорит — либо исключение, либо немного привирают. Работа — это работа. Кто-то любит результат своего труда, но не сам труд. Это не дефект характера и не повод менять профессию. Хирург не обязан кайфовать от самого разреза. Бухгалтер не должен засыпать с мыслями о дебете. Почему разработчик должен обожать дебаггинг в пятницу вечером? Вредность этой установки в другом — она давит на людей, которые просто нормально работают. Делают задачи, получают зарплату, живут дальше. И начинают думать, что с ними что-то не так, раз они не пишут код на выходных для удовольствия. Хотя на самом деле они просто… взрослые люди с нормальным отношением к работе. На карьеру это влияет ровно никак, если ты нормально делаешь своё дело. Страсть к коду — не навык и не компетенция. Это просто черта характера некоторых людей. Романтизировать её как обязательное условие успеха — странно.​​​​​​​​​​​​​​​​