Ginkida.dev | Sungat Arynov

🔬Анатомия AI-видео хайпа: разбираю метрики Higgsfield $50M Series A, 11 млн пользователей за 5 месяцев, министр говорит о конкуренции с OpenAI. Красиво звучит. Но давайте считать. Что не сходится: 📊 ARPU ~$4.5 в год на пользователя. У Netflix — $140, у Spotify — $55. Либо массово не платят, либо сидят на минимальных тарифах. 🔧 Нет собственных моделей. Veo — Google, Kling — Kuaishou, Sora — OpenAI. Higgsfield — красивая обёртка над чужими API. Маржа тонкая, зависимость полная. 💰 Цены в 2-3 раза выше Runway и Kling. При тех же моделях под капотом — за что премия? 🏢 Ноль публичных enterprise-кейсов за 5 месяцев. Runway показывает Lionsgate и A24, Synthesia — BBC и Xerox. У Higgsfield — тишина. Это не приговор. Команда сильная, рынок растёт, $50M хватит на 2-3 года экспериментов. Но 75% венчурных компаний не возвращают деньги инвесторам, и AI-видео — один из самых жёстких секторов для этой статистики. Полный разбор со сценариями развития: https://ginkida.dev/ru/posts/anatomiia-ai-video-xaipa-cto-skryvaetsia-za-metrikami

Почему токсики в IT получают повышение, а нормальные люди уходят Недавно в Threads один программист пытался убедить меня, что коллеги - не причина выгорания в IT. Мол, проблема не в среде. Розовые очки крепко сидят 😅 Вот только статистика: → 37% уходят из tech из-за несправедливого обращения → 78% испытывали токсичное поведение на себе → 85% наблюдали его у коллег → 1 из 10 женщин - нежелательное внимание на работе Это не "единичные случаи чувствительных людей". Это система. Как это работает? Индустрия не любит токсиков на словах. Но вознаграждает условия, где токсичность = выигрышная стратегия: - Давишь сроками вместо прояснения → ты "эффективный" - Тащишь пожары вместо системы → ты "герой" - Унижаешь на код-ревью → "поддерживаешь стандарты" - А кто задаёт вопросы и не играет в доминирование - "не тянет". Дальше естественный отбор. Кто адаптировался - растёт. Кто нет - уходит. Личное наблюдение После многих лет в индустрии понял одну вещь: иногда с AI работать комфортнее, чем с некоторыми начальниками 🤷 - AI не самоутверждается за твой счёт. - Не закатывает глаза на вопросы. - Не саботирует идеи, потому что не он их предложил. Это не комплимент технологиям. Это диагноз культуре. Хорошая новость Токсичность - управляемый риск, а не "характер отрасли". Google это доказал: psychological safety - главный фактор эффективности команд. Вопрос не в том, можно ли изменить. Вопрос - готовы ли мы. Полная статья в блоге: https://ginkida.dev/ru/posts/pocemu-toksiki-v-it-polucaiut-povysenie-a-normalnye-liudi

Недавно меня чуть не развели на паспорт 🎭 Схема красивая: европейская компания, нашли на джоб-борде, написали в личке, созвонились. Один созвон - и "You're hired, welcome aboard!" Я такой: круто, что дальше? Они: пришлите скан паспорта и proof of address на почту, потом дадим контракт. Я: э, а можно сначала контракт? Они: нет, так не работает, сначала документы. Я проверил компанию: - Домен свежий - Отзывов ноль - Сотрудников не найти - Админка публично открыта Написал, что не готов отправлять паспорт без договора. В ответ прилетело: "How do you expect anyone to hire an unknown and undocumented person?" Ну я и послал. Но не паспорт 😅 А теперь серьёзно. Паспорт + proof of address - это всё что нужно для: → Кредитов на ваше имя → Регистрации фирм-однодневок → Дубликата сим-карты → Криминальных схем Написал большую статью о том, как распознать мошенников при найме и что делать если уже отправили документы. 🔗https://ginkida.dev/ru/posts/pocemu-ia-poslal-rabotodatelia-kogda-on-poprosil-pasport Сталкивались с таким?

Программисты которые говорят «ИИ это хайп» напоминают таксистов которые смеялись над Uber в 2015. Каждый раз когда заговариваю с коллегами про вайбкодинг: — Это хайп, через год забудут — ИИ пишет говнокод — Настоящие программисты так не работают — Пузырь скоро лопнет Я никогда так не думал. С первого ChatGPT взял инструмент в работу. Сейчас ИИ - часть ежедневного стека. Рутина ушла на него: тесты, формы, шаблонный код, рефакторинг по 20 файлам. Я занимаюсь архитектурой и ревью - тем, что требует мозгов. «Но ИИ ошибается!» Джуниоры тоже. Только джуниору платишь зарплату и объясняешь 10 раз. Модель адаптируется на лету и стоит $20 в месяц. Пессимизм понимаю. Страшно признать что часть твоих навыков автоматизируется. Но игнорировать реальность - не стратегия. Половина кода в мире уже пишется с помощью ИИ. Это статистика 2025 года. Через 3 года «опыт с AI-ассистентами» будет в каждой вакансии. Вопрос - ты среди первых или догоняющих? Написал большой разбор: инструменты, практики, грабли, что реально работает 👇 https://ginkida.dev/ru/posts/kak-ia-perestal-pisat-kod-i-nacal-im-upravliat

По образованию я географ. Код не писал вообще. Сейчас уже разработчик, свои проекты, карьера в IT. Всё через самообучение: ошибки, откаты, снова попытки. Но это только часть истории 👇 Самостоятельно разобрался с ремонтом машин. Починил свою тачку, от которой отказались все сервисы в городе. Просто сел, изучил, сделал. Освоил вокал. Путь был тот ещё, но результат есть. Откуда это всё? Одна привычка после школы: каждый день узнавать что-то новое. Не "стараюсь", а просто живу так уже много лет. Принцип простой: мне нравится учиться. У людей, по книгам, руками - без разницы. Недавно глубоко копнул тему, как вообще работает самообучение у взрослых. Нейробиология, психология, методы. И обнаружил интересное: - Мозг пластичен всю жизнь, "затвердевание после 25" — миф - Циолковский за 3 года в библиотеке освоил университетскую программу - Маск выучил ракетостроение по книгам - Элла Фицджеральд никогда не брала уроков вокала Возраст не барьер. Отсутствие диплома не барьер. Барьер это мысль "мне уже поздно". Собрал всё в статью - наука, методы, истории, антипаттерны. Если резонирует, то читай!

«Он же senior, он лучше знает» Каждый раз, когда слышу эту фразу - жду провала. И обычно дожидаюсь. Реальный кейс: технический директор из «колёс» два года не мог довести продукт до MVP. Уважаемый, авторитетный. Его ум никто не оспаривал (кроме меня). Я переписал и поднял всё за три недели. Без пафоса и теоретических баталий. Проблема не в сеньорах. Проблема в том, что мы верим в титулы больше, чем в результат. Настоящий эксперт объясняет сложное просто и признаёт границы знаний. Пустышка прячется за жаргоном и боится «потерять лицо». Разобрал тему в статье. Почему авторитет не равен экспертизе и как это исправить 👇 https://ginkida.dev/ru/posts/avtoritet-vs-rezultat-pocemu-gromkii-titul-ne-garantiruet

Почему «сеньор в своём деле» тонет, а универсал вытягивает стартап Классический сценарий: Сеньор-инженер 10+ лет в своей технологии запускает стартап и через год понимает, что его deep-скилл почти ничего не решает. Потому что: он не умеет продавать, нанимать, говорить с клиентами и инвесторами. Маркетолог попадает в ту же ловушку: умеет лить трафик, но не может объяснить разработчикам, что именно строить и зачем. Оба продолжают думать как специалисты, а не как фаундеры. И стартап стоит на месте. Сэм Альтман это формулирует жёстко: Лучшие фаундеры это универсалы от начала и до конца! В реальности фаундер на ранней стадии выглядит так: - утром – продукт/инженер, - днём – продажник и интервьюер клиентов, - вечером – финансовый директор, который считает runway и юнит-экономику, - параллельно – HR, маркетинг и саппорт. И вот почему универсалы выигрывают: - видят весь бизнес, а не только свой кусок кода или воронки; - быстро вникают в новые области (от AI до юристов и налогов); - умеют делать пивоты, не влюбляясь в исходную идею; - экономят ресурс – вместо 10 узких спецов у тебя 2–3 человека, которые тянут всё. Золотая модель здесь T-shaped фаундер: одна–две области, где ты реально глубоко в теме, и широкая «полка» навыков вокруг, чтобы не только сделать продукт, но и построить компанию. Если ты хочешь быть фаундером, а не вечно «старшим специалистом» в чужом проекте, то придётся выйти за пределы своей роли и научиться собирать всё воедино. В длинной статье я разобрал: - почему универсалы особенно сильны на ранних стадиях; - как меняется их роль по мере роста компании; - где универсальность превращается в ловушку; - как прокачать в себе этот режим, не потеряв глубину. Полный разбор здесь 👉ссылка А ты сейчас кто: узкий спец, универсал или T-shaped в процессе прокачки? 🤔

🧨 Анти-паттерны, которые убивают стартапы изнутри Команда сожгла $200k и полгода на «масштабируемую архитектуру» из 7 микросервисов, 5 БД и 3 очередей. Количество платящих клиентов на запуске: 0. Это не редкий случай. Это системная ошибка. Главная мысль проста: стартапы чаще умирают не от плохого кода, а от отсутствия продукта, который кому-то реально нужен. Но технарские анти-паттерны отлично ускоряют смерть 😅 Вот самые токсичные из них 👇 1️⃣ Преждевременные микросервисы Стартовать с микросервисов, Kubernetes и service mesh, когда у тебя нет ни трафика, ни юзеров – это не «профессионализм», а добровольный хардкор. Монолит одной командой из 3–5 человек разворачивается и меняется быстрее. Сначала нужен product-market fit, а не service mesh. 2️⃣ Overengineering и культ «чистого кода» Чистая бизнес-логика, размазанная по 5 слоям абстракций и 42 интерфейсам – это не архитектура, а лабиринт. Если чтобы понять код, нужна диаграмма, вы уже проиграли по скорости. В стартапе порядок такой: сначала «работает», потом «надёжно», потом (если дожили) «красиво». 3️⃣ Хайповый стек вместо здравого смысла Выбирают модный фреймворк, который никто в команде не знает. В итоге больше времени уходит на обучение и борьбу с багами, чем на фичи. Вопросы, которые нужно задавать себе честно: • решает ли технология мою реальную задачу лучше простых альтернатив? • есть ли у команды экспертиза? • не убьёт ли поддержка это решение через год? 4️⃣ Синдром велосипедостроения «Своё логирование, свой ORM, свой фреймворк, свой всё». Сообщество годами пилит библиотеки, а вы клепаете сырой аналог между митингами. В итоге баги, отсутствие документации и зависимость от одного автора. В стартапе главное – не объём написанного кода, а минимальная сложность решения. 5️⃣ Код вместо продукта Вылизанный до идеала код не спасёт, если: • никто не понимает, какую боль решает продукт • гипотезы не валидируются • обратную связь юзеров игнорируют Запускать нужно «достаточно хорошо», а не «идеально когда-нибудь». Мир не ждёт ваш идеальный релиз. 6️⃣ Упрямый техлид Когда лидер глух к рынку, метрикам и команде, стартап теряет гибкость. Лучшие техлиды меняют мнение, когда факты говорят обратное, а не продавливают своё решение ценой продукта. ❌ Краткий чеклист провала: – старт с микросервисов и тяжёлой инфраструктуры без юзеров – выбор стека по хайпу, а не по задачам – абстракции «на будущее», которое никогда не наступит – изобретение велосипеда там, где есть готовые решения – полировка архитектуры вместо проверки гипотез – игнор обратной связи от юзеров и команды ✨ Итог Простота, скорость и честное внимание к проблеме клиента выигрывают у архитектурного перфекционизма. Пользователю всё равно, на чём вы построили сервис. Его волнует только одно: решает ли ваш продукт его боль. Не стройте космический корабль там, где сейчас нужен самокат 🚀

Микросервисы убивают стартапы Каждый второй стартап начинает с микросервисов. Потому что "так делают Netflix". Потому что монолит это "устаревшее legacy". Только Netflix перешёл на микросервисы когда у них появились сотни инженеров и миллионы пользователей. А вы пытаетесь повторить это с командой из 5 человек. Что получается на практике: Команда разбила PHP-монолит на микросервисы. Штат вырос в 4 раза, скорость фич упала на 40%. Четыре человека стали работать медленнее шестнадцати. А вот как бывает с монолитом: Ghost Explore на Laravel - один разработчик, сервер с 1 GB памяти, 14 миллионов запросов в месяц. Без Kubernetes и армии DevOps. Cookpad на Rails - 50 млн пользователей, 15К запросов в секунду. Монолит. GitLab, Amazon, Netflix - все начинали с монолитов. Когда микросервисы реально нужны: → После 100+ инженеров → Независимые команды с разделёнными зонами → Стабильные доменные границы → Явная потребность масштабировать части системы по-разному До этого момента микросервисы создают больше проблем: каждый сервис требует своего мониторинга, CI/CD, логирования. Сеть добавляет латентность. Дебаг превращается в детектив. Что делать вместо этого: Модульный монолит. Изоляция кода без сетевых вызовов и распределённых транзакций. Когда модуль упрётся в потолок, то вынесете. Границы уже готовы. 90% стартапов не доживают до масштаба, где микросервисы нужны. Инвестируйте в продукт, а не в инфраструктуру ради резюме. Подробнее с примерами и антипаттернами в статье 👇 https://ginkida.dev/ru/posts/mikroservisy-ubivaiut-startapy-pocemu-monolit-eto-lucsii

Питер Левелс: $3M/год на PHP и jQuery 🚀 Один чувак без инвесторов, без команды, на «устаревшем» стеке делает то, о чём мечтают стартапы с миллионными раундами. Его стек (бомба!): PHP (старых версий!) SQLite (один файл = вся база) jQuery + vanilla JS Дешёвый VPS + Cloudflare Его философия: Запустил MVP для Photo AI - просто HTML-страница + Stripe. Бэкенда нет. Вручную скачивал фотки и прогонял через модель. 1000 оплат за 24 часа → только тогда начал писать код. Nomad List начался как Google-таблица. Когда она доказала спрос — превратил в сайт. Результат (2022): Remote OK: ~$1.6M/год Nomad List: ~$900K/год 70-90% — чистая прибыль Главные принципы: Сначала спрос - потом код Делай то, что не масштабируется Простые технологии > модные фреймворки Build in Public - прозрачность = доверие Пока все гонятся за React/Next.js/микросервисами - Левелс доказывает, что сложность ≠ успех. Подробнее: https://ginkida.dev/ru/posts/piter-levels-milliony-na-ustarevsem-php-pocemu-odin

Kubernetes это дорогая игрушка 🚛 Типичная история: стартап из пяти человек решает «сделать правильно с самого начала». Разворачивают K8s, три месяца пилят инфраструктуру, нанимают девопса. А потом выясняется, что их три сервиса отлично жили бы на Docker Compose. Что не говорят на конференциях: - Средний кластер загружен на 30-50%, остальное простаивает - Для прода нужны ещё CI/CD, Prometheus, Grafana, ELK, Ingress — и каждый настраивай отдельно - Автоскейлер без лимитов раздует счёт так, что финдир прибежит. Docker Swarm закрывает 80% задач. Одна команда, тот же Docker CLI, встроенный балансировщик. Arbuz.kz начинали на Swarm - K8s взяли только когда реально выросли. K8s нужен когда десятки сервисов, дикие скачки нагрузки и три девопса в команде. Для остальных это оверкилл. Разобрал подробно: когда K8s оправдан, когда нет, как выбирать → https://ginkida.dev/ru/posts/kubernetes-eto-dorogaia-igruska-pocemu-vasemu-startapu

IT-собеседования превратились в театр абсурда 🎪 Последние несколько лет наблюдаю одну и ту же картину: компании средней руки пытаются изображать из себя Google. Шесть этапов интервью, алгоритмические задачки, live-coding под прицелом пяти человек и всё это ради позиции, где человек будет клепать формы и дёргать API. Недавно наткнулся на исследование Microsoft, которое подтвердило то, что разработчики знали интуитивно 👇 Live-coding снижает результаты кандидатов на 50%. Не потому что люди глупые или не знают материал. А потому что стресс. Когда трое незнакомцев смотрят на каждый твой символ и ждут идеального решения за 20 минут, то мозг переключается в режим выживания. Мы проверяем не умение кодить, а умение выступать на сцене. HR-специалисты тоже бьют тревогу: на 2-3 этапе многие кандидаты просто отваливаются. Причина банальная. Пока одна компания согласовывает седьмое интервью с директором по инновациям, конкурент уже сделал оффер. Сильные специалисты не будут ждать месяц, пока вы решите, достойны ли они чести работать в вашей конторе по продаже виджетов. Отдельная боль это теоретические вопросы 🧠 Переворачивание матриц, красно-чёрные деревья, сложность алгоритмов быстрой сортировки. Для позиции фронтендера. Который потом полгода будет перекрашивать кнопки и фиксить баги в формах. Откуда это взялось? Компании тупо копируют процессы FAANG без понимания контекста. «Ребята знают, что делают» - думают они. Но то, что работает для Google с потоком в тысячи кандидатов в день, не имеет смысла для стартапа в 30 человек. Когда я сам начал нанимать, то делал всё наоборот 🔄 Перед встречей изучал резюме, LinkedIn, GitHub. Если у человека есть публичные проекты, то зачем давать тестовое? Лучше обсудить его реальный код: почему принял такие решения, с чем столкнулся, что бы сделал иначе. Само интервью от силы 30-40 минут разговора о реальном опыте. Не экзамен, а диалог. Какие проекты делал, какие задачи были самыми сложными, какие ошибки совершал. Это показывает в сто раз больше, чем наблюдение за тем, как человек потеет над задачкой с LeetCode. Никаких алгоритмов, если они не нужны в работе. Никакого live-coding под стрессом. Никаких шести этапов. Результат? Сильные люди в команде. Закрытые вакансии за дни, а не месяцы. Люди, которые работали годами, а не сбегали через испытательный срок. Собрал весь опыт в большую статью 📝 Разобрал главные проблемы найма, привёл исследования и цифры, описал антипаттерны и альтернативный подход. Если устал от собеседований-марафонов с любой стороны стола, то будет полезно. 👉https://ginkida.dev/ru/posts/problemy-it-sobesedovanii-kak-perestat-teriat-kandidatov-i А у вас какой самый абсурдный опыт собеседований был?