Почему нельзя просто взять и сделать отечественный процессор побольше?

Разработчики “Герои 3” как-то поделились лором: события игры вообще-то происходят в далеком будущем, а вся эта магия и расы - просто забытые технологии.

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

Пока в этом копался, задался тупым, но честным вопросом. В России умеют делать процессоры, но сильно отстают по техпроцессу. Почему бы просто не сделать чип физически больше? Ну да, будет жрать электричество, но инженеры же могут это решить?

Чтобы понять, почему идея не рабочая, пришлось нырнуть в то, как песок вообще превращают в мозги для компа.

Оказывается, сначала из очень чистого кремния(песок буквально) выращивают болванку и режут её на диски (зеркальные блины). Потом по этому блину бьют лазером через трафареты. Выжигают миллиарды транзисторов, тянут медные дорожки и строят нано-город. На один блин влезают сотни процессоров. В самом конце его шинкуют на квадратики, которые называют кристаллами. Дальше кристалл клеят на плату, закрывают крышкой - и всё, процессор готов.

Размер кристалла нельзя раздувать просто так, тут сразу несколько причин.

Экономика и банальная пыль.

Блины на заводах не бывают идеально чистыми. Из одного блина выходит 500 мелких кристаллов, случайная пылинка запорет два-три. Брак копеечный. Но если резать огромные куски, их на блине поместится штук десять. Одна пылинка — минус 10% партии. А если их с десяток, весь блин летит в помойку. Себестоимость такого гиганта просто улетит в космос.

Синдром утюга.

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

Скорость света.

Тут мы тупо бьемся о фундаментальную физику. Чем больше кристалл, тем дольше сигнал идет от одного края до другого. В огромном процессоре ток просто не успеет пробежать это расстояние за один такт.

Ладно, если делать один кирпич бессмысленно, почему не воткнуть в материнку два обычных процессора?

На серверах так и делают. Но для домашнего компа это боль. Два камня постоянно тратят время на перекличку. Пока они кидаются данными, игра или тяжелый софт начнут жестко лагать из-за задержек.

Но есть изящный выход. Эту фишку обкатала AMD, когда начала отставать по тех-процессу и это чиплеты. Процессор не льют единым куском, а собирают на подложке из мелких кристаллов. Один считает, другой рулит памятью. Это дешево, решает проблему пыли на блинах и обходит кучу физических лимитов.

Я подумал: блин, для наших процессоров это же идеальный путь!

А потом уткнулся в реальность. Чиплеты круто работают, когда ты можешь печатать их мелкими. А у нас заводы вроде “Микрона” уперлись в 65–90 нанометров. Тайваньская TSMC, которая печатала сложную мелочь, маршрут закрыла из-за санкций.

Полез с детским вопросом “почему не сделать побольше”, а понял, что микроэлектроника - это место, где в одной точке бьются лбами физика, экономика и геополитика. Простые решения тут давно не работают.

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

Дебаж 🐞с ноги 🦶

Чем заменить Cursor на корпоративном ноуте

Последнюю неделю я пытаюсь выжить, совмещая основную работу с хакатоном. По идее, вывозить такую двойную нагрузку должен помогать spec-кодинг. Обычно для этого я просто открываю Cursor, но на работе его юзать нельзя (секьюрность), запрет на отправку кода во внешние API и всё такое. А писать всё руками после ИИ-ассистентов уже физически больно.

Пошел искать open-source альтернативы, чтобы можно было секьюрно spec-кодить через локальные и корпоративные LLM. Эксперименты с KiloCode с треском провалились, ну не нравится он мне. В итоге обновил стек на рабочем Маке и собрал такой сетап:

1️⃣ IDE Void - форк VS Code. Накатил туда все Java/Kotlin аддоны, подрубил MCP Atlassian, и теперь Qwen3-Coder-480B пытается писать код за меня. Как генератор - 🔥 . Правда, с Kotlin у LLM всё ещё не так гладко, как с Python или JS, поэтому генерирую я в Void, а ревьюить и дебажить всё равно ухожу в родную IDEA.

2️⃣ browserOs - форк Chromium со встроенным ИИ-чатом (аналог Comet от Perplexity, но работает с любыми LLM по API). Продукт местами сыроват, но главная фича реализована достойно. Самая большая боль - это дебильный рыжий логотип с собакой. Мой мозг отказывается ассоциировать это с браузером, и при переключении через Cmd+Tab я вечно не могу его найти.

Забавно, что на самом хакатоне я сейчас пилю инструмент, который решает похожие корпоративные боли enterprise-аналог NotebookLM. Суть простая: закидываешь в диалог с корпоративной LLM ссылки на внутреннюю Jira, Confluence или TestOps, а ИИ всё это переваривает и помогает по работе. Дали доступ к мощным моделям типа нового DeepSeek-V4, и результаты прям огонь.

И вот смотрю я на свой новый рабочий сетап и понимаю: апка, которую я делаю на хакатоне, идеально ложится в этот локально-корпоративный стек. Особенно если упаковать её в десктоп.

А может вообще вкатиться с ней в свой первый open-source?

Дебаж 🐞с ноги 🦶

Google снёс моё расширение за спам ❌

Захотел установить свой же Extract Text From Picture, иду в поиск (из прикольного: по запросу я на первой странице Google!), кликаю по ссылке, а там: This item is not available.

Пошел проверять почту. Chrome Web Store действительно прислал “письмо счастья”: удалили за нарушение политики Spam and Placement in the Store.

Пошел искать правду по чатикам разработчиков и выяснил, что проблема массовая. Походу, Google выкатил новый алгоритм модерации, который жестко триггерится на количество локализаций. А у меня их было аж 52 (привет, ASO-оптимизация).

Что буду делать дальше? Из хорошего: тип реджекта yellow 🟡. Это значит, что бан не перманентный, а предупреждающий, и проект можно спасти. План такой: временно дропаю все 51 перевод, оставляю только английский язык и отправляю на повторную модерацию. Посмотрим, как быстро пропустят.

Дебаж 🐞с ноги 🦶

Прокрустово ложе

В недавнем видосе я рассказывал, что сейчас читаю Талеба (в частности, его идеи вокруг “Антихрупкости”). И вот на днях на работе поймал идеальный личный пример одной из его любимых метафор Прокрустова ложа.

Суть там в чем: в мифе разбойник Прокруст укладывал гостей на свою железную кровать. Если человек был слишком длинным, то он отрубал ему ноги, если коротким - вытягивал суставы. Талеб переносит это на нашу жизнь: когда живая, сложная реальность не влезает в наши жесткие модели и системы, мы предпочитаем обкорнать реальность, лишь бы она поместилась.

А теперь к практике. Как говорят таксисты: блог и инди-хакинг - это для души, а вообще у меня и настоящая работа есть. Я бэкенд-лид в команде, которая пилит платформу для масс-найма (курьеры, сборщики).

Недавно обсуждали с ребятами, почему в какой-то момент автоматизация процессов начинает буксовать: фича обходится дорого, а позитивного эффекта от нее всё меньше. Оцифровать ведь можно только то, что уже жестко формализовано.

А дальше классика: 20% эйчаров закрывают 80% вакансий. И тут возникает моя самая наивная мысль: ну так давайте пилить фичи специально под этих топов!

Но тут кроется засада. Выясняется, что процессы самых эффективных ребят очень сложно загнать в рамки. У них свои паттерны, подходы, интуиция. И когда пытаемся натянуть на них стандартный флоу, мы строим для них то самое Прокрустово ложе. Пытаясь впихнуть нестандартного, сильного спеца в удобные для системы формочки, мы буквально “отрубаем ему ноги”. Мы заставляем его работать “как положено”, лишая тех самых фишек, которые и делали его звездой.

Получается забавный парадокс: классическая автоматизация мешает сильным, но отлично помогает “слабым”. Среднего сотрудника надо меньше учить, он быстрее вкатывается. А если он уйдет, найти замену гораздо проще, а порог входа сильно снижается за счет жесткого и автоматизированного рабочего процесса.

Как наброс на будущее: возможно, дальше мы придем к персональной автоматизации. Когда не человек подстраивается под приложение, а интерфейсы собираются под конкретного спеца и его стиль работы. Грубо говоря: когда мы научимся с помощью ИИ на лету менять размер кровати, а не рубить людям ноги.

Дебаж 🐞с ноги 🦶

Я решил собрать гаджет от головной боли

Знаете это чувство, когда всё вроде делаешь правильно: спишь по 8 часов, пьёшь воду, ходишь норму шагов, пульс как у космонавта, а голова к вечеру всё равно гудит и глаза устают?

Я затрекал всё тело, и данных оказалось недостаточно. Поэтому появилась гипотеза: возможно, проблема не во мне, а в моей рабочей среде.

Решил сделать полезную штуку лично для себя: затрекать рабочее место. Форм-фактор: умная настольная лампа.

План на MVP такой: Следим за CO2, влажностью, температурой и освещённостью. Плюс добавил напоминалку поморгать (звучит смешно, но я в фокусе реально перестаю это делать).

И самое спорное это трекать магнитные поля и радиочастоты. Включаю режим конспиролога: а вдруг мои Bluetooth-наушники незаметно варят мне мозг излучением? Наука, конечно, крутит пальцем у виска и говорит, что всё ок, но я хочу собрать свои данные. Надо же либо окончательно успокоиться, либо идти клеить шапочку из фольги.

Рулить железом будет ESP32-S3 дешёвая и холодная, в отличие от Raspberry Pi. А вот думать будет отдельный сервер с языковой моделью. Шутки про «ИИ везде» принимаются, но мне реально нужно, чтобы железка просто говорила по-человечески: «душно - открой окно», а не заставляла меня вчитываться в дашборды.

Детальки заказаны, скоро буду собирать прототип.

Дебаж 🐞с ноги 🦶

За последние пару недель в Кулере появилось много всего: счётчики переходов по ссылкам из постов, генератор коротких ссылок, даже страничка-визитка - вот моя: cooler.debug-leg.ru/my-link/debug-leg

Но главного: кросспостинга в VK с фото до сих пор нет. И вот почему.

Я думал, это будет просто. Создал API-ключ в группе VK, дал ему права на стену, фото, файлы, потом попросил ИИ написать код. Первая публикация прошла. Текст лёг на стену как надо. Добавил фото и сразу ошибка:

error_code: 27 — Group authorization failed: method is unavailable with group auth.

Окей. Гуглю. Оказывается, для загрузки фото нужен пользовательский токен, а не токен сообщества. Иду за ним. Получаю:

error_code: 15 — Access denied: no access to call this method with current scopes.

Расширенные права? Пишу на devsupport@corp.vk.com. Ответ:

Из-за изменения политики дистрибуции API-методов расширенные API-доступы больше не выдаются.

Кольцо замкнулось. Токен сообщества - нельзя. Пользовательский токен - нельзя. Расширенные права - не дают.

Я пока не понимаю: это я что-то упускаю, или VK тихо закрыл эту возможность и просто не обновил документацию?

Кто-нибудь встречался с VK API и получал что-то кроме боли? 👇

ChatGPT на собесе: инструкция по провалу

На прошлой неделе провёл два техсобеса на Kotlin-разработчика и в очередной раз словил абсолютный кринж: кандидаты пытаются проходить интервью с ChatGPT, и делают это максимально тупо.

Почему-то люди думают, что если они не шарят экран, то собеседующий ничего не замечает. Но вот как выглядит этот «стелс» на практике:

*️⃣ Стук клавиш. Я задаю вопрос, человек задумчиво молчит, зато в микрофон радостно начинает лупить механическая клавиатура. Напокупали себе кастомных механик с громкими свитчами, а теперь палятся на первом же промпте.

*️⃣ Светомузыка на лице. Кандидат сидит в полутёмной комнате, и ровно после моего вопроса его лицо внезапно озаряется белым светом - открылась спасительная вкладка браузера.

*️⃣ Бегающий взгляд. Прямо на камере видно, как глаза двигаются влево-вправо, считывая строчки сгенерированного текста.

Как выглядит сам диалог с таким «киборгом»?

Например, прошу объяснить, что такое ACID. Кандидат сначала зависает на 5–7 секунд. Мнётся, выдаёт невнятное мычание в духе «ну… это короче про базы данных и надежность».

А потом в него вселяется Википедия. Он внезапным дикторским голосом начинает чеканить:

ACID — это Atomicity, Consistency, Isolation, Durability…

и выдает все расшифровки книжным языком. Переход от “не могу связать два слова” к “я лектор по базам данных” занимает ровно одну загрузку ответа.

И это не моя личная паранойя. В Huntflow я всё чаще вижу в карточках от других интервьюеров пометки: “кажется, использует ИИ”, “вероятно, зачитывает ответы с экрана”.

Как я на это реагирую в моменте? Не рублю с плеча и не устраиваю сцен. Сначала даю шанс, пытаюсь помочь наводящими вопросами. Но когда понимаю, что человек на том конце провода не рассуждает, а просто работает кожаным интерфейсом между мной и LLM,  я перестаю его вытаскивать. Просто прогоняю по оставшимся вопросам в x2 скорости и сворачиваю звонок.

Знаете, в чём главная ирония? Я вообще не из лагеря морализаторов: обманул на собесе - в ад.

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

Кринж в другом. Взрослые инженеры ведут себя как напуганные школьники, неумело списывающие у доски. Собеседование — это не экзамен, это попытка найти себе адекватного коллегу. А по итогу получается просто трата времени.

Дебаж 🐞с ноги в TG, VK и Дзен

Как я сжег $60 в Cursor за 3 дня и понял, что флагманские LLM - это оверпрайс для рутины

Сейчас я с головой погружен в разработку Кулера. И на днях впервые уперся в лимит подписки Cursor Pro. Закинул еще $20, потом еще $20 и всё это меньше чем за три дня. Спойлер: эти деньги сгорели всего на половине фичи (сокращатель ссылок + счетчик переходов).

Я сидел на Claude Sonnet 4.6 и пробовал Opus 4.7. И вот на какой задаче до меня дошло, что я делаю какую-то херню.

Мой стек это React + Supabase. Прошу Opus сгенерить логику, а эта нейросеть за $25/1M токенов на серьезных щах пишет код, который тянет из базы все посты сразу, забив на батчи и даты публикации.

И тут пазл сложился. Флагманские модели - это эксперты во всём. Opus 4.7 шарит в молекулярной биологии и может написать эссе про пирамиды Хеопса. Но когда мне нужно накидать очередную формочку, я переплачиваю за всю эту мировую эрудицию, стреляя из пушки по воробьям.

Если мне всё равно нужно давать детальные инструкции и бить ИИ по рукам за детские архитектурные косяки, зачем платить х10? Встроенный Composer 2 (где токен стоит $2.50) при нормальном входном контексте отлично генерит базовый код.

В итоге я вывел для себя такой воркфлоу, чтобы соблюдать баланс цены и качества:

1️⃣ Базовая разработка (формочки, CRUD, бойлерплейт) - по умолчанию сижу на легком Composer 2.

2️⃣ Проектирование и архитектура - иду обсуждать в Perplexity.

3️⃣ Реально сложная логика - переключаю ручками на что-то от Antropic, опираясь на чутье разработчика.

P.S. Перечитал сейчас свой текст. Звучу как динозавр из мира C++, который хейтит Python и ворчит про лишние слои абстракции и оптимизацию.

Чебурнет или как перестать хоронить мир и начать пилить продукт

Последние две недели я тупо смотрел в IDE и не мог написать ни строчки. Пока Cursor пытался генерить за меня код, я думскроллил новости про чебурнет, листал вакансии на HH и всерьез думал, а не уехать ли в Минск.

В какой-то момент понял: всё, стоп, приехали. Я пробил дно продуктивности. Такое состояние у меня уже бывало пару раз, так что алгоритм выхода из пике мне знаком. Решил вырубать тревожность радикально.

Вот мой стек по борьбе с кукухой за последние 5 дней:

1️⃣ Жёсткий инфодетокс

Отписался вообще от всех новостных каналов в Телеге. ФотоГрам и YouTube у меня и так физически лежат на другом телефоне, так что там залипать не выходило.

2️⃣ Пережил ломку по новостям

Самым сложным было перестать рефлекторно хватать телефон каждые 15 минут, чтобы проверить, не начался ли апокалипсис. Договорился с собой: если случится что-то реально важное, я всё равно об этом узнаю либо на утреннем дейлике, либо из очередного мемаса.

3️⃣ Физика

Урезал кофе (совсем исключить пока не вышло) и начал гулять по утрам перед работой. Строго без наушников, музыки и подкастов: просто чтобы проветрить голову.

Итог:

Меня отпустило. Я перестал переживать о том, куда катится мир. Но самое крутое - все эти разговоры про блокировки меня так выбесили, что я психанул, сублимировал тревогу в код и наконец-то начал пилить свой пет-проект сервис кросспостинга.

Cursor — это не чат в IDE

Я бекенд‑разработчик.
И я с помощью Cursor собрал расширение для браузера: Speech‑to‑Text и Extract Text from Picture.

До этого я честно пытался делать то же самое в чатах OpenAI / Grok / DeepSeek.
Сценарий всегда один: контекст расползается, требования приходится повторять, а иногда чат просто зависает — и я делаю всё заново.

После этого я перестал относиться к LLM как к переписке и начал относиться как к рабочему месту: проект + файлы + правила + Git.

Мой принцип

Мне не нужен «идеальный промпт».
Мне нужен процесс, который не убивает мой день, когда модель поехала не туда.

С чего начать (мой чеклист)

Это реально можно собрать за вечер.

I. Intro

• Коротко понять, почему модель то попадает, то мимо​

• База про правила (Rules)​

II. Rules: сделай «рамки» работы

Я не могу отдать свои правила (там много личного/проектного), но логика простая: rules — это договор, как Cursor работает в моём репо.​

Мой минимум, который почти всегда даёт буст:

• Перед ответом смотри /README.md и /docs/.

• Если не хватает данных — задай до 3 вопросов и только потом действуй.

• Любые правки кода — маленькими порциями; после шага пиши, какие файлы изменил.

• Если задача большая — сначала Plan, потом Agent.

Если лень писать с нуля — я иногда беру за основу готовые developer rules и допиливаю под себя:

• TypeScript rules​

• Front-end rules​

Хак: rules можно дописывать прямо по ходу работы — я часто прошу агента «сформулируй правило, чтобы мы больше так не делали», и добавляю его в проект.

III. Положи «источники правды» в репу

Тут мой единственный принцип: всё, что я устал повторять — я выношу в файлы.

Пример структуры, которую я делаю для большинства задач:

project/
  README.md
  docs/
    business-requirements.md
    tech-spec.md
    decisions.md
  src/
  research/

README.md — одна страница «что строю и зачем».
docs/ — требования и решения (чтобы не хранить их в голове и в чате).

IV. Режимы: я не жму Agent сразу

Я использую три режима:

• Ask — когда хочу разобраться/проверить идею и ничего не ломать.​

• Plan — когда задача больше пары часов: сначала план и вопросы.​

• Agent — когда план ок: он уже правит файлы и двигает задачу.​

И два хака, которые у меня реально помогают:

• Хак 1: я спрашиваю у самого агента в Cursor, какую модель лучше взять под мою задачу.

• Хак 2: я стараюсь не использовать авто-режим — автоматически Cursor часто подбирает модель неудачно.

V. Бизнес‑дока → Tech Spec

Я не начинаю с “какой стек лучше”.

У меня уже есть привычный стек (я писал про него тут), и мой первый вопрос к Cursor другой: могу ли я остаться на нём под эти бизнес‑требования или мне придётся делать иначе (и почему).​

Дальше я делаю так:

1. Пишу бизнес‑требования простыми буллетами в /docs/business-requirements.md.

2. Прошу Cursor собрать Tech Spec: API + архитектура + риски + edge cases.

3. И только потом иду в код.

Пример (упрощённо, мой кейс с промокодами):

• Пользователь присылает сообщение с промокодом.

• Промокод валиден, если: сейчас в диапазоне date_from..date_to и пользователь ещё не использовал его.

• Если валиден — отправляю ответ: текст/фото (если есть) + кнопки с доступными подписками.

• В момент покупки я обязан ещё раз проверить, что промокод активен.

• После покупки подписки типа PROMO_CODES помечаю промокод использованным.

Где Cursor меня подставлял (и что я делаю)

Главный минус: LLM плохо исправляют ошибки, если уже “врубились” в неправильную реализацию.

Поэтому у меня репозиторий всегда под Git (или я работаю с включённой системой контроля версий).

• Каждая фича — отдельный коммит (или ветка, если страшно).

• Если вижу, что оно поехало не туда и прогресса нет — откат и делаю заново, но с более точными вводными/планом.

На этом всё.
Я показал подход, который у меня прижился: собрать в Cursor нормальное рабочее место, где ИИ работает “по проекту”, а не “по настроению”.

Если тема заходит — я регулярно пишу про инди‑разработку и свои эксперименты в ТГ: https://t.me/debug_leg

А ты доверяешь своему проекту?

Для Cursor или любого другого VSCode‑форка есть ненулевая вероятность, что при открытии чужой репы IDE тихо запустит какие‑нибудь скрипты в фоне.​

Недавно наткнулся на историю: человек скачал репозиторий с автономным ИИ‑агентом "просто посмотреть код", открыл папку в Cursor и IDE сразу сама запустила какие‑то node‑скрипты в терминале. Без единого клика. Спасло его только то, что данные были зашифрованы, пароли в менеджере, а крипта в холодном кошельке.​

Откуда вообще берётся риск

• В классическом VSCode есть Workspace Trust — та самая модалка "доверяете ли вы этому воркспейсу?", от ответа зависит, можно ли запускать расширения и скрипты.​

• Есть Tasks с режимом runOn: folderOpen, который позволяет запускать скрипты при открытии папки. Удобно для честной автоматизации и идеально для атаки.​

• В чистом VSCode это завязано на trust. А вот в Cursor, по их же документации, workspace trust по умолчанию отключён и никакого лишнего вопроса вы просто не увидите.​

В результате злоумышленнику достаточно положить в репозиторий tasks, которые стартуют при открытии папки, и дождаться, пока кто‑то откроет эту репу в форке с выключенным trust. Node‑скрипт в таске имеет доступ к ОС, а дальше полёт фантазии, от телеметрии до кражи ключей.​

Что можно сделать прямо сейчас

Минимальный чек‑лист:

• включить workspace trust;

• отключить автоматический запуск tasks.​

В settings JSON это две строки:

"security.workspace.trust.enabled": true,
"task.allowAutomaticTasks": "off"

После того как прочитал эту историю, первым делом пошёл и проверил свои настройки IDE.

Если такие практичные разборы про разработку, безопасность и реальные кейсы из проектов заходят — у себя в Telegram‑канале регулярно разбираю подобные штуки и показываю, как это влияет на живые продукты. Ссылка на канал.

Железо в ипотеку: почему разработчикам снова придётся считать память⁠

Друг недавно пошёл купить планку памяти на 16 ГБ и вернулся с ощущением, что железо скоро будут продавать в ипотеку.

Он зацепился за простую мысль: оперативка есть везде — в компьютерах, телефонах, приставках, серверах. Если память дорожает, значит очень быстро подорожает всё остальное железо.

Для разработчиков это неприятный звоночек. На мобилках и десктопах подход «и так сойдёт, железо вывезет» будет работать хуже: более дешёвые устройства, больше экономии на начинке — значит, снова придётся думать про оптимизации, вес приложений, количество абстракций и то, что реально нужно тащить в рантайм.

На бэке привычное временное решение «завалим проблему железом» (которое по традиции становится постоянным) тоже перестаёт быть очевидным. Если память, GPU и виртуалки дорожают, то горизонт «давайте просто докинем ещё один инстанс» превращается в всё более дорогой вид спорта.

С другой стороны, на всё это сверху уже наезжает волна сервисов и приложений на LLM, сделанных без особых мыслей про ресурсы. Если виртуалки и GPU подорожают, LLM‑API, скорее всего, тоже станут дороже, а значит, экономика части проектов, построенных по принципу «шлём всё в большую модель и не паримся», может просто перестать сходиться.

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

Вопрос к читателям: если железо и облака ещё подорожают, вы скорее пойдёте в жёсткую оптимизацию всего или просто заложите рост себестоимости в цену продукта?

Если такие разборы интересны, в Telegram делюсь ещё и практикой: как считаю экономику своих фич и LLM‑штук на реальных проектах.

Как Cursor помог переписать браузерное расширение за 2 часа: опыт миграции на единый стек

Последние пару недель занимаюсь унификацией технологического стека для всех своих pet-проектов и поделок. Цель — собрать единый тех-радар, чтобы не тратить время на переключение контекста между разными фреймворками и библиотеками.

Мой стек

Frontend:
- React (без сюрпризов)
- WXT (лучший фреймворк для браузерных расширений)
- MUI (библиотека UI-компонентов под Material Design)
- Netlify (бесплатный и надёжный хостинг)

Backend:
- Supabase (как Firebase, только лучше)
- Yandex Cloud (serverless-контейнеры + S3-хранилища)

Процесс

На выходных добрался до Speech to Text — браузерного расширения для транскрипции аудио. Оно было написано на vanilla JS ещё в первых версиях, и каждое обновление превращалось в квест по поиску багов и зависимостей.

С помощью Cursor (AI-ассистента для кода) переписал всё расширение за пару часов:

• Перенёс на WXT (фреймворк для Chrome Extensions)

• Заменил самописные компоненты на MUI

• Добавил TypeScript для типобезопасности

• Заодно запилил новую фичу: транскрипцию системного звука через Chrome Tab Capture API

Что получилось - https://chromewebstore.google.com/detail/speech-to-text/jolafoahioipbnbjpcfjfgfiililnoih

Теперь Speech to Text может расшифровывать не только микрофон, но и всё, что играет на компьютере: YouTube-видео, Zoom-созвоны, лекции, подкасты и т.д.

Дополнительно добавил:

• Аудиоплеер для предпросмотра файла перед отправкой

• Анонимную расшифровку по прямой ссылке на аудио

Бонус

Модерация в Chrome Web Store прошла за 2 часа (обычно было 8-12). Предполагаю, что регулярные релизы дают "репутацию" у алгоритмов Google.

Выводы

Унификация стека — это не просто модное слово, а реальная экономия времени. Теперь могу быстро переключаться между проектами и переиспользовать компоненты без головной боли.

Хотите больше деталей?
Про процесс унификации стека, выбор инструментов и другие эксперименты с расширениями пишу в своём Telegram-канале @debug_leg. Там более неформальный формат: короткие посты, скриншоты процесса и честные истории про грабли. Подписывайтесь, если интересна кухня разработки.

Мой стек для запуска MVP 🚀

После отпуска я понял простую вещь - двух недель достаточно, чтобы забыть вообще всё, чем ты занимался.
Если у тебя нет структуры, стек превращается в хаос из случайных библиотек, фреймворков и зависимостей.

Поэтому я сел и собрал для себя техрадар - единый стек, который позволяет запускать pet-проекты и мини SaaS быстро и без боли.

⚙️ Frontend

React
🧠 Почему: куча библиотек, море документации и огромное комьюнити. Плюс масса готовых компонентов - не надо изобретать велосипед.

WXT
⚡ Почему: лучший фреймворк для браузерных расширений, если нужно быстро. Реально сокращает путь от идеи до первой установки

MUI
🎨 Почему: так как большинство моих проектов - Chrome Extensions, UI-компоненты под Material Design органично вписываются в браузер от Google.

Netlify
☁️ Почему: одна из самых удобных платформ для веб-разработки. Автоматическая сборка, тестирование и деплой в пару кликов. Работает стабильно и без боли.

🧩 Backend

Supabase
🗄 Почему: open-source альтернатива Firebase, но с Postgres под капотом — понятным, гибким и предсказуемым. Есть всё: авторизация, база, edge-функции и SQL-запросы.

Yandex Cloud
💾 Почему: недорогой S3, с "льготным" объёмом данных, за который не берут денег. Плюс умеет поднимать Docker-контейнеры в serverless-режиме. Идеально для пет-проектов.

🧱 Инфраструктура

CI/CD — Jenkins
🔁 Почему: не прожорлив, стабилен и с кучей плагинов. Работает даже на обычном VPS.

GlitchTip
🐞 Почему: не ест столько памяти, как Sentry, но совместим с его API и библиотеками. Отличный вариант для отслеживания ошибок.

Umami
📊 Почему: не блокируется ad-блоками, лёгкая и быстрая. Отличная альтернатива Google Analytics и Яндекс.Метрике.

🧰 Инструменты

JetBrains IDEA
💻 Почему: всю жизнь писал на Java и Kotlin - это мой родной IDE. Самый знакомый и надёжный инструмент.

WebStorm
🧠 Почему: по сути та же IDEA, только заточенная под JS и TypeScript.

Cursor
🚀 Почему: ускоряет разработку. Во второй версии можно подключить debug port Chromium и буквально «вайбкодить» с ИИ в реальном времени.

DBeaver
📘 Почему: купить лицензию DataGrip сложно, а DBeaver - почти то же самое. Не идеально, но достаточно для работы с БД.

GitHub
🌐 Почему: так исторически сложилось. Репозиторий, автодеплой, CI - всё в одном месте.

💬 Языки

TypeScript
🧩 Почему: я привык к типизированной Java, и JS без типов меня бесит 😅.
Плюс Cursor тратит меньше токенов, потому что не нужно проверять типы, и упрощается процесс vibe debugging - сразу понятно, что за данные под капотом.

Python
🐍 Почему: стараюсь минимизировать, но иногда выручает. Особенно когда дело доходит до ML и AI - ребята из этой среды его обожают.

(А вот Kotlin, как бы я его ни любил, сюда просто не ложится.)

Сейчас думаю над системой логов и метрик — скорее всего, выберу VictoriaMetrics.

Ещё у меня есть телеграм-канал, где я рассказываю, как всё это использую вживую, и делюсь процессом разработки своих пет-продуктов 👉 t.me/debug_leg

Как понять, полетит ли твой пет-проект, ещё до того как ты его закодил

Когда я впервые решил попробовать себя на маркетплейсах, первое, что сделал — посчитал математику.
Какие товары выгодно продавать, а какие не имеет смысла даже закупать.
С этого момента я понял одну простую вещь: экономика всегда важнее идеи.

С IT-проектами, мини-SaaS и прочими пет-поделками всё работает точно так же.
Некоторые идеи звучат круто, но экономика там минусовая ещё до релиза.
А какие-то — наоборот, простые, скучные, но с отличной маржинальностью.

Чтобы не тратить время на «мертвые» идеи, я собрал простой калькулятор экономики пет-проекта.
Он помогает понять, сколько денег нужно вложить и сколько можно заработать за первые три месяца, если запускаться через поисковый трафик.

Внутри — всё по делу: трафик, конверсии, CTR, CPC, расходы, цена подписки.
В итоге калькулятор покажет, во что ты реально влезешь, и стоит ли вообще кодить идею или лучше оставить её в «папке с концептами».

🧮 Калькулятор можно посмотреть и попробовать тут:
👉 Google Sheets — Экономика пет-проекта

Я сделал его под свои запуски, но он подойдёт любому, кто хочет тестировать идеи быстро и с холодной головой.

С чего на самом деле стоит начинать IT-проект

Если бы год назад меня спросили, с чего начинать IT-проект, я бы не задумываясь сказал: с MVP. Так учили, так делают большие продуктовые команды, так звучит «по науке».

Но чем больше я работаю, тем сильнее понимаю, что моё представление о minimal и value давно извратили корпоративные процессы. MVP — это уже не про скорость, а про маленький продукт с большой бюрократией.

Проблема даже не в том, что минимальный продукт часто получается просто говном — с багами, уродливым дизайном и UX из 2010-го.
Проблема в том, что на него уходит время. А это уже не MVP, а мини-стартап со всеми рисками.

Сейчас я всё больше убеждаюсь, что главное — не идея и не продукт, а трафик.
Сколько его, сколько стоит, где его взять, как купить, какая там конкуренция и какие риски. Трафик — это и есть спрос. Всё остальное — следствие.

Иногда вместо MVP хватает лендинга. Он быстро отвечает на главный вопрос: стоит ли вообще делать MVP и какие фичи туда добавить.

Ориентиры простые:

• CTR — как часто кликают по офферу (в рекламе, постах, реддите — не важно где).

• CR — как часто совершают целевое действие на лендинге.

Если CTR высокий, а CR низкий — идея заходит, но оффер не цепляет.

❌ Плохо описана фича.
❌ Много нецелевой аудитории.

Если CTR низкий, а CR высокий — наоборот: оффер норм, но ты не туда бьёшь.

🎯 Промах по таргету.
🎯 Слабая коммуникация.

Если оба низкие — идея мёртвая.

И вот теперь я думаю: может, всё MVP-мышление надо перевернуть? Не строить продукт, чтобы проверить спрос, а сначала проверить спрос, чтобы понять — нужен ли продукт.

Короче, если твоя идея собирает внимание — проект почти точно полетит.

Я пишу про такие наблюдения, тесты и свои эксперименты с инди-продуктами у себя в телеге.

Как я ищу идеи без ChatGPT

Очень часто вижу совет: «Хочешь найти идею? Просто спроси у ChatGPT».
Но если реально хочу откопать живую идею и проверить рынок — иду не к ИИ, а в данные.
Вот список сервисов, которые для этого использую 👇

🔎 Аналитика запросов

• Answer the Public — строит карту поисковых запросов на основе автокомплитов Google. Помогает понять, как реально формулируют вопросы пользователи.

• Semrush — мощный SEO-инструмент: ключевики, конкуренты, источники трафика. Удобен для оценки ниши и поиска новых идей.

• Wordstat Yandex — статистика по ключевым словам в Яндексе. Полезно для анализа российского рынка.

• Google Trends — показывает динамику интереса к запросам во времени. Отлично подходит, чтобы понять: хайп это или долгосрочный тренд.

📊 Аналитика посещаемости сайтов

• Similarweb — оценка трафика сайта, источники, география. Можно подсмотреть, откуда растут конкуренты.

📱 Аналитика мобильных приложений

• Sensor Tower — трекает загрузки и выручку приложений. Полезно для оценки рынка мобильных продуктов.

• Appmagic — похож на Sensor Tower, но с более детальными срезами по нишам. Удобен для ресёрча идей.

• App Store Spy — анализ ключевых слов и позиций приложений в сторе. Помогает с ASO.

• Read Reviews — парсинг отзывов из магазинов приложений. Можно быстро выявить боли пользователей.

🏢 Аналитика юрлиц (Россия)

• Rusprofile — финансы, учредители, судебные дела. Полезно для проверки конкурентов или потенциальных партнёров.

📢 Аналитика соцсетей

• TGStat — аналитика Telegram-каналов: рост, вовлечённость, пересечения аудиторий.

• Telemetr — ещё одна метрика по Telegram, иногда даёт чуть другие данные.

• VidIQ — анализ YouTube-каналов: теги, тренды, вовлечение. Нужен, если строишь продукт на контент-аудитории.

⚡️Как использовать

• ищешь идею → смотришь, как её ищут (Answer the Public, Wordstat, Trends);

• проверяешь конкурентов → Similarweb, Semrush, Appmagic;

• анализируешь боли → Read Reviews, TGStat;

• смотришь деньги и риски → Rusprofile.

Кстати, я регулярно делюсь такими находками и своими экспериментами в инди-хакинге у себя в телеграме 👉 Дебаж с ноги

SCAMPER⁠⁠

Недавно я узнал про методику SCAMPER.
Она из разряда простых, но мощных инструментов креативного мышления. Суть в том, что ты берёшь продукт или задачу и начинаешь смотреть на неё с семи разных углов:

S — Substitute (заменить)
C — Combine (комбинировать)
A — Adapt (адаптировать)
M — Modify (модифицировать)
P — Put to another use (использовать иначе)
E — Eliminate (убрать)
R — Reverse (перевернуть)

Методика работает как игра: задаёшь себе вопросы, которые обычно не задаёшь, и получаешь неожиданные варианты.

Пример: возьмём банальный TODO-менеджер.
– Что можно заменить? Ввод руками — на импорт задач из мессенджера.
– Что комбинировать? Список задач + календарь в одну сущность.
– Как адаптировать? Взять механику из игр и добавить квесты.
– Что модифицировать? Из списка сделать канбан с лимитами.
– Где использовать иначе? Движок для задач отдать командам саппорта.
– Что убрать? Проекты и теги — оставить «сегодня» и «инбокс».
– Что перевернуть? Планировать не с утра, а с конца дня — от дедлайна назад.

Из одной скучной идеи рождается десяток направлений для MVP. А дальше уже вопрос проверки спроса.

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

Для меня SCAMPER стал открытием: всего семь «рычагов», которые помогают находить новые решения даже там, где кажется, что всё давно придумано.

Кстати, я регулярно делюсь такими находками и своими экспериментами в инди-хакинге у себя в телеграме 👉 https://t.me/debug_leg

Портфель продуктов⁠⁠

Я всё больше прихожу к мысли, что моя стратегия - это не «ставка на одного единорога», а портфель продуктов.
Я постоянно запускаю новые проекты. Да, не все они находят рынок. Но зато всегда есть шанс, что один или два "выстрелят".

Почему не один?
Потому что меня не драйвит идея "сидеть на одном продукте до посинения". Мне нравится запускать, проверять гипотезы на реальном спросе, а не тратить месяцы на интервью и бесконечные обсуждения проблем пользователей. Минимальный прототип -> рынок -> обратная связь. И вперёд.

У этого подхода есть очевидные плюсы. Это диверсификация: один провал не убивает всё. Это быстрые тесты: можно пробовать разные рынки и модели монетизации. Это сглаживание дохода: разные продукты дают суммарный MRR и снижают волатильность. И, конечно, это опыт: каждый запуск учит чему-то новому, и следующий делать проще.

Но есть и обратная сторона. Переключение между проектами рвёт фокус. Поддержка множества продуктов превращается в постоянный саппорт. Иногда ловлю себя на том, что не дожимаю тот проект, который стоит дожать, потому что «есть ещё три».
Бренд тоже страдает: аудитории сложнее понять, о чём ты. Ну и усталость - постоянные запуски дают дофамин, но оставляют хвост незакрытых задач.

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

И знаете что? Пока мне нравится сам процесс. Запускать, смотреть реакцию, делать выводы и идти дальше. Это даёт мне больше мотивации, чем идея "строить идеальный продукт годами" (это уже проходили).

Кстати, я регулярно пишу о своих продуктах, экспериментах и запусках в телеграме 👉 https://t.me/debug_leg

LLM умрут, а бизнесы на API рухнут⁠⁠

35 лет подряд Янн Лекун угадывает повороты в ИИ.
В 80-х он говорил про распознавание изображений, в нулевых - про нейросети, в 2016 - про самообучение.
И вот сейчас он заявляет самое радикальное: LLM в том виде, в каком мы их знаем, мертвы.

Проблема не в данных и не в мощности, а в архитектуре.
Каждый токен чуть сдвигает модель в сторону, и чем длиннее вывод - тем выше шанс галлюцинаций. Никакие терабайты и GPU это не спасут.

А теперь подумай, сколько сейчас продуктов держится только на API OpenAI.
Чат-боты, резюмирование документов, генерация текстов.
Все эти проекты живут лишь потому, что можно позвать API.

Но новая волна придёт не от «больше параметров», а от моделей, которые учатся «как дети»: через видео, восприятие и понимание мира.
И тогда поддерживать бизнес на API старых LLM станет бессмысленно. Новые модели будут быстрее, точнее и дешевле.

Лекун прямо говорит: закрытые модели исчезнут, открытые и распределённые — победят. Meta уже вкладывает $20 млрд в перестройку стратегии. Сроки короткие: 3-5 лет до первых моделей мира, и около десятилетия до ИИ уровня человека.

Для корпораций это вызов. А для indie-hacker’ов - шанс.
У больших игроков всё завязано на старых API и инерции.
А у нас есть свобода пробовать новое. Пет-проекты — это маленькие лаборатории, где можно тестировать идеи будущего и учиться жить «после LLM».

Когда рынок перетрясёт, выиграют те, кто уже умеет мыслить продуктом, а не строками API.

Я как раз пишу о своих экспериментах в инди-хакинге и пет-проектах у себя в телеге 👉 https://t.me/debug_leg