Как я просрал 9 месяцев жизни из-за разговоров 👹 Май 2024. Я и ещё два партнёра решили сделать сервис, который определяет что за автомобильная запчасть перед тобой, к каким маркам и моделям подходит и не подделка ли это Звучит скучно, но копни глубже - а на этом рынке происходит реальная вакханалия - Одна деталь подходит к десяткам моделей разных марок - У одной и той же детали может быть три разных кода от трех производителей, и они сами путаются в собственной номенклатуре - И вишенка на торте - рынок заполнен копиями и подделками, где на глаз их вообще не отличить от оригинала ➖ Короче, мы захотели построить сервис, который наводит в этом порядок Обучали модель, месяцами собирали данные по крупицам, созванивались с людьми из отрасли и в какой-то момент я уже зашарил в совместимости автозапчастей :) Но было большое НО Мы пытались продать индустрии решение проблемы, которую сами не могли решить в трех головах: кто за что отвечает. Модель мы обучили, да А вот управленческое решение - кто именно отвечает за продажи, кто за продукт, кто за сроки так и не приняли 🤩 Девять месяцев мы созванивались каждую неделю Обсуждали, уточняли, спорили, но проблема была в том, что тему, которую мы разбирали на седьмом месяце, мы закрыли ещё на втором и просто продолжали ее мусолить Продажами явно не занимался никто. Каждый по чуть-чуть касался всего и в итоге никто не отвечал ни за что целиком, а к февралю 2025 звонки стали реже, а потом их вовсе не стало Вывод, который обошёлся мне в 9 месяцев работы:

созвоны не двигатель проекта, особенно когда нет четких зон отвественности и четких задач + сроков после него

Я уже со многими подписчиками пообщался в директе на эту тему и понимаю, как бывает стремно такое обсуждать, а в особенности делиться своими факапами Но если вдруг у тебя есть ощущение, что на проекте что-то идет не так - под этим постом можно поделиться и получить фидбек со стороны (ни на что не намекаю как всегда)

Вообще не осталось продакт-менеджеров, которые бы не упоролись напрочь в нейросети. Мне кажется это какие-то неправильные менеджеры, кто этого еще не сделал. Поэтому я и веду свой второй канал @gleb_pro_ia, и делаю это примерно в 100 раз активнее, чем этот. Чего-то высасывать из пальца при этом тоже не хочется. И я все думал. а про что ж писать тут? Решение висело под носом. Тут уже написано в заголовке про бизнес, значит буду продолжать писать про бизнес. Пусть и с нейросетевым уклоном, так как без этого сейчас ну вообще без вариантов. А на втором канале продолжу исповедовать гонзо-журналистику про то, каких агентов я потрогал сегодня, и как они меня возблагодарили в ответ.

🤬 Новая охота на ведьм На The Verge вышла отличная статья, которая откликается у нашей редакции. Раньше преподаватели гоняли работы через антиплагиат: система сравнивала текст с базой сайтов и научных статей и выдавала процент совпадений. Теперь охотятся не за копипастой, а за нейросетью. Детекторы вроде GPTZero, Pangram и других, работают иначе. Собственная ИИ-модель анализирует лексику, ритм, структуру предложений, длину и тон и выносит вердикт. Оценка выходит субъективной и особенно часто спотыкается на тех, для кого английский неродной. Масштаб уже приличный: по опросу Center for Democracy and Technology, в 2024–2025 годах детекторами регулярно пользовались 43% американских учителей средних и старших классов. Француз Тьерри Риньоль судится с Йелем: профессор прогнал его экзаменационную работу через GPTZero, и студент получил незачёт и год отстранения. В феврале студент Университета Адельфи выиграл похожий иск. А недавно Джек Осборн, сын Оззи, обвинил журналистку Кэт Тенбардж в том, что статью за неё написала нейросеть, и показал 3,5 миллионам подписчиков «доказательство» из детектора. Опровержение она опубликовала, а он обвинение так и не снял и видео не удалил. Самое любопытное, что сами разработчики предупреждают о недостатках. Grammarly просит не полагаться на детектор в одиночку. GPTZero признаёт, что стопроцентного детектора не существует. OpenAI и вовсе закрыла свой ещё в 2023-м из-за низкой точности. Университеты мирового уровня: Йель, Джонс Хопкинс, Вандербильт, Джорджтаун и другие уже отключили или ограничили такие проверки. MIT вообще говорит, что детекторы не работают. Вместо них советуют менять сами задания — писать в аудитории, дробить длинные работы, разрешать указывать, где помогал ИИ. Мы, кстати, сталкиваемся с этим постоянно. И это, на наш взгляд, новый вид паранойи, который породил ИИ: читатель заранее подозревает текст, а живой автор старается писать так, чтобы «не звучать как нейросеть». Например, конструкция “это не просто А, а это Б”, вообще забанена нашим редактором. Хотя до появления нейросетей этот приём часто использовался в текстах. @droidergram

Клиентка удивилась: "Ого, так быстро!" Я скинула ей отчёт с рекомендациями утром. На самом деле вся картинка по ее продуктам у меня сложилась как только накануне поздно вечером она прислала их фото - красивые дизайнерские гитары. И ответы на мои уточняющие вопросы. У меня в голове сразу понеслись мысли, я быстро записала их в диктофон и заметки. Утро мне нужно было, чтобы перепроверить все мысли на свежую голову + расписать так, чтоб клиентке и ее партнеру сразу было понятно, что и как делать. Когда мои рекомендации готовы, для проверки и из любопытства я сейчас прогоняю товары через 5 ИИ и смотрю, что предложат они. На практике они обычно дают 1-2 идеи, которые не увидела я, и не видят 2-3 самых важных стратегии + 5-10 небольших мыслей. Часто вообще не замечают самое ключевое, что переворачивает всё развитие проекта. Опыт не заболтаешь ☝️ Здесь 1 из ИИ подсказал ещё одну хорошую идею, я добавила ее в отчёт и развила от нее ещё 5 рекомендаций. 2 других наболтали поверхностного бреда. И, разумеется, пришлось их возвращать к РФ реалиям. А то они даже мотивации поступков клиентов любят лепить по американским калькам. Ни один не назвал 20 рекомендаций, которые дала я. Я финализировала отчёт и отправила клиентке. "Разбор за час" занял суммарно 1ч15 на составление отчёта и ~40 минут на первичные переговоры с клиенткой и запись летящих идей в процессе.

В индустрии давно используются системы контроля версий. Они помогают команде совместно работать над кодом, позволяют отследить изменения и при необходимости откатиться до рабочей версии. Помимо кода там можно хранить конфигурации и манифесты, спецификации и документацию. Короче, Всё-as-Code. Первая такая система возникла аж в 1972 в Bell Labs. Программа SCCS отслеживала локальные изменения файлов. В 1986 появилась централизованная система - CVS, там уже использовался центральный репозиторий и клиент-серверное взаимодействие. Теперь уже несколько пользователей могли работать с единой кодовой базой. В начале 2000-х вышла SVN, как преемник CVS, и стала фактическим стандартом на несколько лет. Сейчас это Apache Subversion, и она до сих пор используется в некоторых старых проектах. В 2005 создатель Linux Линус Торвальдс представил третье поколение подобных систем - Git, который и по сей день является самым популярным инструментом для контроля верисий. В том же году появились аналоги - Mercurial, тоже довольно популярный, и Bazaar, но Git всех обогнал. Вот тут можно почитать. И вот мы уже третий десяток лет работаем с Git, вот таким он оказался универсальным и удобным. Понятное дело, что прогресс продолжается. Есть экспериментальные и альтернативные системы нового поколения, но они остаются нишевыми. Однако, энтузиасты усовершенствуют даже Git. Есть такой проект - GitButler. Это Git-клиент, созданный Scott Chacon, сооснователем GitHub. Проект привлёк $17M от фонда a16z. Вот что они пишут про возможности: ▪️Параллельные ветки - можно работать над разными задачами в одном рабочем пространстве без переключения контекста ▪️Стековые ветки - это зависимые друг от друга ветки (тут подробнее) ▪️Бесконечное Undo - снэпшоты перед каждой операцией позволяют откатиться без потерь ▪️Коммитами можно жонглировать как угодно даже после пуша в удаленный репозиторий ▪️ИИ-помощник для названий веток, коммитов и описаний PR ▪️Интеграция с GitHub и GitLab Опенсорсно. Есть десктопная и консольная версии. #tools #git

Новый двигатель на водороде для грузовиков работает не хуже дизельных Водород можно использовать в качестве топлива двояко: либо соединять с кислородом в топливных ячейках и получать электрический ток, либо сжигать его в обычном двигателе внутреннего сгорания (ДВС), получая на выходе вместо углекислого газа водяной пар. Исследователи из США разработали оптимизированный водородный двигатель с искровым зажиганием для среднетоннажных коммерческих грузовиков. По характеристикам он приближается к дизельным двигателям, но при этом сохраняет преимущества ДВС. https://hightech.plus/2026/08/10/novii-dvigatel-na-vodorode-dlya-gruzovikov-rabotaet-ne-huzhe-dizelnih

#кейс_стади Разбор с СEO, вайбкодом и Едрит Многие ответили на задачу с позиции мидл-менеджера: провести ретро, спросить архитектора, поправить процессы, не лезть в чужую работу. Но CEO здесь вообще в другой позиции. У него сорван крупный контракт, под риском следующий рейз, потеряно доверие к инженерным оценкам и появился контрпример. Его задача быстро вернуть управляемость Первое Показать свою ветку CTO и поставить задачу ее опровергнуть. И не с позиции "я сделал лучше вас", а "вот решение, которое по моей текущей оценке закрывает то же самое за две недели 1 человеком". Можно остановить менее важные задачи, подключить сильных инженеров и прогнать тот же набор проверок. Если решение развалится -> отлично, CEO получит конкретные причины, чего он не понимал. Если после недели допила оно сравнимо -> вопрос становится очень неприятным Второе CTO должен объяснить не код, а управленческое решение. Что из вот этого platform наворота было еально необходимо для Дастархана, что строилось на будущее, кто принял вообще сравнивал варианты и какая экономика у них. Критичный бизнес-дедлайн был известен заранее. Если инженерка сознательно обменяла его на красивую платформу, бизнес должен был участвовать в этом решении, а не узнать о последствиях через пять месяцев Третье С этого момента подобные решения принимаются иначе. Есть жесткое внешнее ограничение -> CTO приносит несколько вариантов со сроками, рисками и стоимостью: быстро закрыть потребность, сделать нормально, строить платформу. Какой риск купить -> решает CEO. Архитектура не существует отдельно от экономики, особенно когда на другой стороне контракт и инвестиционные деньги Четвертое CTO должен принести отчет, причем не нейрослоп HTML-бандл от клодкода, а понятные 2 странички с хронологией проекта, где были проблемы, что для них делали и почему не уложились в сроки. Отдельно информация как им управляли и контролировали. По отчету станет прозрачно осознавал ли техдир важность проекта и делает ли менеджмент в компании полезную нагрузку Отдельно меня удивило, сколько людей вообще начали обсуждать, правильно ли CEO втихаря вайбкодит и должен ли он лезть в работу разработчиков. Это взгляд из своей профессиональной колокольни. В условиях кейса CEO уже вайбкодит, уже достаточно погружен и получил новую информацию о собственной компании. Спорить с условиями задачи вместо принятия решения -> уходить от самой задачи. Тем более я постоянно общаюсь с C-level продуктовых компаний и это уже совсем не экзотика, когда даже фаундер собирает себе что-то И дальше самое важное -> реакция CTO. Ошибка в архитектуре допустима. Сорванный срок тоже иногда допустим. Недопустимо, когда критичный для бизнеса срок сорван, последствия воспринимаются как данность, альтернативное решение никто не хочет проверять, а объяснение заканчивается на вам не понять разработку. Если CTO сам разбирает ситуацию, показывает где ошибка CEO и меняет систему -> доверие можно восстановить. Если защищает статус-кво -> я бы ставил CTO испытательный срок