Собираем Docs-as-Code: GitLab CI, Docusaurus и поиск. Как мы сделали базу знаний. Часть 3
В прошлой части я объяснил, почему мы выбрали Docusaurus. Выбор сделан, но «движок» сам по себе — это просто куча JS-файлов. Чтобы всё это реально заработало в компании, нужно было подружить его с нашими репозиториями, настроить автоматическую сборку и заставить поиск работать молниеносно.
Рассказываю, как мы это «приготовили» в СОФТОНИТ.
Архитектура: Одна «витрина» — много источников
Главная идея Docs-as-Code: документация лежит рядом с кодом, мы пишем код, обновляем документацию и клиенты видят обновленную документацию на сайте без танцев с бубном. У нас несколько продуктов (например, Управление IT-отделом 8), и у каждого продукта свой репозиторий в GitLab.
Я не хотел заставлять разработчиков копировать файлы вручную. Все должно быть просто для разработчиков. Поэтому мы создали отдельный репозиторий для документации, который работает как «агрегатор».
Как это работает:
1. В репозитории агрегаторе есть файл конфигурации repos.json, где перечислены все наши проекты и ветки откуда надо брать документацию (как правило это ветка main).
2. GitLab CI при запуске в репозитории агрегаторе идет в эти репозитории доноры и забирает папку docs у каждого продукта, копируя в общую структуру Docusaurus. В каждом репозитории есть папка docs с документацией в markdown.
3. Происходит «магия» со слагами (slugs) и ID для каждой статьи (транслитерация адресов URL статей), чтобы ссылки не бились.
Всё это пакуется и собирается общая база знаний, а затем она копируется на сервер.
4. Затем обновляется поисковый индекс.
Разбор полетов: Наш GitLab CI/CD
Ниже — ключевые этапы нашей сборки. Я не буду уходить в дебри, остановлюсь на важных нюансах.
- Этап синхронизации (Sync): Здесь мы используем node:24-alpine. Главная хитрость — обход прокси для внутреннего GitLab. Мы прописываем IP бэкенда прямо в ~/.ssh/config. Скрипт перебирает repos.json, клонирует репозитории и вытягивает Markdown-файлы.
- Сборка (Build): Стандартный npm run build. На выходе получаем готовую статику в папке build/.
- Деплой (Deploy): Используем старый добрый rsync через SSH. Это быстрее и надежнее для обновления только измененных файлов. Работает, кстати, такое очень быстро.
- Индексация (Index): А вот тут самое интересное.
Поиск: Почему Meilisearch, а не Algolia?
В прошлой статье я хвалил Algolia, но в итоге мы развернули Meilisearch. Почему?
- Полный контроль: Всё крутится на нашем сервере.
- Скорость: Он быстрый.
- Стоимость: Для наших объемов это бесплатно, при этом качество выдачи не уступает облачным гигантам.
Сейчас на docs.softonit.ru уже можно посмотреть результат.
А как вы решаете вопрос с обновлением общей документации из разных репозиториев? Делаете мульти-проектные пайплайны или тоже живете на расписании? 👇
В прошлой части я объяснил, почему мы выбрали Docusaurus. Выбор сделан, но «движок» сам по себе — это просто куча JS-файлов. Чтобы всё это реально заработало в компании, нужно было подружить его с нашими репозиториями, настроить автоматическую сборку и заставить поиск работать молниеносно.
Рассказываю, как мы это «приготовили» в СОФТОНИТ.
Архитектура: Одна «витрина» — много источников
Главная идея Docs-as-Code: документация лежит рядом с кодом, мы пишем код, обновляем документацию и клиенты видят обновленную документацию на сайте без танцев с бубном. У нас несколько продуктов (например, Управление IT-отделом 8), и у каждого продукта свой репозиторий в GitLab.
Я не хотел заставлять разработчиков копировать файлы вручную. Все должно быть просто для разработчиков. Поэтому мы создали отдельный репозиторий для документации, который работает как «агрегатор».
Как это работает:
1. В репозитории агрегаторе есть файл конфигурации repos.json, где перечислены все наши проекты и ветки откуда надо брать документацию (как правило это ветка main).
2. GitLab CI при запуске в репозитории агрегаторе идет в эти репозитории доноры и забирает папку docs у каждого продукта, копируя в общую структуру Docusaurus. В каждом репозитории есть папка docs с документацией в markdown.
3. Происходит «магия» со слагами (slugs) и ID для каждой статьи (транслитерация адресов URL статей), чтобы ссылки не бились.
Всё это пакуется и собирается общая база знаний, а затем она копируется на сервер.
4. Затем обновляется поисковый индекс.
Разбор полетов: Наш GitLab CI/CD
Ниже — ключевые этапы нашей сборки. Я не буду уходить в дебри, остановлюсь на важных нюансах.
- Этап синхронизации (Sync): Здесь мы используем node:24-alpine. Главная хитрость — обход прокси для внутреннего GitLab. Мы прописываем IP бэкенда прямо в ~/.ssh/config. Скрипт перебирает repos.json, клонирует репозитории и вытягивает Markdown-файлы.
- Сборка (Build): Стандартный npm run build. На выходе получаем готовую статику в папке build/.
- Деплой (Deploy): Используем старый добрый rsync через SSH. Это быстрее и надежнее для обновления только измененных файлов. Работает, кстати, такое очень быстро.
- Индексация (Index): А вот тут самое интересное.
Поиск: Почему Meilisearch, а не Algolia?
В прошлой статье я хвалил Algolia, но в итоге мы развернули Meilisearch. Почему?
- Полный контроль: Всё крутится на нашем сервере.
- Скорость: Он быстрый.
- Стоимость: Для наших объемов это бесплатно, при этом качество выдачи не уступает облачным гигантам.
Сейчас на docs.softonit.ru уже можно посмотреть результат.
А как вы решаете вопрос с обновлением общей документации из разных репозиториев? Делаете мульти-проектные пайплайны или тоже живете на расписании? 👇
Зачем мы строим планы, когда всё летит в тартарары?
Посмотрел на выходных выпуск-подкаст, тема была не совсем про ИТ. В подкасте говорили о несправедливости и личном выборе. Мне понравился один момент, который как мне кажется хорошо перекликается с ИТ-проектами.
Там зачитывают вопрос подписчика:
Знакомая ситуация для любого руководителя в последние годы. Лег сервер, уволился ключевой сотрудник, срываются сроки проекта и т.п.
Автор дает ответ, который меня зацепил: Это вопрос не про план, это вопрос про ощущение контроля.
Я почему-то никогда в такой парадигме не думал…
Обычно план воспринимают как карту будущего. Но когда ничего не понятно, а в ИТ так почти всегда, функция у него другая. Психотерапевтическая. Когда есть план и ты начинаешь действовать, то перестаешь быть щепкой, которую несет течением. Возвращается субъектность и то самое ощущение контроля.
Если переложить это на нашу работу, становится понятно, зачем на самом деле нужны все эти роадмапы, спринты и стратегии. Даже если через месяц их придется переписывать.
1. План превращает панику в процедуру. Яркий пример — это план аварийного восстановления. Упал сервер и никто не знает, когда поднимется. Хаос. Но если есть инструкция, команда не бегает с криками «мы все умрем», а спокойно по пунктам делает работу. План не тушит пожар, он тушит панику в головах инженеров.
2. Снижается нагрузка на мозг. Спринты планируют не из слепой веры в неизменность задач на две недели. Это нужно, чтобы разработчик утром просто знал: сегодня я делаю задачу А. Меньше тревожности, больше фокуса.
3. Ловушка «иллюзии контроля». Тут важно быть честным, есть риск. В погоне за ощущением контроля руководители часто начинают управлять тем, до чего могут дотянуться, а не тем, что важно.
Не можешь гарантировать, что внешний провайдер не отключит API? От бессилия начинаешь следить, во сколько сотрудники приходят в офис, или считать строки кода. Вроде успокаивает — я же управляю! — но результат убивает. Такой вот карго-культ.
Резюме
Планирование в турбулентности нужно для сохранения холодной головы. Автор подкаста привел жесткий пример: даже если несешься в автобусе в пропасть, мысль о страховке и плане действий для семьи позволяет не истерить, а сгруппироваться и возможно, это спасет тебя.
В ИТ, да и в любом бизнесе то же самое. Планы строят не чтобы угадать будущее, это невозможно. Они нужны, чтобы здесь и сейчас команда чувствовала почву под ногами. Чтобы делали своё дело, а не рефлексировали над новостями.
Мне кажется, что это важная мысль и в текущее время это актуально как никогда. Планируйте проекты, друзья!
Посмотрел на выходных выпуск-подкаст, тема была не совсем про ИТ. В подкасте говорили о несправедливости и личном выборе. Мне понравился один момент, который как мне кажется хорошо перекликается с ИТ-проектами.
Там зачитывают вопрос подписчика:
Как строить планы на жизнь в горизонте пары лет, если я не знаю, что со мной будет через месяц?
Знакомая ситуация для любого руководителя в последние годы. Лег сервер, уволился ключевой сотрудник, срываются сроки проекта и т.п.
Автор дает ответ, который меня зацепил: Это вопрос не про план, это вопрос про ощущение контроля.
Я почему-то никогда в такой парадигме не думал…
Обычно план воспринимают как карту будущего. Но когда ничего не понятно, а в ИТ так почти всегда, функция у него другая. Психотерапевтическая. Когда есть план и ты начинаешь действовать, то перестаешь быть щепкой, которую несет течением. Возвращается субъектность и то самое ощущение контроля.
Если переложить это на нашу работу, становится понятно, зачем на самом деле нужны все эти роадмапы, спринты и стратегии. Даже если через месяц их придется переписывать.
1. План превращает панику в процедуру. Яркий пример — это план аварийного восстановления. Упал сервер и никто не знает, когда поднимется. Хаос. Но если есть инструкция, команда не бегает с криками «мы все умрем», а спокойно по пунктам делает работу. План не тушит пожар, он тушит панику в головах инженеров.
2. Снижается нагрузка на мозг. Спринты планируют не из слепой веры в неизменность задач на две недели. Это нужно, чтобы разработчик утром просто знал: сегодня я делаю задачу А. Меньше тревожности, больше фокуса.
3. Ловушка «иллюзии контроля». Тут важно быть честным, есть риск. В погоне за ощущением контроля руководители часто начинают управлять тем, до чего могут дотянуться, а не тем, что важно.
Не можешь гарантировать, что внешний провайдер не отключит API? От бессилия начинаешь следить, во сколько сотрудники приходят в офис, или считать строки кода. Вроде успокаивает — я же управляю! — но результат убивает. Такой вот карго-культ.
Резюме
Планирование в турбулентности нужно для сохранения холодной головы. Автор подкаста привел жесткий пример: даже если несешься в автобусе в пропасть, мысль о страховке и плане действий для семьи позволяет не истерить, а сгруппироваться и возможно, это спасет тебя.
В ИТ, да и в любом бизнесе то же самое. Планы строят не чтобы угадать будущее, это невозможно. Они нужны, чтобы здесь и сейчас команда чувствовала почву под ногами. Чтобы делали своё дело, а не рефлексировали над новостями.
Мне кажется, что это важная мысль и в текущее время это актуально как никогда. Планируйте проекты, друзья!
🔥2
Искусственный интеллект нарушает цепочку развития программных продуктов и это 100%
Прочел статью на Хабре о проблемах создателей Tailwind CSS и призадумался. Ситуация выглядит парадоксально. Продукт на пике популярности, но бизнес-модель рушится.
Давайте разберем механику этого процесса, потому что она касается не только CSS-фреймворков, но и всего Open Source.
Как это работало раньше и как Tailwind зарабатывала деньги
Возьмем Tailwind CSS. Это сверхпопулярный инструмент, стандарт де-факто в современной верстке. Его используют около 75% опрошенных разработчиков.
Раньше экономика Open Source продукта выглядела так:
1. Разработчик гуглит решение.
2. Попадает на сайт Tailwind.
3. Читает документацию.
4. Видит платные продукты (Tailwind UI — готовые компоненты) и покупает их, чтобы сэкономить время.
5. Деньги идут авторам фреймворка.
6. Авторы инвестируют в развитие ядра продукта.
Схема была здоровой:
Что изменилось с приходом AI
Теперь в игру вступили «умные» редакторы кода: Cursor, Copilot, Windsurf и т.п. Сценарий изменился кардинально:
1. Разработчик открывает IDE (например, Cursor).
2. Пишет промпт: «Сделай мне красивую кнопку на Tailwind».
3. Нейросеть генерирует код, используя знания о классах Tailwind CSS.
Разработчик не заходит на сайт, не видит рекламу платных китов, не покупает Tailwind UI.
Новая экономическая схема:
В чем проблема?
Разработчик инструмента Tailwind выпал из цепочки. Финансы уходят не создателю технологии, а создателю нейросети.
Это создает парадокс:
- Фреймворк популярен как никогда.
- Денежный поток создателей иссякает.
- Компании вынуждены увольнять сотрудников и сокращать инвестиции в развитие.
Змея, пожирающая сама себя
Это не просто «проблемы бизнеса». Это проблема всей индустрии. Если такие компании, как Tailwind, перестанут развивать свои продукты из-за нехватки средств, на чем будут учиться следующие версии нейросетей?
Нейросети не создают новые фреймворки, они используют существующие. Мы рискуем получить ситуацию, где AI паразитирует на текущих технологиях, убивая их создателей, и тем самым останавливает приток новых идей.
Искусственный интеллект нарушает естественную цепочку «финансирование — инновации». В краткосрочной перспективе нам удобно (код пишется быстро), но в долгосрочной это 100% приведет к стагнации инструментов, которыми мы пользуемся.
#Кейсы_КИД #РазборПродукта_КИД #Бизнес_КИД https://t.me/codeitdir/75?utm_source=Telegram&utm_medium=social&utm_campaign=27859428
Прочел статью на Хабре о проблемах создателей Tailwind CSS и призадумался. Ситуация выглядит парадоксально. Продукт на пике популярности, но бизнес-модель рушится.
Давайте разберем механику этого процесса, потому что она касается не только CSS-фреймворков, но и всего Open Source.
Как это работало раньше и как Tailwind зарабатывала деньги
Возьмем Tailwind CSS. Это сверхпопулярный инструмент, стандарт де-факто в современной верстке. Его используют около 75% опрошенных разработчиков.
Раньше экономика Open Source продукта выглядела так:
1. Разработчик гуглит решение.
2. Попадает на сайт Tailwind.
3. Читает документацию.
4. Видит платные продукты (Tailwind UI — готовые компоненты) и покупает их, чтобы сэкономить время.
5. Деньги идут авторам фреймворка.
6. Авторы инвестируют в развитие ядра продукта.
Схема была здоровой:
Клиент → Потребность → Документация/Сайт → Покупка доп. услуг → Деньги разработчику → Развитие продукта
Что изменилось с приходом AI
Теперь в игру вступили «умные» редакторы кода: Cursor, Copilot, Windsurf и т.п. Сценарий изменился кардинально:
1. Разработчик открывает IDE (например, Cursor).
2. Пишет промпт: «Сделай мне красивую кнопку на Tailwind».
3. Нейросеть генерирует код, используя знания о классах Tailwind CSS.
Разработчик не заходит на сайт, не видит рекламу платных китов, не покупает Tailwind UI.
Новая экономическая схема:
Клиент → Подписка на AI ($20/мес) → Нейросеть → Готовый код
В чем проблема?
Разработчик инструмента Tailwind выпал из цепочки. Финансы уходят не создателю технологии, а создателю нейросети.
Это создает парадокс:
- Фреймворк популярен как никогда.
- Денежный поток создателей иссякает.
- Компании вынуждены увольнять сотрудников и сокращать инвестиции в развитие.
Змея, пожирающая сама себя
Это не просто «проблемы бизнеса». Это проблема всей индустрии. Если такие компании, как Tailwind, перестанут развивать свои продукты из-за нехватки средств, на чем будут учиться следующие версии нейросетей?
Нейросети не создают новые фреймворки, они используют существующие. Мы рискуем получить ситуацию, где AI паразитирует на текущих технологиях, убивая их создателей, и тем самым останавливает приток новых идей.
Искусственный интеллект нарушает естественную цепочку «финансирование — инновации». В краткосрочной перспективе нам удобно (код пишется быстро), но в долгосрочной это 100% приведет к стагнации инструментов, которыми мы пользуемся.
#Кейсы_КИД #РазборПродукта_КИД #Бизнес_КИД https://t.me/codeitdir/75?utm_source=Telegram&utm_medium=social&utm_campaign=27859428
😱1💯1
Я вырастил сеньора из саппорта, а он ушел
Открываю в блоге новую рубрику — «Управленческие задачи». Здесь не будет теории из учебников MBA. Кейсы про команду, клиентов, ответственность и выбор, который приходится делать ежедневно в реальной работе. Почти всегда не содержит правильного ответа, но позволяет задуматься как можно повести себя в той или иной ситуации.
Сегодняшний кейс — о талантах, карьерном росте и страхе потерять сотрудника, сделав его слишком крутым.
Описание ситуации
Вы тимлид в ИТ-подразделении и взяли на работу на 1-ю линию сотрудника — Руслана (имя вымышлено). Его задача — отвечать на вопросы техподдержки, помогать тестированием функционала и писать документацию по продукту.
Спустя время, вы понимаете, что парень талантливый и потихоньку это ведет его вперед. Те вопросы, которые ему поручаются он выполняет достаточно хорошо и качественно. То, что отдано в работу Руслану, всегда выполняется в срок и качественно. Время идет, он растет и набирается опыта. Основной стек разработки — это 1С, и вы занимаетесь разработкой собственного решения на 1С. Получается так, что Руслан иногда сам в 1С отладчиком находит проблемы клиентов и разработчикам передает эту информацию. Т.е. парень прям серьезно вырос.
Тут случается непредвиденная ситуация. Два программиста одновременно решают уйти из компании. Перед вами появляется дилемма: как быстро закрыть эту потребность без потери качества, чтобы человек был сразу в теме и мог хотя бы частично эту потребность закрыть.
Вы вспоминаете про Руслана, т.к. именно в текущий момент это win/win.
- Для вас: вы получаете лояльного, мотивированного сотрудника, который уже знает продукт изнутри и готов развиваться.
- Для Руслана: он получает возможность расти дальше, но уже в роли разработчика и с другой мотивацией.
Вы разговариваете с Русланом и предлагаете ему эту должность. Он соглашается.
Спустя время вы понимаете, что Руслан отлично справляется со сменой должности и уже в роли разработчика 1С прекрасно себя показывает. Через год Руслан уже Middle+ и к нему начали поступать задачи на проектирование и разработку отдельных подсистем. Т.е. потенциально мы имеем Senior.
Развитие и финал
На очередном PR, Руслан сказал, что хотел бы уволиться. Причина не в деньгах (оффер не сработал). Причина в стеке. Компания пишет собственный продукт. Руслан осознал: работая над уникальным отраслевым решением, он теряет квалификацию по рынку. Рынок требует знания типовых конфигураций (Бухгалтерия, ERP, ЗУП и т.п.), а он «варится» в кастомном коде. Он бы хотел заниматься типовыми решениями 1С, а наша компания не может ему этого дать. Он увольняется и уходит в компанию на типовые проекты, чтобы оставаться ликвидным специалистом.
Альтернативное мнение: «Ты сам виноват»
Обсуждая эту ситуацию с коллегой-руководителем, я неожиданно услышал жесткую критику. Его позиция была такой:
Для меня такое решение вопроса спорное. Да и с этической стороной есть проблемы.
Вопросы для обсуждения
1. Насколько верным управленческим решением было предлагать Руслану перейти в разработку из техподдержки?
2. Верите ли вы в стратегию «искусственного сдерживания»? Если бы Руслан остался в поддержке, не ушел бы он еще раньше от скуки и отсутствия перспектив?
3. Если ваша компания разрабатывает собственный уникальный софт, как вы удерживаете разработчиков, которые боятся отстать от рынка и потерять квалификацию в типовых решениях (ERP / Spring / React и т.д.)?
4. Вы понимаете, что перед вами сотрудник-бриллиант пока без знаний, но с огромным потенциалом. Как лучше организовать развитие такого сотрудника, чтобы он не покинул компанию досрочно и принес максимум пользы?
Открываю в блоге новую рубрику — «Управленческие задачи». Здесь не будет теории из учебников MBA. Кейсы про команду, клиентов, ответственность и выбор, который приходится делать ежедневно в реальной работе. Почти всегда не содержит правильного ответа, но позволяет задуматься как можно повести себя в той или иной ситуации.
Сегодняшний кейс — о талантах, карьерном росте и страхе потерять сотрудника, сделав его слишком крутым.
Описание ситуации
Вы тимлид в ИТ-подразделении и взяли на работу на 1-ю линию сотрудника — Руслана (имя вымышлено). Его задача — отвечать на вопросы техподдержки, помогать тестированием функционала и писать документацию по продукту.
Спустя время, вы понимаете, что парень талантливый и потихоньку это ведет его вперед. Те вопросы, которые ему поручаются он выполняет достаточно хорошо и качественно. То, что отдано в работу Руслану, всегда выполняется в срок и качественно. Время идет, он растет и набирается опыта. Основной стек разработки — это 1С, и вы занимаетесь разработкой собственного решения на 1С. Получается так, что Руслан иногда сам в 1С отладчиком находит проблемы клиентов и разработчикам передает эту информацию. Т.е. парень прям серьезно вырос.
Тут случается непредвиденная ситуация. Два программиста одновременно решают уйти из компании. Перед вами появляется дилемма: как быстро закрыть эту потребность без потери качества, чтобы человек был сразу в теме и мог хотя бы частично эту потребность закрыть.
Вы вспоминаете про Руслана, т.к. именно в текущий момент это win/win.
- Для вас: вы получаете лояльного, мотивированного сотрудника, который уже знает продукт изнутри и готов развиваться.
- Для Руслана: он получает возможность расти дальше, но уже в роли разработчика и с другой мотивацией.
Вы разговариваете с Русланом и предлагаете ему эту должность. Он соглашается.
Спустя время вы понимаете, что Руслан отлично справляется со сменой должности и уже в роли разработчика 1С прекрасно себя показывает. Через год Руслан уже Middle+ и к нему начали поступать задачи на проектирование и разработку отдельных подсистем. Т.е. потенциально мы имеем Senior.
Развитие и финал
На очередном PR, Руслан сказал, что хотел бы уволиться. Причина не в деньгах (оффер не сработал). Причина в стеке. Компания пишет собственный продукт. Руслан осознал: работая над уникальным отраслевым решением, он теряет квалификацию по рынку. Рынок требует знания типовых конфигураций (Бухгалтерия, ERP, ЗУП и т.п.), а он «варится» в кастомном коде. Он бы хотел заниматься типовыми решениями 1С, а наша компания не может ему этого дать. Он увольняется и уходит в компанию на типовые проекты, чтобы оставаться ликвидным специалистом.
Альтернативное мнение: «Ты сам виноват»
Обсуждая эту ситуацию с коллегой-руководителем, я неожиданно услышал жесткую критику. Его позиция была такой:
Ты совершил ошибку. Таких людей нельзя переводить в разработку, если у тебя «самописная конфигурация». В поддержке он был бы звездой. Он чувствовал бы себя нужным, у него была бы стабильная зарплата, и ему некуда было бы деваться, потому что навыки саппорта специфичны. А ты дал ему в руки профессию, которая позволяет ему выбирать. Мы у себя намеренно ограничиваем вертикальный рост таких кадров, чтобы они дольше приносили пользу на своем месте.
Для меня такое решение вопроса спорное. Да и с этической стороной есть проблемы.
Вопросы для обсуждения
1. Насколько верным управленческим решением было предлагать Руслану перейти в разработку из техподдержки?
2. Верите ли вы в стратегию «искусственного сдерживания»? Если бы Руслан остался в поддержке, не ушел бы он еще раньше от скуки и отсутствия перспектив?
3. Если ваша компания разрабатывает собственный уникальный софт, как вы удерживаете разработчиков, которые боятся отстать от рынка и потерять квалификацию в типовых решениях (ERP / Spring / React и т.д.)?
4. Вы понимаете, что перед вами сотрудник-бриллиант пока без знаний, но с огромным потенциалом. Как лучше организовать развитие такого сотрудника, чтобы он не покинул компанию досрочно и принес максимум пользы?
Как Яндекс бесплатной почтой убил конкурентов и посадил бизнес на подписку
Оплачивал на днях Яндекс 360 для бизнеса и поймал себя на мысли: а ведь мог бы поднять почту на своём сервере. Домен есть, VPS есть. Но каждый раз как подхожу к этой задаче, вспоминаю про настройку DKIM, SPF, борьбу со спам-листами, мониторинг, бэкапы... И откладываю.
А потом вспомнил, как вообще оказался в этой ситуации.
Что было до 2009 года
Если тебе нужна была корпоративная почта на своём домене, варианты были невеселые. Либо поднимаешь свой почтовый сервер и мучаешься с настройками. Либо покупаешь почту у хостинга, платишь, а оно всё равно криво работает. Либо сидишь на бесплатных ящиках типа mail.ru и выглядишь несерьёзно.
Рынок бесплатной почты для физлиц к тому моменту уже поделили. Расти некуда. И тут Яндекс придумал ход.
Что сделал Яндекс
В 2009 году появился pdd.yandex.ru. Суть простая: подключаешь свой домен, прописываешь MX-записи, и в пару кликов получаешь корпоративную почту ivan@moicompany.ru на мощностях Яндекса. Бесплатно и без лимитов.
Бизнес начал перетекать. Зачем платить хостингу или возиться с сервером, если Яндекс даёт всё то же самое, но бесплатно?
Как это работало
Сначала Яндекс занял рынок за свой счёт. Бесплатный сервис привлёк массу мелкого и среднего бизнеса. Кто будет платить хостингу за почту, если можно бесплатно? Конкуренты посыпались.
Параллельно Яндекс допиливал экосистему: Диск, Календарь, потом Телемост, Трекер. Всё это обрастало вокруг почты, затягивало глубже.
А в 2023 году бесплатный тариф убрали. Теперь это Яндекс 360 за деньги. Все клиенты уже внутри, переезжать дорого и больно. Конкурентов нет.
К чему это я
Модель рабочая: входи бесплатно, расти вместе с клиентом, закрывай монетизацию когда рынок твой. С Яндекс Go было очень похоже. Субсидировали поездки, демпинговали, поглотили Uber Russia. Теперь цены растут, а альтернатив почти нет.
Меня вот что цепляет: мы как бизнес сидим на таких сервисах и вроде понимаем риски. Но каждый раз удивляемся, когда бесплатное становится платным. Я вот сам до сих пор плачу Яндексу, хотя технически мог бы съехать.
А вы как решаете? Платите и не паритесь, или ищете альтернативы?
Оплачивал на днях Яндекс 360 для бизнеса и поймал себя на мысли: а ведь мог бы поднять почту на своём сервере. Домен есть, VPS есть. Но каждый раз как подхожу к этой задаче, вспоминаю про настройку DKIM, SPF, борьбу со спам-листами, мониторинг, бэкапы... И откладываю.
А потом вспомнил, как вообще оказался в этой ситуации.
Что было до 2009 года
Если тебе нужна была корпоративная почта на своём домене, варианты были невеселые. Либо поднимаешь свой почтовый сервер и мучаешься с настройками. Либо покупаешь почту у хостинга, платишь, а оно всё равно криво работает. Либо сидишь на бесплатных ящиках типа mail.ru и выглядишь несерьёзно.
Рынок бесплатной почты для физлиц к тому моменту уже поделили. Расти некуда. И тут Яндекс придумал ход.
Что сделал Яндекс
В 2009 году появился pdd.yandex.ru. Суть простая: подключаешь свой домен, прописываешь MX-записи, и в пару кликов получаешь корпоративную почту ivan@moicompany.ru на мощностях Яндекса. Бесплатно и без лимитов.
Бизнес начал перетекать. Зачем платить хостингу или возиться с сервером, если Яндекс даёт всё то же самое, но бесплатно?
Как это работало
Сначала Яндекс занял рынок за свой счёт. Бесплатный сервис привлёк массу мелкого и среднего бизнеса. Кто будет платить хостингу за почту, если можно бесплатно? Конкуренты посыпались.
Параллельно Яндекс допиливал экосистему: Диск, Календарь, потом Телемост, Трекер. Всё это обрастало вокруг почты, затягивало глубже.
А в 2023 году бесплатный тариф убрали. Теперь это Яндекс 360 за деньги. Все клиенты уже внутри, переезжать дорого и больно. Конкурентов нет.
К чему это я
Модель рабочая: входи бесплатно, расти вместе с клиентом, закрывай монетизацию когда рынок твой. С Яндекс Go было очень похоже. Субсидировали поездки, демпинговали, поглотили Uber Russia. Теперь цены растут, а альтернатив почти нет.
Меня вот что цепляет: мы как бизнес сидим на таких сервисах и вроде понимаем риски. Но каждый раз удивляемся, когда бесплатное становится платным. Я вот сам до сих пор плачу Яндексу, хотя технически мог бы съехать.
А вы как решаете? Платите и не паритесь, или ищете альтернативы?
За 2.5 года страх перед ИИ вырос с 13% до 47%
Иногда почитываю Reddit и случайно наткнулся на график, от которого стало как-то не по себе. Какой-то энтузиаст три года подряд каждые полгода спрашивает коллег из FAANG одно и то же: Насколько вы переживаете, что ИИ заберет вашу работу?
Посмотрите на август 2023. 87% людей отвечали в духе «да ладно, это никогда не произойдет».
А сейчас, в январе 2026 только 17% не переживают. Почти половина (47%!) говорят «меня могут заменить сегодня».
Что вообще произошло
В 2023 ChatGPT был прикольной штукой / игрушкой. Да, он мог написать стишок или письмо, но всерьез его воспринимали разве что хайпожоры. Все эти шутки про «нейросеть как второклассник», помните?
Сегодня все, мягко говоря, чуть-чуть не так. Claude Code генерит код, который я отправляю в прод после минимальной правки (есть такой грешок). Cursor дописывает не просто следующую строку, а целую функцию, причем часто именно ту, что мне нужна. Появляются агенты типа OpenClaw, которые и память свою имеют и где-то даже самостоятельны.
Я думаю вот что: дело не в том, что ИИ вдруг стал супер-умным (хотя и не без этого, LLM умнеют). Просто люди наконец ощутили разницу. Не в теории, а на своей шкуре. Увидели, как задачи на три часа теперь закрываются за двадцать минут.
Вот это «ощутили» и есть переломный момент.
Комментарии оттуда же
Я полез читать обсуждение под постом. Там целая война разгорелась.
Кто-то пишет: «На мой взгляд, это огромная часть перемен. Трудно получить нейтральное мнение, когда на кону твоя работа.»
А кто-то отвечает в духе: «Да успокойтесь вы все. ИИ — просто инструмент. Молоток не заменил плотника? Excel не убил бухгалтеров? И здесь так же будет».
Что я об этом думаю
Последние полгода я довольно активно юзаю ИИ в работе над УИТ. Пришел к одной мысли:
Короче, не сама технология угрожает людям. А те, кто ее освоил, угрожают тем, кто нет.
Раньше нормальный разработчик выдавал условно 200 строк годного кода в день. Сейчас с ИИ тот же разработчик может делать 500-700. Может даже больше, зависит от задачи. Планка сместилась. И если ты не подтянулся, ты уже позади.
Я как руководитель теперь не могу объяснить себе, зачем мне нанимать человека, который принципиально не использует эти штуки. Это же прямой удар по эффективности. Либо он делает меньше за ту же зарплату, либо мне надо платить больше за тот же результат.
Наверное, именно эта логика и добралась до тех 47% обеспокоенных людей из опроса.
Вопрос открытый
У себя используем Cursor, $40 подписка на рабочее место + $50 в месяц каждому сверх лимита. В прошлом месяце купил Claude Code попробовать, наверное будем менять схему работы.
Хотелось бы узнать а как у вас в компании? Команда уже активно работает с ИИ, есть такое же беспокойство как на Reddit?
У нас в Софтоните я не то чтобы требую, но очень настоятельно рекомендую использовать. Сам показываю, как работает, разбираем кейсы. Но вот честно не знаю, правильный ли это подход. Может, кто-то делает иначе и это работает лучше?
Делитесь в комментах, правда интересно.
Пруф: https://www.reddit.com/r/dataisbeautiful/comments/1qp1n0r/oc_for_the_past_3_years_ive_polled_people_on/
Иногда почитываю Reddit и случайно наткнулся на график, от которого стало как-то не по себе. Какой-то энтузиаст три года подряд каждые полгода спрашивает коллег из FAANG одно и то же: Насколько вы переживаете, что ИИ заберет вашу работу?
Посмотрите на август 2023. 87% людей отвечали в духе «да ладно, это никогда не произойдет».
А сейчас, в январе 2026 только 17% не переживают. Почти половина (47%!) говорят «меня могут заменить сегодня».
Что вообще произошло
В 2023 ChatGPT был прикольной штукой / игрушкой. Да, он мог написать стишок или письмо, но всерьез его воспринимали разве что хайпожоры. Все эти шутки про «нейросеть как второклассник», помните?
Сегодня все, мягко говоря, чуть-чуть не так. Claude Code генерит код, который я отправляю в прод после минимальной правки (есть такой грешок). Cursor дописывает не просто следующую строку, а целую функцию, причем часто именно ту, что мне нужна. Появляются агенты типа OpenClaw, которые и память свою имеют и где-то даже самостоятельны.
Я думаю вот что: дело не в том, что ИИ вдруг стал супер-умным (хотя и не без этого, LLM умнеют). Просто люди наконец ощутили разницу. Не в теории, а на своей шкуре. Увидели, как задачи на три часа теперь закрываются за двадцать минут.
Вот это «ощутили» и есть переломный момент.
Комментарии оттуда же
Я полез читать обсуждение под постом. Там целая война разгорелась.
Кто-то пишет: «На мой взгляд, это огромная часть перемен. Трудно получить нейтральное мнение, когда на кону твоя работа.»
А кто-то отвечает в духе: «Да успокойтесь вы все. ИИ — просто инструмент. Молоток не заменил плотника? Excel не убил бухгалтеров? И здесь так же будет».
Что я об этом думаю
Последние полгода я довольно активно юзаю ИИ в работе над УИТ. Пришел к одной мысли:
ИИ не заменит программиста. Но программист с ИИ точно заменит программиста без ИИ.
Короче, не сама технология угрожает людям. А те, кто ее освоил, угрожают тем, кто нет.
Раньше нормальный разработчик выдавал условно 200 строк годного кода в день. Сейчас с ИИ тот же разработчик может делать 500-700. Может даже больше, зависит от задачи. Планка сместилась. И если ты не подтянулся, ты уже позади.
Я как руководитель теперь не могу объяснить себе, зачем мне нанимать человека, который принципиально не использует эти штуки. Это же прямой удар по эффективности. Либо он делает меньше за ту же зарплату, либо мне надо платить больше за тот же результат.
Наверное, именно эта логика и добралась до тех 47% обеспокоенных людей из опроса.
Вопрос открытый
У себя используем Cursor, $40 подписка на рабочее место + $50 в месяц каждому сверх лимита. В прошлом месяце купил Claude Code попробовать, наверное будем менять схему работы.
Хотелось бы узнать а как у вас в компании? Команда уже активно работает с ИИ, есть такое же беспокойство как на Reddit?
У нас в Софтоните я не то чтобы требую, но очень настоятельно рекомендую использовать. Сам показываю, как работает, разбираем кейсы. Но вот честно не знаю, правильный ли это подход. Может, кто-то делает иначе и это работает лучше?
Делитесь в комментах, правда интересно.
Пруф: https://www.reddit.com/r/dataisbeautiful/comments/1qp1n0r/oc_for_the_past_3_years_ive_polled_people_on/
Как я разнес код интегратора и поплатился
В период моей работы в агрохолдинге нам поставили задачу внедрить 1С:УПП. Экспертизы не хватало, пригласили внедренцев. Нашли крупного интегратора, заключили договор.
Довелось поработать с группой во главе с Надеждой — хороший специалист. С ней работал опытный разработчик и Александра — отличный аналитик, которая только начинала пробовать себя в разработке.
Мне поставили задачу контролировать код. Тогда в 1С не было тестов и devops. Всё ручками. Ну а я же максималист / правдоруб 🙂
Открываю конфигуратор и погнали. С первых строчек стало не очень... Открыл Word, начал добавлять замечания. Пункты перевалили за 20. Запросы в цикле, мёртвый код, обилие закомментированных кусков.
В конце написал:
Вы крупный интегратор, вы занимаетесь автоматизацией и обслуживаете крупных клиентов. Непозволительно использовать в продакшн такой код. Это непрофессионально.Сейчас бы я так никогда не сделал. Я бы встретился с руководителем, обсудил, поговорил. Попытался бы оценить насколько там вменяемый человек и после этого принял бы решение как быть дальше. Идти к руководству, или мы бы поговорили и они бы исправили все замечания — и дело с концом.
Но тогда я не видел проблемы. Искренне думал: раз наша компания платит (немалые деньги), то я, как представитель заказчика, имею полное право требовать от исполнителей качества.
Эх, что после моих последних строк началось! Надежда была в ярости:
Виталий! Александра написала заявление на увольнение — это она делала этот код! Зачем ты так написал?! Что теперь делать с внедрением? Человек плачет, хочет уволиться. Она преподавала, но решила пойти в разработку, а ты так унизительно отозвался о её профессиональных качествах.Я тоже не остался в долгу и спросил зачем они поставили писать код человека, который совсем нулевой? Почему опытный разработчик, который был с ними в команде, не провёл своё ревью? Мы разругались тогда с ней очень серьёзно. Вплоть до того, что потом не разговаривали.
А дальше опытный разработчик с их стороны всё поправил и проект поехал дальше. Но шёл с огромным скрипом. А через время я уволился.
Всё было бы просто, если бы это был конец истории. Но нет.
Супруга общалась с коллегой Ириной. Муж и жена — одна сатана, мы познакомились, завязалось общение. Через время Ира родила дочь и решила покрестить. Позвала меня крёстным. Спросил, кто будет крёстной — внятного ответа не получил. Чувствуете куда катится история? )))
День крещения — та-да-ам! Надежда будет крёстной! Стоим и смотрим друг на друга. Немая пауза: «ты что здесь делаешь?» 🙂
Всё обошлось. Время и неловкость сбили негатив.
К чему история? ИТ-мир тесный. Земля круглая. Сегодня разносишь чей-то код, а через пару лет стоишь с этим человеком у купели.
После той ситуации я стал по-другому подходить к ревью. Не то чтобы стал добрее — просто понял, что за каждым куском кода стоит живой человек. Можно написать "запрос в цикле, исправить" — и получить тот же результат. А можно написать "непрофессионально" — и получить заявление на увольнение и испорченные отношения на годы.
Если вижу слабый код от подрядчика, стараюсь сначала поговорить с руководителем. Обсудить, понять контекст. Замечания — к коду, не к человеку. Звучит банально, но мне потребовался скандал и случайная встреча на крестинах, чтобы это до меня дошло.
В период моей работы в агрохолдинге нам поставили задачу внедрить 1С:УПП. Экспертизы не хватало, пригласили внедренцев. Нашли крупного интегратора, заключили договор.
Довелось поработать с группой во главе с Надеждой — хороший специалист. С ней работал опытный разработчик и Александра — отличный аналитик, которая только начинала пробовать себя в разработке.
Мне поставили задачу контролировать код. Тогда в 1С не было тестов и devops. Всё ручками. Ну а я же максималист / правдоруб 🙂
Открываю конфигуратор и погнали. С первых строчек стало не очень... Открыл Word, начал добавлять замечания. Пункты перевалили за 20. Запросы в цикле, мёртвый код, обилие закомментированных кусков.
В конце написал:
Вы крупный интегратор, вы занимаетесь автоматизацией и обслуживаете крупных клиентов. Непозволительно использовать в продакшн такой код. Это непрофессионально.Сейчас бы я так никогда не сделал. Я бы встретился с руководителем, обсудил, поговорил. Попытался бы оценить насколько там вменяемый человек и после этого принял бы решение как быть дальше. Идти к руководству, или мы бы поговорили и они бы исправили все замечания — и дело с концом.
Но тогда я не видел проблемы. Искренне думал: раз наша компания платит (немалые деньги), то я, как представитель заказчика, имею полное право требовать от исполнителей качества.
Эх, что после моих последних строк началось! Надежда была в ярости:
Виталий! Александра написала заявление на увольнение — это она делала этот код! Зачем ты так написал?! Что теперь делать с внедрением? Человек плачет, хочет уволиться. Она преподавала, но решила пойти в разработку, а ты так унизительно отозвался о её профессиональных качествах.Я тоже не остался в долгу и спросил зачем они поставили писать код человека, который совсем нулевой? Почему опытный разработчик, который был с ними в команде, не провёл своё ревью? Мы разругались тогда с ней очень серьёзно. Вплоть до того, что потом не разговаривали.
А дальше опытный разработчик с их стороны всё поправил и проект поехал дальше. Но шёл с огромным скрипом. А через время я уволился.
Всё было бы просто, если бы это был конец истории. Но нет.
Супруга общалась с коллегой Ириной. Муж и жена — одна сатана, мы познакомились, завязалось общение. Через время Ира родила дочь и решила покрестить. Позвала меня крёстным. Спросил, кто будет крёстной — внятного ответа не получил. Чувствуете куда катится история? )))
День крещения — та-да-ам! Надежда будет крёстной! Стоим и смотрим друг на друга. Немая пауза: «ты что здесь делаешь?» 🙂
Всё обошлось. Время и неловкость сбили негатив.
К чему история? ИТ-мир тесный. Земля круглая. Сегодня разносишь чей-то код, а через пару лет стоишь с этим человеком у купели.
После той ситуации я стал по-другому подходить к ревью. Не то чтобы стал добрее — просто понял, что за каждым куском кода стоит живой человек. Можно написать "запрос в цикле, исправить" — и получить тот же результат. А можно написать "непрофессионально" — и получить заявление на увольнение и испорченные отношения на годы.
Если вижу слабый код от подрядчика, стараюсь сначала поговорить с руководителем. Обсудить, понять контекст. Замечания — к коду, не к человеку. Звучит банально, но мне потребовался скандал и случайная встреча на крестинах, чтобы это до меня дошло.
🔥4👍1
Я был не прав про ИИ в 1С
Полгода назад я написал статью Искусственный интеллект в 1С: будущее и перспективы и довольно скептически оценил перспективы ИИ в разработке на 1С. Говорил про контекстное окно, про поздний старт компании 1С в ИИ-гонке, про нехватку обучающих данных на BSL. Выводы были пессимистичные.
Сегодня признаю: я ошибся. Не во всём, но в главном. ИИ уже может продуктивно работать с кодом 1С. Не когда-нибудь потом, а прямо сейчас.
Что изменилось
Я недооценил MCP (Model Context Protocol). Когда писал ту статью, мыслил в парадигме «закинуть весь контекст конфигурации в нейросеть». Это невозможно, конфигурации 1С огромны. Но MCP перевернул подход. Вместо того чтобы загружать весь контекст, мы даём нейросети инструменты для работы с ним. Как обычному программисту: открыл модуль, посмотрел код, нашёл нужное, написал своё.
Проблема контекстного окна решена. Не расширением окна, а сменой подхода.
Claude Code Max
Я взял подписку Claude Code Max и после первого месяца понял, что назад дороги нет. Claude Opus в агентном режиме цепко держит контекст задачи, планирует выполнение, запускает субагентов и параллелит работу. Не теряется на полпути, доводит до конца. Моя скорость ощутимо выросла.
Купил Max-подписку и для команды. Да, дорого. Но я смотрю на это иначе: у каждого разработчика появляется персональный Junior/Middle помощник. Он и код напишет, и тесты подготовит, и документацию оформит. Попробуйте нанять живого джуна за эти деньги))
EDT-MCP: ИИ в 1C:EDT
Расширение EDT-MCP придумал и реализовал Дмитрий Шерстобитов. Я тоже участвую в развитии проекта.
В 1C:EDT уже есть всё, чем пользуется программист: поиск по коду, автодополнение, BSL-проверки, семантический поиск. Идея: отдать всё это нейросети через MCP. Посадить ИИ за EDT как обычного программиста.
И этот подход работает. Открываешь 1C:EDT с проектом, рядом запускаешь VS Code с той же папкой и пишешь задачу в чате. ИИ через MCP получает контекст из EDT, проверяет код, использует подсказки платформы, методы, семантический поиск. На выходе получается довольно качественный код.
Но есть границы. Формы верстать через MCP пока нельзя, и тут начинаются проблемы. Что-то простое нейросеть соберёт сама, но сложная вёрстка форм пока ей не по зубам. Это ограничение конкретного MCP, не подхода в целом.
Почему не RAG
В сообществе 1С я видел другой подход: RAG-системы плюс MCP по справке платформы. Индексируют документацию, встраивают в векторные базы, поднимают Qdrant, Embeddings, пачку Docker-контейнеров.
Считаю этот подход тупиковым. Разработчику не нужны конспекты. Мы открываем код и понимаем, как он работает. Базовые концепции держим в голове, остальное находим по ситуации.
Мне нравится аналогия с Tesla Vision. Tesla отказалась от лидаров и полагается только на камеры. Казалось бы, лидар надёжнее: точные данные о расстояниях, трёхмерная карта пространства. Но логика Tesla проста: если человек справляется с вождением, используя только глаза, значит и машина может.
С RAG нужно постоянно индексировать. Данные устарели, нейросеть найдёт неактуальное. Как индексировать, какие модели для векторизации, как поддерживать базу? Лишний слой сложности.
MCP-подход проще. Дай нейросети инструменты, пусть работает с живым кодом напрямую. Как программист. Да, что-то записывает себе куда-то, но не тотально, а только то, что важно в проекте.
Итого
ИИ в разработке 1С работает. Не идеально, с ограничениями по формам, но работает. Claude Code плюс EDT-MCP уже дают ощутимый прирост скорости.
Не нужно ждать, пока фирма «1С» сделает свой ИИ-инструмент. Сообщество уже создаёт решения, которые можно использовать. Чем раньше начнёте, тем больше выиграете.
Полгода назад я написал статью Искусственный интеллект в 1С: будущее и перспективы и довольно скептически оценил перспективы ИИ в разработке на 1С. Говорил про контекстное окно, про поздний старт компании 1С в ИИ-гонке, про нехватку обучающих данных на BSL. Выводы были пессимистичные.
Сегодня признаю: я ошибся. Не во всём, но в главном. ИИ уже может продуктивно работать с кодом 1С. Не когда-нибудь потом, а прямо сейчас.
Что изменилось
Я недооценил MCP (Model Context Protocol). Когда писал ту статью, мыслил в парадигме «закинуть весь контекст конфигурации в нейросеть». Это невозможно, конфигурации 1С огромны. Но MCP перевернул подход. Вместо того чтобы загружать весь контекст, мы даём нейросети инструменты для работы с ним. Как обычному программисту: открыл модуль, посмотрел код, нашёл нужное, написал своё.
Проблема контекстного окна решена. Не расширением окна, а сменой подхода.
Claude Code Max
Я взял подписку Claude Code Max и после первого месяца понял, что назад дороги нет. Claude Opus в агентном режиме цепко держит контекст задачи, планирует выполнение, запускает субагентов и параллелит работу. Не теряется на полпути, доводит до конца. Моя скорость ощутимо выросла.
Купил Max-подписку и для команды. Да, дорого. Но я смотрю на это иначе: у каждого разработчика появляется персональный Junior/Middle помощник. Он и код напишет, и тесты подготовит, и документацию оформит. Попробуйте нанять живого джуна за эти деньги))
EDT-MCP: ИИ в 1C:EDT
Расширение EDT-MCP придумал и реализовал Дмитрий Шерстобитов. Я тоже участвую в развитии проекта.
В 1C:EDT уже есть всё, чем пользуется программист: поиск по коду, автодополнение, BSL-проверки, семантический поиск. Идея: отдать всё это нейросети через MCP. Посадить ИИ за EDT как обычного программиста.
И этот подход работает. Открываешь 1C:EDT с проектом, рядом запускаешь VS Code с той же папкой и пишешь задачу в чате. ИИ через MCP получает контекст из EDT, проверяет код, использует подсказки платформы, методы, семантический поиск. На выходе получается довольно качественный код.
Но есть границы. Формы верстать через MCP пока нельзя, и тут начинаются проблемы. Что-то простое нейросеть соберёт сама, но сложная вёрстка форм пока ей не по зубам. Это ограничение конкретного MCP, не подхода в целом.
Почему не RAG
В сообществе 1С я видел другой подход: RAG-системы плюс MCP по справке платформы. Индексируют документацию, встраивают в векторные базы, поднимают Qdrant, Embeddings, пачку Docker-контейнеров.
Считаю этот подход тупиковым. Разработчику не нужны конспекты. Мы открываем код и понимаем, как он работает. Базовые концепции держим в голове, остальное находим по ситуации.
Мне нравится аналогия с Tesla Vision. Tesla отказалась от лидаров и полагается только на камеры. Казалось бы, лидар надёжнее: точные данные о расстояниях, трёхмерная карта пространства. Но логика Tesla проста: если человек справляется с вождением, используя только глаза, значит и машина может.
С RAG нужно постоянно индексировать. Данные устарели, нейросеть найдёт неактуальное. Как индексировать, какие модели для векторизации, как поддерживать базу? Лишний слой сложности.
MCP-подход проще. Дай нейросети инструменты, пусть работает с живым кодом напрямую. Как программист. Да, что-то записывает себе куда-то, но не тотально, а только то, что важно в проекте.
Итого
ИИ в разработке 1С работает. Не идеально, с ограничениями по формам, но работает. Claude Code плюс EDT-MCP уже дают ощутимый прирост скорости.
Не нужно ждать, пока фирма «1С» сделает свой ИИ-инструмент. Сообщество уже создаёт решения, которые можно использовать. Чем раньше начнёте, тем больше выиграете.
👍2🔥1
Сеньор не сеньор?
Недавно наткнулся на пост, где автор сравнивает типичного разработчика «сеньора» с водителем, который 8 лет ездил по одному маршруту до магазина и обратно, а теперь называет себя профессиональным гонщиком. Грубовато, но в точку.
Сеньоров на рынке с каждым годом всё больше. Сеньорности правда всё меньше :)
Откуда они берутся
Во многих компаниях грейд-система заканчивается на Senior. Отработал 5-8 лет, прошёл пару повышений, а дальше расти некуда. Только в тимлиды, а это вообще другая профессия. Грейд присваивается по выслуге лет. В стартапах ещё проще: ты единственный разработчик, вот тебе и Senior в резюме.
В 1С-мире все тоже самое. Человек 10 лет сопровождает одну конфигурацию на одном предприятии. Знает её вдоль и поперёк. Но ни разу не проектировал ничего с нуля, не трогал нагруженные системы, не принимал решений, от которых зависит продукт целиком. И при этом на собеседовании говорит: «Я сеньор, у меня десять лет опыта». Он прав? Конечно нет.
А в чём разница?
Вот что я заметил за годы найма. Опыт, штука обманчивая. Можно десять лет расти, а можно один год прожить десять раз подряд.
Человек, которого я про себя называю сеньором, думает не про свой модуль. Он думает про систему в целом. Прикидывает, во сколько обойдётся поддержка через пару лет и куда развивать продукт. Когда команда буксует, не ждёт, пока кто-то разрулит, а сам лезет разбираться. Ну и да, берёт на себя ответственность за результат. Не за тикет, не за свой кусок кода, а за результат.
Почему меня это беспокоит
Для бизнеса это конкретные деньги. Платишь сеньорную зарплату, ждёшь, что человек потянет проект. А получаешь исполнителя, который сидит и ждёт задачу.
Для самих разработчиков тут ловушка еще хуже. Получил грейд, и мотивация расти куда-то испаряется. Зачем напрягаться, если ты уже на верхней ступеньке? Это как чёрный пояс после трёх лет тренировок, звучит красиво, но на ринге бесполезно.
Что я делаю у себя
Резюме я давно не читаю всерьёз, тем более сейчас в эпоху ИИ. Конечно, пробегаю глазами, но решение принимаю по другому: как человек думает, какие вопросы задаёт, что делает, когда задача размытая.
Уважаю, когда разработчик берет задачу, где заведомо не хватает данных и начинает уточнять контекст и предлагать варианты. С таким интересно разговаривать и приходить к решению. Тот, кто спрашивает «а где ТЗ?», ну, тоже нормальный специалист. Просто не сеньор.
А если ты разработчик и читаешь это, то тебе один совет. Оторвись от своего модуля. Разберись, зачем бизнесу то, что ты пишешь. Кто этим пользуется, какие у них боли? Сеньорность начинается не с количества отработанных лет в резюме, а с момента, когда тебе становится не всё равно, что происходит за пределами твоего кода.
Недавно наткнулся на пост, где автор сравнивает типичного разработчика «сеньора» с водителем, который 8 лет ездил по одному маршруту до магазина и обратно, а теперь называет себя профессиональным гонщиком. Грубовато, но в точку.
Сеньоров на рынке с каждым годом всё больше. Сеньорности правда всё меньше :)
Откуда они берутся
Во многих компаниях грейд-система заканчивается на Senior. Отработал 5-8 лет, прошёл пару повышений, а дальше расти некуда. Только в тимлиды, а это вообще другая профессия. Грейд присваивается по выслуге лет. В стартапах ещё проще: ты единственный разработчик, вот тебе и Senior в резюме.
В 1С-мире все тоже самое. Человек 10 лет сопровождает одну конфигурацию на одном предприятии. Знает её вдоль и поперёк. Но ни разу не проектировал ничего с нуля, не трогал нагруженные системы, не принимал решений, от которых зависит продукт целиком. И при этом на собеседовании говорит: «Я сеньор, у меня десять лет опыта». Он прав? Конечно нет.
А в чём разница?
Вот что я заметил за годы найма. Опыт, штука обманчивая. Можно десять лет расти, а можно один год прожить десять раз подряд.
Человек, которого я про себя называю сеньором, думает не про свой модуль. Он думает про систему в целом. Прикидывает, во сколько обойдётся поддержка через пару лет и куда развивать продукт. Когда команда буксует, не ждёт, пока кто-то разрулит, а сам лезет разбираться. Ну и да, берёт на себя ответственность за результат. Не за тикет, не за свой кусок кода, а за результат.
Почему меня это беспокоит
Для бизнеса это конкретные деньги. Платишь сеньорную зарплату, ждёшь, что человек потянет проект. А получаешь исполнителя, который сидит и ждёт задачу.
Для самих разработчиков тут ловушка еще хуже. Получил грейд, и мотивация расти куда-то испаряется. Зачем напрягаться, если ты уже на верхней ступеньке? Это как чёрный пояс после трёх лет тренировок, звучит красиво, но на ринге бесполезно.
Что я делаю у себя
Резюме я давно не читаю всерьёз, тем более сейчас в эпоху ИИ. Конечно, пробегаю глазами, но решение принимаю по другому: как человек думает, какие вопросы задаёт, что делает, когда задача размытая.
Уважаю, когда разработчик берет задачу, где заведомо не хватает данных и начинает уточнять контекст и предлагать варианты. С таким интересно разговаривать и приходить к решению. Тот, кто спрашивает «а где ТЗ?», ну, тоже нормальный специалист. Просто не сеньор.
А если ты разработчик и читаешь это, то тебе один совет. Оторвись от своего модуля. Разберись, зачем бизнесу то, что ты пишешь. Кто этим пользуется, какие у них боли? Сеньорность начинается не с количества отработанных лет в резюме, а с момента, когда тебе становится не всё равно, что происходит за пределами твоего кода.
👍8👀1
X в 2026-м напомнил, что такое хороший продуктовый сдвиг
Не думал, что соцсеть сможет меня удивить в 2026 году. X удивил.
Никогда особо не тяготел к Twitter. Заходил, смотрел, уходил. Много английского текста, чужие алгоритмы, общий шум. Не моё.
8 апреля X раскатал автоперевод на всех пользователей, и что-то поменялось. Лента читается на русском. Без кнопки «перевести», без копирования в переводчик. Работает по умолчанию, под капотом Grok.
Технически фича не новая, X экспериментировал с ней через Grok ещё с середины 2025-го. Но одно дело эксперимент для части пользователей, другое, дефолт для всех. И вот в этом переключателе, на мой взгляд, и есть главный урок.
Звучит как мелочь, но попробуйте. Подписываешься на американского CTO, японского инженера или аргентинского стартапера и просто читаешь их мысли на родном языке. Доступ к первоисточникам без языкового барьера.
Без ложки дёгтя не обошлось. Первые дни часть пользователей злилась, не могла понять, что произошло, и искала, как это отключить. Классическая история: хорошая фича, плохой онбординг. Дефолты надо менять аккуратно, иначе даже правильное решение получает волну негатива.
И главный вопрос, который меня зацепил: почему другие так не сделали раньше? Telegram, VK, LinkedIn, везде либо кнопка на каждый пост, либо никак. Но X показал, что в 2026-м это уже решаемо. И тот, кто первым сделал фичу дефолтной, выиграл больше, чем тот, у кого она есть «по кнопке».
Дефолты решают. Почти всегда.
Пользуетесь X? Заметили изменение? Как вам качество перевода? 🤔
Не думал, что соцсеть сможет меня удивить в 2026 году. X удивил.
Никогда особо не тяготел к Twitter. Заходил, смотрел, уходил. Много английского текста, чужие алгоритмы, общий шум. Не моё.
8 апреля X раскатал автоперевод на всех пользователей, и что-то поменялось. Лента читается на русском. Без кнопки «перевести», без копирования в переводчик. Работает по умолчанию, под капотом Grok.
Технически фича не новая, X экспериментировал с ней через Grok ещё с середины 2025-го. Но одно дело эксперимент для части пользователей, другое, дефолт для всех. И вот в этом переключателе, на мой взгляд, и есть главный урок.
Звучит как мелочь, но попробуйте. Подписываешься на американского CTO, японского инженера или аргентинского стартапера и просто читаешь их мысли на родном языке. Доступ к первоисточникам без языкового барьера.
Без ложки дёгтя не обошлось. Первые дни часть пользователей злилась, не могла понять, что произошло, и искала, как это отключить. Классическая история: хорошая фича, плохой онбординг. Дефолты надо менять аккуратно, иначе даже правильное решение получает волну негатива.
И главный вопрос, который меня зацепил: почему другие так не сделали раньше? Telegram, VK, LinkedIn, везде либо кнопка на каждый пост, либо никак. Но X показал, что в 2026-м это уже решаемо. И тот, кто первым сделал фичу дефолтной, выиграл больше, чем тот, у кого она есть «по кнопке».
Дефолты решают. Почти всегда.
Пользуетесь X? Заметили изменение? Как вам качество перевода? 🤔
👍5
DDoS нашего сайта. Кто-то реально ходит на работу
Где-то недели две назад нас прощупывали. Рабочий сайт тупил. Часик так поработает и пауза. Какое-то время на это не обращал внимание, пока вчера сайт полностью не лег на целый день.
Сижу, смотрю в логи. За вчерашние сутки — 2 447 964 запроса. Средний RPS 28, в пиковые часы с 08:00 до 16:00, по 170 тысяч запросов в час, это ~50 RPS. Сегодня все в том же темпе.
У меня честный вопрос: кому мы мешаем? Мы небольшая IT-компания в нише, где нет большой политики и миллиардных контрактов. Конкуренты? Обиженный клиент? Пытаются сделать больно нашим клиентам в рабочее время? Разбираюсь по фактам.
Провел небольшое расследование и собрал статистику:
Всего запросов: 2 447 964
Средний RPS: 28
Пиковый час (16:00): 177 164 запросов
Минимум (20:00): 10 303 запросов
Вчерашнее распределение по часам:
С 07:00 до 18:00 стабильные 120-170 тысяч запросов в час. В 19:00 обрыв в 10 раз. В 21:00 — снова подъём до 34 тысяч. Ночью — средние 50-90 тысяч.
Бот, запущенный в режиме «поставил и ушёл», так себя не ведёт. Тут либо живой оператор, либо скрипт с расписанием, которому выставлены разные режимы на разные часы. И цель не «уронить сайт намертво», а именно замедлять его в рабочее время. С 19:00 до 20:00 — что-то вроде «ужина», потом снова вечерняя смена.
И самое показательное — поисковые запросы :
Это наши собственные теги из базы знаний продукта Управление IT-отделом 8. Кто-то ходил по сайту руками, собрал теги конкретно по нашему продукту (даже с указанием версий 3.0.37, 3.1.2, 3.1.6, 3.1.12.7) и скормил их боту. Атака «на авось» так не умеет. Это разведка, сделанная человеком, понимающим, что у нас за продукт и где у нас тяжёлые запросы.
Выводы
Атака распределённая (сотни уникальных IP, по 700-1400 запросов с каждого), но не из ботнета — это арендованная VPS-ферма.
Атака имитирует браузер: подтягивает всю статику, шлёт легальные URL.
Атака с предварительной разведкой: атакующий собрал конкретно наши теги с нашими версиями продукта.
Атака с живым оператором: работает по графику рабочего дня, ротирует источники день ко дню.
Бюджет атакующего — сотни долларов в месяц.
Три гипотезы, кому мы помешали
Без IR-расследования точного ответа не будет. Но версии стоит перебрать.
1. Конкуренты. Работа по графику рабочего дня, ручной подбор тегов по нашему продукту с номерами версий, ротация источников — всё указывает сюда. Аналитики РБК и Positive Technologies прямо говорят: DDoS как инструмент конкурентной борьбы чаще всего заказывают в узких нишах, где «немного просесть» конкуренту — заметный плюс себе. Ниша B2B-софта с понятной клиентской базой — идеальная мишень.
2. Отвлечение внимания. DDoS как дымовая завеса под другую активность: попытка эксплойта, брутфорс, вынос данных. В отчётах «Лаборатории Касперского» и «Солара» это второй по популярности сценарий 2025-го. Мы прошлись по логам аутентификаций и подозрительных POST — пока чисто, но внимание держим.
3. Заказ «на сдачу». Бывший клиент, бывший сотрудник. В 2025-м заказать DDoS стало тривиально: по Forbes и «Ростелекому», медианная цена атаки в даркнете — 20 долларов. Но наша атака дороже. Это не разовая покупка на 20 долларов, это длительный заказ с ротацией. Если «на сдачу», то от сильно обиженного с деньгами.
Я склоняюсь к первой версии.
А как вы защищаете свои сайты?
Где-то недели две назад нас прощупывали. Рабочий сайт тупил. Часик так поработает и пауза. Какое-то время на это не обращал внимание, пока вчера сайт полностью не лег на целый день.
Сижу, смотрю в логи. За вчерашние сутки — 2 447 964 запроса. Средний RPS 28, в пиковые часы с 08:00 до 16:00, по 170 тысяч запросов в час, это ~50 RPS. Сегодня все в том же темпе.
У меня честный вопрос: кому мы мешаем? Мы небольшая IT-компания в нише, где нет большой политики и миллиардных контрактов. Конкуренты? Обиженный клиент? Пытаются сделать больно нашим клиентам в рабочее время? Разбираюсь по фактам.
Провел небольшое расследование и собрал статистику:
Всего запросов: 2 447 964
Средний RPS: 28
Пиковый час (16:00): 177 164 запросов
Минимум (20:00): 10 303 запросов
Вчерашнее распределение по часам:
=== Нагрузка по часам (вчера) ===
00:00 — 84 690 запросов
01:00 — 42 586
02:00 — 57 603
03:00 — 75 511
04:00 — 91 871
05:00 — 94 590
06:00 — 98 846
07:00 — 146 990
08:00 — 171 044 ← пик утренний
09:00 — 140 138
10:00 — 161 200
11:00 — 140 094
12:00 — 148 158
13:00 — 112 530
14:00 — 141 870
15:00 — 121 985
16:00 — 177 164 ← пик вечерний, максимум дня
17:00 — 162 475
18:00 — 127 229
19:00 — 12 267 ← обрыв, -90%
20:00 — 10 303 ← минимум
21:00 — 34 834
22:00 — 35 838
23:00 — 58 148
С 07:00 до 18:00 стабильные 120-170 тысяч запросов в час. В 19:00 обрыв в 10 раз. В 21:00 — снова подъём до 34 тысяч. Ночью — средние 50-90 тысяч.
Бот, запущенный в режиме «поставил и ушёл», так себя не ведёт. Тут либо живой оператор, либо скрипт с расписанием, которому выставлены разные режимы на разные часы. И цель не «уронить сайт намертво», а именно замедлять его в рабочее время. С 19:00 до 20:00 — что-то вроде «ужина», потом снова вечерняя смена.
И самое показательное — поисковые запросы :
/search/?tags=Markdown,База знаний,Linux
/search/?tags=ITIL,договор,удаление данных
/search/?tags=3.1.6,вложения,обновления,личный кабинет
/search/?tags=3.1.2,обновление,Управление IT-отделом 8,пароли
/search/?tags=3.1.12.7,канбан,обновления,задание,уведомления
Это наши собственные теги из базы знаний продукта Управление IT-отделом 8. Кто-то ходил по сайту руками, собрал теги конкретно по нашему продукту (даже с указанием версий 3.0.37, 3.1.2, 3.1.6, 3.1.12.7) и скормил их боту. Атака «на авось» так не умеет. Это разведка, сделанная человеком, понимающим, что у нас за продукт и где у нас тяжёлые запросы.
Выводы
Атака распределённая (сотни уникальных IP, по 700-1400 запросов с каждого), но не из ботнета — это арендованная VPS-ферма.
Атака имитирует браузер: подтягивает всю статику, шлёт легальные URL.
Атака с предварительной разведкой: атакующий собрал конкретно наши теги с нашими версиями продукта.
Атака с живым оператором: работает по графику рабочего дня, ротирует источники день ко дню.
Бюджет атакующего — сотни долларов в месяц.
Три гипотезы, кому мы помешали
Без IR-расследования точного ответа не будет. Но версии стоит перебрать.
1. Конкуренты. Работа по графику рабочего дня, ручной подбор тегов по нашему продукту с номерами версий, ротация источников — всё указывает сюда. Аналитики РБК и Positive Technologies прямо говорят: DDoS как инструмент конкурентной борьбы чаще всего заказывают в узких нишах, где «немного просесть» конкуренту — заметный плюс себе. Ниша B2B-софта с понятной клиентской базой — идеальная мишень.
2. Отвлечение внимания. DDoS как дымовая завеса под другую активность: попытка эксплойта, брутфорс, вынос данных. В отчётах «Лаборатории Касперского» и «Солара» это второй по популярности сценарий 2025-го. Мы прошлись по логам аутентификаций и подозрительных POST — пока чисто, но внимание держим.
3. Заказ «на сдачу». Бывший клиент, бывший сотрудник. В 2025-м заказать DDoS стало тривиально: по Forbes и «Ростелекому», медианная цена атаки в даркнете — 20 долларов. Но наша атака дороже. Это не разовая покупка на 20 долларов, это длительный заказ с ротацией. Если «на сдачу», то от сильно обиженного с деньгами.
Я склоняюсь к первой версии.
А как вы защищаете свои сайты?
👍1
Claude Max vs API. Реальная разница в цене
Недавно у братьев Либерман в подкасте проскочила мысль: цены на LLM будут расти, потому что себестоимость уже выше подписок. Параллельно наткнулся на статью https://habr.com/ru/articles/1036550/?utm_source=Telegram&utm_medium=social&utm_campaign=30085453 про то же самое — Anthropic и OpenAI тратят на каждого подписчика больше электричества и железа, чем получают за $20, $100 и $200. В статье сильно сгущены краски, но суть передана верно.
Логика простая: сейчас задача AI-компаний плотно подсадить мир на LLM. Получится — поднимут цены. Модели при этом продолжают умнеть, в том числе на наших же данных. То есть мы своими руками повышаем их ценность, а платить за это будем потом. Понятно, что использовать API выгодно, если у тебя всего 10 запросов в месяц, но если ты с этим работаешь каждый день — становится резко невыгодно.
И тут возник вопрос: а сколько бы я платил, если бы подписки завтра убрали и оставили только API? При использовании API платишь по тарифам сколько потратил, за столько и заплати.
Считать самому ничего не пришлось. Есть проект ccusage: читает локальные логи Claude Code и Codex, умножает токены на актуальные тарифы API. На выходе сумма, которую я бы реально отдал, если бы использовал API.
Мой контекст
Подписка Max за $200. Claude Code установлен на рабочем ПК, домашнем ПК и MacBook. До лимитов (5 часов и 7 дней) ни разу не доходил — пару раз подбирался близко, но не выбирал. Основной сценарий — плагин Claude Code в VS Code, реже Claude Desktop.
Если бы платил за API
Рабочий ПК
Период: с 17.02.26 по 19.05.26
Активных дней: 32
Токенов: 3 006 700 000
По API: $2 099.25 (~$677 в месяц)
Домашний ПК
Период: с 28.01.26 по 18.05.26
Активных дней: 40
Токенов: 1 617 766 040
По API: $1 074.97 (~$291 в месяц)
MacBook
Период: с 15.01.26 по 08.05.26
Активных дней: 30
Токенов: 282 771 946
По API: $134.99 (~$36 в месяц)
Статистика
Суммарно ~$1000 в месяц по API против $200 за подписку. Anthropic дотирует моё использование примерно на $800 каждый месяц. На сколько они в минусе по железу и электричеству, я даже считать не пытался — это уже их экономика.
Что это значит
Цифры подтверждают то, с чего начали: текущие подписки это бонус. И он рано или поздно закончится. Вопрос только когда и до какого уровня поднимут цены.
Прикидка по моему профилю:
$500 за подписку — всё ещё выгоднее, чем API
$1000 — паритет, начну считать и думать, как оптимизировать
$1500 — либо переход на API, либо резать использование. Возможно, подключу несколько моделей, в том числе из более дешёвых
До этих сумм цены не подскочат завтра, но тренд понятен. Cursor уже на usage-based. GitHub с 1 июня переводит Copilot на гибрид: подписки по тем же ценам, но внутри метерятся токены по API-ставкам через AI Credits. OpenAI убрал безлимитный Pro. Anthropic добавила недельные лимиты там, где их раньше не было. Все идёт в одну сторону.
Мой вывод: пока есть такой бонус, его надо использовать. Жадность тут ни при чём, чистый расчёт. Закладывать в бизнес-процессы зависимость от $200 подписки рискованно. То, что сегодня стоит дёшево, через год может стоить как зарплата джуна. И когда это случится — надо иметь какие-то варианты. Ну и быть готовым к тому, что эта халява не вечная. https://habr.com/ru/articles/1036550/
Недавно у братьев Либерман в подкасте проскочила мысль: цены на LLM будут расти, потому что себестоимость уже выше подписок. Параллельно наткнулся на статью https://habr.com/ru/articles/1036550/?utm_source=Telegram&utm_medium=social&utm_campaign=30085453 про то же самое — Anthropic и OpenAI тратят на каждого подписчика больше электричества и железа, чем получают за $20, $100 и $200. В статье сильно сгущены краски, но суть передана верно.
Логика простая: сейчас задача AI-компаний плотно подсадить мир на LLM. Получится — поднимут цены. Модели при этом продолжают умнеть, в том числе на наших же данных. То есть мы своими руками повышаем их ценность, а платить за это будем потом. Понятно, что использовать API выгодно, если у тебя всего 10 запросов в месяц, но если ты с этим работаешь каждый день — становится резко невыгодно.
И тут возник вопрос: а сколько бы я платил, если бы подписки завтра убрали и оставили только API? При использовании API платишь по тарифам сколько потратил, за столько и заплати.
Считать самому ничего не пришлось. Есть проект ccusage: читает локальные логи Claude Code и Codex, умножает токены на актуальные тарифы API. На выходе сумма, которую я бы реально отдал, если бы использовал API.
Мой контекст
Подписка Max за $200. Claude Code установлен на рабочем ПК, домашнем ПК и MacBook. До лимитов (5 часов и 7 дней) ни разу не доходил — пару раз подбирался близко, но не выбирал. Основной сценарий — плагин Claude Code в VS Code, реже Claude Desktop.
Если бы платил за API
Рабочий ПК
Период: с 17.02.26 по 19.05.26
Активных дней: 32
Токенов: 3 006 700 000
По API: $2 099.25 (~$677 в месяц)
Домашний ПК
Период: с 28.01.26 по 18.05.26
Активных дней: 40
Токенов: 1 617 766 040
По API: $1 074.97 (~$291 в месяц)
MacBook
Период: с 15.01.26 по 08.05.26
Активных дней: 30
Токенов: 282 771 946
По API: $134.99 (~$36 в месяц)
Статистика
Суммарно ~$1000 в месяц по API против $200 за подписку. Anthropic дотирует моё использование примерно на $800 каждый месяц. На сколько они в минусе по железу и электричеству, я даже считать не пытался — это уже их экономика.
Что это значит
Цифры подтверждают то, с чего начали: текущие подписки это бонус. И он рано или поздно закончится. Вопрос только когда и до какого уровня поднимут цены.
Прикидка по моему профилю:
$500 за подписку — всё ещё выгоднее, чем API
$1000 — паритет, начну считать и думать, как оптимизировать
$1500 — либо переход на API, либо резать использование. Возможно, подключу несколько моделей, в том числе из более дешёвых
До этих сумм цены не подскочат завтра, но тренд понятен. Cursor уже на usage-based. GitHub с 1 июня переводит Copilot на гибрид: подписки по тем же ценам, но внутри метерятся токены по API-ставкам через AI Credits. OpenAI убрал безлимитный Pro. Anthropic добавила недельные лимиты там, где их раньше не было. Все идёт в одну сторону.
Мой вывод: пока есть такой бонус, его надо использовать. Жадность тут ни при чём, чистый расчёт. Закладывать в бизнес-процессы зависимость от $200 подписки рискованно. То, что сегодня стоит дёшево, через год может стоить как зарплата джуна. И когда это случится — надо иметь какие-то варианты. Ну и быть готовым к тому, что эта халява не вечная. https://habr.com/ru/articles/1036550/
Айти «очищается»?
На Хабре развернулась дискуссия, которая зацепила многих. Всё началось с поста, где человек рассказал, как ушёл из IT в гидроизоляцию крыш — и стал счастливым. Дальше ему ответили, ответили отвечавшему, и получилась целая трилогия о том, что вообще происходит с профессией.
1. Как я в 2026 году ВЫШЕЛ из айти? Личная история программиста, который четыре года работал в IT, но профессию никогда не любил, каждая задача и созвон были мучением, держался ради денег. В итоге скормили Claude, тот посоветовал ускорить согласование требований, команду распустили. Поиски новой работы провалились. Он ушёл в физический труд и стал кровельщиком. И счастлив! Появилась физическая активность, выходные, доход в час вырос. Основная мысль: «Лучше времени выйти из айти не будет». Если работа в тягость, AI-волна это хороший повод уйти.
2. IT очищается от случайных людей. И это хорошо Ответ на первую статью. Автор рад за «ушедшего», но ещё больше за отрасль и за себя: в 2018–2023 был аномальный период, когда люди шли не в профессию, а за зарплатой. Сравнивает с гипотетическим наплывом нелюбящих свою работу учителей. Приводит свой зеркальный опыт: был случайным тренером по кроссфиту, ненавидел работу, потом ушёл в разработку с просадкой зарплаты вдвое и тоже стал счастлив. Вывод: лёгких денег больше нет, а ИИ обесценил примитивную работу (клепание формочек и однотипных сайтов), тогда как сильным сеньорам он, наоборот, снимает рутину. «Случайные» люди уходят и это оздоровление.
3. Про «случайных» людей в ИТ Ответ на вторую статью и контртезис. Автор проводит параллель с кризисом 2008-го, когда его начальник так же радовался, что «недоучек смоет» и плохо закончил вместе с банком. Главная мысль: экспертность — это всегда внешняя оценка, возможная только внутри своей отрасли; нет отрасли, не будет и экспертов. Радоваться «очищению» опасно, потому что на одного реального специалиста приходится несколько тысяч заинтересованных «зрителей», и именно массовый интерес обывателей, «вкатунов» и джунов держит ценность профессии на плаву. Если интерес исчезнет, ценность экспертизы обнулится, и сеньоры пойдут в дворники, как физики-ядерщики в 90-е. Хорошая аналогия с футболом: профессионалы рождаются только из массового любительства, поэтому нужно популяризировать IT, а не злорадствовать над чужими увольнениями.
И вот что самое интересное: каждый, кто написал статью, по-своему прав. У меня самого нет однозначного ответа нужно ли уходить из IT или нет тем, кто хочет / сомневается или уволен и не может найти работу.
Если человек не любит IT, не хочет развиваться, ненавидит задачи и держится только за деньги, возможно, уход действительно будет правильным решением. Не потому что рынок очистился, а потому что жизнь слишком короткая, чтобы годами мучиться в профессии, которая не твоя.
Если человек только хочет войти в IT, я бы не отговаривал. Но и не говорил бы про то, что здесь мёд. Входить можно. Но надо понимать: лёгкого входа уже почти нет. Конкуренция высокая. Простые задачи автоматизируются. Работодатели стали осторожнее. Одного желания перейти на удалёнку и получать больше недостаточно.
IT стало жёстче к тем, кто зашёл сюда случайно. С этим не поспорить. Но радоваться чужим увольнениям позиция так себе. Сегодня «смыло» соседа по опенспейсу, завтра половину твоих задач отдадут модели за двадцать баксов в месяц, и вопрос «а ты-то здесь зачем» прилетит уже тебе.
По мне, вся эта дискуссия про одно: зачем ты в профессии. Пришёл за зарплатой? Рынок будет тебя выдавливать и лёгких денег тут больше нет. Пришёл за профессией и тебе действительно нравится в IT? Тебя, наоборот, будет не хватать.
Скажу как работодатель. Действительно сильных специалистов на рынке мало, и за таких людей надо держаться: они понимают бизнес заказчика, а не просто пишут код по ТЗ. А вот отдельный исполнитель на задачи уровня «сделай форму» уже вряд ли кому-то будет нужен. Эту работу быстрее и дешевле делает Cursor.
Так что уходить или оставаться — это вопрос не к рынку и не к ИИ. Это вопрос больше к себе.
А вы бы сейчас ушли из айти? И если да, то куда?
На Хабре развернулась дискуссия, которая зацепила многих. Всё началось с поста, где человек рассказал, как ушёл из IT в гидроизоляцию крыш — и стал счастливым. Дальше ему ответили, ответили отвечавшему, и получилась целая трилогия о том, что вообще происходит с профессией.
1. Как я в 2026 году ВЫШЕЛ из айти? Личная история программиста, который четыре года работал в IT, но профессию никогда не любил, каждая задача и созвон были мучением, держался ради денег. В итоге скормили Claude, тот посоветовал ускорить согласование требований, команду распустили. Поиски новой работы провалились. Он ушёл в физический труд и стал кровельщиком. И счастлив! Появилась физическая активность, выходные, доход в час вырос. Основная мысль: «Лучше времени выйти из айти не будет». Если работа в тягость, AI-волна это хороший повод уйти.
2. IT очищается от случайных людей. И это хорошо Ответ на первую статью. Автор рад за «ушедшего», но ещё больше за отрасль и за себя: в 2018–2023 был аномальный период, когда люди шли не в профессию, а за зарплатой. Сравнивает с гипотетическим наплывом нелюбящих свою работу учителей. Приводит свой зеркальный опыт: был случайным тренером по кроссфиту, ненавидел работу, потом ушёл в разработку с просадкой зарплаты вдвое и тоже стал счастлив. Вывод: лёгких денег больше нет, а ИИ обесценил примитивную работу (клепание формочек и однотипных сайтов), тогда как сильным сеньорам он, наоборот, снимает рутину. «Случайные» люди уходят и это оздоровление.
3. Про «случайных» людей в ИТ Ответ на вторую статью и контртезис. Автор проводит параллель с кризисом 2008-го, когда его начальник так же радовался, что «недоучек смоет» и плохо закончил вместе с банком. Главная мысль: экспертность — это всегда внешняя оценка, возможная только внутри своей отрасли; нет отрасли, не будет и экспертов. Радоваться «очищению» опасно, потому что на одного реального специалиста приходится несколько тысяч заинтересованных «зрителей», и именно массовый интерес обывателей, «вкатунов» и джунов держит ценность профессии на плаву. Если интерес исчезнет, ценность экспертизы обнулится, и сеньоры пойдут в дворники, как физики-ядерщики в 90-е. Хорошая аналогия с футболом: профессионалы рождаются только из массового любительства, поэтому нужно популяризировать IT, а не злорадствовать над чужими увольнениями.
И вот что самое интересное: каждый, кто написал статью, по-своему прав. У меня самого нет однозначного ответа нужно ли уходить из IT или нет тем, кто хочет / сомневается или уволен и не может найти работу.
Если человек не любит IT, не хочет развиваться, ненавидит задачи и держится только за деньги, возможно, уход действительно будет правильным решением. Не потому что рынок очистился, а потому что жизнь слишком короткая, чтобы годами мучиться в профессии, которая не твоя.
Если человек только хочет войти в IT, я бы не отговаривал. Но и не говорил бы про то, что здесь мёд. Входить можно. Но надо понимать: лёгкого входа уже почти нет. Конкуренция высокая. Простые задачи автоматизируются. Работодатели стали осторожнее. Одного желания перейти на удалёнку и получать больше недостаточно.
IT стало жёстче к тем, кто зашёл сюда случайно. С этим не поспорить. Но радоваться чужим увольнениям позиция так себе. Сегодня «смыло» соседа по опенспейсу, завтра половину твоих задач отдадут модели за двадцать баксов в месяц, и вопрос «а ты-то здесь зачем» прилетит уже тебе.
По мне, вся эта дискуссия про одно: зачем ты в профессии. Пришёл за зарплатой? Рынок будет тебя выдавливать и лёгких денег тут больше нет. Пришёл за профессией и тебе действительно нравится в IT? Тебя, наоборот, будет не хватать.
Скажу как работодатель. Действительно сильных специалистов на рынке мало, и за таких людей надо держаться: они понимают бизнес заказчика, а не просто пишут код по ТЗ. А вот отдельный исполнитель на задачи уровня «сделай форму» уже вряд ли кому-то будет нужен. Эту работу быстрее и дешевле делает Cursor.
Так что уходить или оставаться — это вопрос не к рынку и не к ИИ. Это вопрос больше к себе.
А вы бы сейчас ушли из айти? И если да, то куда?
👍3🔥1