Все потоки

Привет! В GPTunneL мы строим инфраструктуру, которая помогает бизнесу безопасно и эффективно использовать генеративные модели в продуктах.

Наша цель — сделать работу с LLM предсказуемой, контролируемой и масштабируемой: от качества ответа до стоимости и соответствия требованиям.

Сейчас мы усиливаем инженерную команду и ищем Python AI/ML Engineer, который поможет нам развивать ML‑ядро и пайплайны, улучшать качество моделей и внедрять решения в продакшн. Если вам интересно работать на стыке NLP, инженерии и продукта — будем рады познакомиться.

Чем предстоит заниматься:

• Проектировать и разрабатывать пайплайны для работы с Large Language Models (LLM) — от прототипа до продакшена

• Создавать AI-агентов — проектировать мультиагентные систем, оркестрацию, tool-use, планирование и memory

• Разрабатывать и оптимизировать RAG / GraphRAG систем — строить retrieval-пайплайны, работать с векторными БД, графами знаний, chunking-стратегиями, re-ranking

• Экспериментировать и исследовать — подбирать модели, prompt engineering, fine-tuning, оценивать качествао(evaluation pipelines)

• Интегрировать модели в продуктовые сервисы через API, очереди, стриминг

• Работать с данными — готовить датасеты, строить ETL-пайплайны для обучения и инференса

Что мы ожидаем:

Must have

• Python — уверенное владение (3+ лет коммерческого опыта)

• Глубокое понимание архитектуры Transformers (attention, tokenization, encoder/decoder, positional encoding и т.д.)

• Практический опыт работы с LLM (OpenAI API, Anthropic, open-source модели — LLaMA, Mistral, Qwen и др.)

• Опыт построения RAG-систем (векторные БД: Qdrant / Pinecone / Weaviate / Milvus, embedding-модели, retrieval-стратегии)

• Понимание принципов GraphRAG — работа с графами знаний, entity extraction, graph-based retrieval

• Опыт создания AI-агентов (LangChain / LangGraph / CrewAI / AutoGen или аналоги)

• Знание фреймворков: HuggingFace Transformers, PyTorch

• Опыт работы с LangChain / LlamaIndex или аналогичными фреймворками

• Понимание принципов prompt engineering, chain-of-thought, few-shot, function calling

• Умение работать с Git, базовое понимание CI/CD

• Английский — чтение документации и статей свободно

Nice to have

• Опыт работы с Diffusion-моделями (Stable Diffusion, SDXL, Flux, Midjourney API) — генерация изображений, fine-tuning (LoRA, DreamBooth, Textual Inversion), ComfyUI / A1111

• Опыт fine-tuning LLM (LoRA, QLoRA, PEFT, RLHF/DPO)

• Знание vLLM / TGI / Ollama для оптимизации инференса

• Опыт работы с multimodal-моделями (GPT-4V, LLaVA и др.)

• Знакомство с MLOps практиками (MLflow, Weights & Biases, эксперимент-трекинг)

• Опыт работы с облачными GPU (RunPod, Vast.ai, AWS, GCP)

• Понимание FastAPI / asyncio для построения высоконагруженных сервисов

• Опыт работы с Neo4j / NetworkX для графовых структур

• Публикации, open-source контрибьюции или pet-проекты в области AI/ML

Технологический стек

Python PyTorch HuggingFace LangChain LlamaIndex LangGraph FastAPI Docker PostgreSQL Redis Qdrant Neo4j vLLM Git

Условия

• 📍 Удалённая работа (full remote)

• 💰 Конкурентная заработная плата (обсуждается по результатам собеседования)

• 🕐 Гибкий график

• 🧠 Работа с cutting-edge технологиями — никакого легаси, только передний край AI

• 🚀 Влияние на продукт — ваши решения идут в прод, а не в стол

• 📈 Возможности для профессионального роста и участия в R&D

• 🤝 Команда, которая горит AI и делает крутые вещи

Как откликнуться:

Отправьте ваше резюме/CV и ссылку на GitHub (если есть) в тг нашему HRBP @hr_welcome .

Будет плюсом: краткое описание самого интересного AI-проекта, над которым вы работали.

GPTunneL — мы делаем AI, который работает. ⚡️

Вот интересен предел нашей деградации из за ИИ, ведь 10 лет назад я половину рф и всю европу насквозь без навигатора проезжал- сейчас даже до магазина без навигатора не ездят…

А с ии через 10 лет мы будем спрашивать как дышать, видимо.

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

Наркота какаята вкусная и вредная. Это мой последний выдох разума родил)

IPS и IDS: как устроены системы защиты от атак в сети

IDS и IPS — это системы защиты от сетевых атак и вредоносной активности. IDS анализирует копию сетевого трафика и отправляет оповещения при обнаружении угроз. IPS обрабатывает весь проходящий через него трафик и может блокировать атаки в реальном времени — отбрасывать пакеты или разрывать соединения.

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

Подробнее об  IDS и IPS, их принципах работы и алгоритме выбора системы читайте на сайте Рег.облака.

Когда задача считается выполненной

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

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

Мы поговорили с коллегами и попросили их рассказать, в какой момент для них задача считается завершенной. Их ответы читайте ниже.

Настя, тестировщик:

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

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

Ваня, системный аналитик:

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

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

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

И наконец, пункты задачи должны быть приоритизированы, а сроки выполнения — обозначены, чтобы работа двигалась предсказуемо и без постоянных возвратов к деталям.

Олег, android-разработчик:

Задача выполнена, когда:

1. Функциональность реализована и проверена вручную — примерно так, как это сделал бы тестировщик, но без учета конкретных тест-кейсов.

2. Новое поведение решает цель задачи, а не просто повторяет постановку. Иногда по ходу работы находится вариант проще для разработки/поддержки или удобнее для пользователя — выбираю его. Фича должна закрывать потребность.

3. Пограничные случаи поведения (corner cases) проработаны и учтены. В постановке не всегда учитываются моменты, которые становятся заметны в коде. Например, что показать на мобильном клиенте при 500 ответе сервера или при долгой загрузке из-за задержки ответа сервера.

4. Новое поведение покрыто тестами, есть уверенность, что его не сломают случайно. Также важно, чтобы оно не сломало существующие автотесты.

5. Новое поведение поддерживаемо и расширяемо: его сможет понять и продолжить другой разработчик.

Применяем кодогенерацию в Java для решения алгоритмических задач

В прошлый раз мы разобрались, как решается задача трансляции деревьев. И остановились на том, что в случае с AST от компилятора TypeScript, придётся руками обрабатывать 263 типов узлов. Тысячи строк однотипного boilerplate-кода: приведения типов, аннотации, объявления методов — всё это нужно не просто написать, но ещё и поддерживать. А если требования к архитектуре поменяются — переписывать заново.

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

Как реализовать это с помощью JavaPoet, что умеет эта библиотека, а также как встроить в процесс нормализацию можно узнать в новом материале, посвящённом использованию кодогенерации для трансляции деревьев.

Где хранить код и как настроить CI/CD, если GitLab CE уже не хватает

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

У нас есть готовое решение для такого случая. На вебинаре 27 февраля мы расскажем о Deckhouse Code — единой платформе для непрерывной разработки и управления жизненным циклом ПО:

• Покажем, как настроить правила слияния, CODEOWNERS, push rules и безопасно хранить секреты вне платформы.

• Обсудим, как сократить нагрузку на команды за счёт managed-подхода.

• Проведём живое демо от коммита в консоли до артефакта в registry.

Регистрируйтесь и подключайтесь, если вы отвечаете за CI/CD в корпоративной среде. Автор лучшего вопроса в чате вебинара получит персональное демо под свою задачу.

«Сокращать нельзя оставить»: где правильно поставить запятую и как сделать этот непростой процесс экологичным?

26 февраля в 11.00 (МСК) поговорим о том, о чём обычно молчат в корпоративных коммуникациях. Увольнения и сокращения стали новой реальностью: четверть российских компаний проходили через них за последние 2 года. И каждый второй случай, по данным исследований, – потеря 11-20% команды. Для многих это, увы, не разовая история, а повторяющийся сценарий.

Но цифры – это одно, а другое – тревога в глазах тех, кто остается, чувство вины у руководителей, обида уходящих и выгорание HR, который вынужден брать на себя ответственность.

На вебинаре с экспертами K-Team (ГК «КОРУС Консалтинг») и Alter разберём, как проводить сокращения без разрушительных последствий:

🟢 Почему даже точечные увольнения превращаются в токсичный хаос и как этим управлять
🟢 Что говорить уходящим, чтобы снижать напряжение
🟢 Как работать с «выжившими» – когда команда нуждается в поддержке не меньше, чем те, кто ушёл
🟢Где брать ресурс HR и руководителям, когда сложных разговоров не избежать

Приходите – будем говорить прямо и поделимся инструментами, которые по-настоящему помогают и поддерживают всех участников процесса.

➡️ Регистрация по ссылке!

Экс‑разработчик Ubisoft представил открытый видеоредактор FreeCut, который работает в браузере и позволяет собирать сложные видео, улучшает их качество, накладывает эффекты и субтитры.

Проект умеет:

• сокращать, урезать, соединять видосы, добавлять картинки, другие ролики, формы, текст;

• добавлять анимацию, создать любую композицию и реализовать всевозможные идеи;

• CSS‑эффекты, ключевые кадры, переходы, фильтры, коррекция цвета, перемещение камеры, 3D;

• экспортировать во всех самых популярных форматах: MP4, MOV, WebM, MKV;

• аудио принимает в форматах: MP3, AAC, WAV;

• поддержку кодеков: H.264, H.265, VP8, VP9, ProRes;

• сжимает видео без потери качества.

Китайский робот STAR1 научили лепить пельмени — робот выполняет все действия на кухне по этой задаче.

Вышел Gemini 3.1 Pro от Google (доступно в Google AI Studio). Этот ИИ показал 77,1% в сложнейшем тесте на абстрактное мышление ARC‑AGI-2. Результат в два раза превосходит показатели прошлой версии и оставляет позади даже Opus 4.6 с GPT-5.2. Также разработчики из Google прокачали базовые способности ИИ: теперь модель умеет генерировать анимированные SVG по текстовому описанию и решать логические задачи с новыми паттернами, которых не было в обучении.

Привет. У меня вопрос к разработчикам LLM. Периодически читаю про жалобы на галлюцинации LLM и невозможность адекватной оценки вероятности её ответов (типа, уверенно врёт). При этом, я раньше занимался разработкой системы распознавания рукописного текста, и у нас была в чём-то схожая проблема (трудно было оценить достоверность результатов распознавания). Решалась она довольно неплохо путём прогона цепочки распознавания достаточно большого числа раз на одном и том же изображении, и последующей перенормировкой вероятностей в итоговом списке ответов (ответы, по существу генерировались методом монте-карло путём последовательного продвижения по графу возможных вариантов в байесовской цепи). Как понимаю, в LLM принцип генерации ответа в чём-то похожий (последовательный вероятностный перебор цепочки токенов с генерацией их в реальном масштабе времени). Соответственно, вопрос - а если повысить в разумных пределах температуру и Top P, прогонять цепочку несколько раз, а потом пересчитывать итоговую вероятность правильности ответа путём перенормировки списка, это не может ли помочь хотя бы частично решить проблему?

PS

Заранее извиняюсь, если что-то не догоняю, я в LLM не Копенгаген, но идея, думаю, понятна.

В сезоне INFOSTART AWARDS 2025 мы обновили механику выбора победителей - добавили этап экспертного голосования. Цель простая: объединить оценку сообщества Инфостарта с независимым взглядом со стороны рынка, чтобы отмечать не только популярные материалы, но и решения, которые реально работают в бизнесе.

Процесс идёт в два этапа.

Сначала команда Инфостарта формирует шорт-лист номинантов. Мы оцениваем активность авторов за год, практическую пользу материалов и решений, отклик сообщества, применимость в проектах, глубину проработки и вклад в развитие профессиональной среды.

Затем в дело вступает экспертное жюри INFOSTART AWARDS 2025 - ИТ-директора, технические руководители и лидеры цифровых трансформаций из крупных компаний разных отраслей. Они голосуют за номинантов из шорт-листа, и победителями становятся авторы и решения с наибольшей поддержкой экспертов.

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

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

Полный список экспертов жюри и представление каждого — в статье на сайте.

Церемония награждения пройдёт офлайн на INFOSTART TEAM EVENT 2026 в Москве.

От чего зависит надёжность работы облачной 1С? Инфраструктура очень важна, но ещё один ключевой фактор — качество инженерного сопровождения

26 февраля вместе с нашим партнёром ASTON обсудим практический опыт техподдержки систем 1С в облаке. 

На вебинаре эксперты

• проанализируют события прошлого года на рынке 1С и тренды 2026

• расскажут об условиях, моделях и подходах к кастомизации техподдержки 1С в облаке

• сравнят сценарии поддержки на основе своих повседневных кейсов 

• дадут рекомендации по бесшовной передаче систем 1С на техподдержку и организации процесса т/п: все участники получат полезные чек-листы

• поделятся лайфхаками и выводами из реализованных проектов

Спикеры

Анжелика Захарова, руководитель практик 1С и кибербезопасности K2 Cloud

Яков Кротов, директор направления ИИ и сервисных проектов ASTON

📍 26 февраля, четверг, 11:00 мск

Вебинар будет интересен CIO, CTO, руководителям ИТ-инфраструктуры, специалистам по финансовым и бухгалтерским операциям, специалистам по 1С.

Зарегистрироваться

Налоговая отчётность в 1С: почему не стоит менять?

Привет, Хабр!

Стали мне часто попадаться доработки налоговой отчётности.

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

1. Отчётность - это часть конфигурации, которая обновляется чаще всего. Каждое ваше исправление - это потеря денег при каждом обновлении (адаптация).

2. Типовые алгоритмы в 1С отлажены на тысячах баз, учтены десятки нюансов и разъяснений Минфина. Вероятность, что именно ваш случай не учтён, есть, но она очень мала.

3. Ваша «точечная» правка может незаметно сломать смежные расчёты в других разделах или за другие периоды.

Что же делать?

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

2. Внимательно изучите типовое решение. Скорее всего, там есть настройки или правила игры, учитывающие ваш случай. Например, меня неоднократно просили добавить справочник «Филиалы» для заполнения декларации по прибыли. Решение: во всех типовых конфигурациях для учёта филиалов используется справочник «Организации».

3. Если правок в декларацию немного, и их можно без существенных трудозатрат сделать руками – следует оставить типовой вариант.

4. .Если есть такая возможность - внесите правки после заполнения декларации отдельным апгоритмом.

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

ВАЖНО: типовые возможности должны быть сохранены и для пользователя.

Например, если добавляем кнопку заполнения книги покупок, должна быть добавлена кнопка «Заполнить книгу (ООО «Ромашка»)», а типовая кнопка должна остаться в первозданном и рабочем состоянии.

Это позволит:

• быстро вернуться к типовому варианту

• проверить работоспособность типового варианта

• сравнить доработанный вариант с типовым

• и ещё это спасительная возможность заполнить декларацию, если доработанный вариант перестал работать после обновления.

Всем удачи и лёгких обновлений!

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

И все бы ничего, но иногда в галерею попадают изображения инсайдерского характера, разглашение которых может быть очень "больно" и "дорого". Поэтому требования к телефону, его настройке и разрешениям носят критический характер.
Представьте ситуацию, что сотрудник банка фотографирует вас с паспортом в качестве подтверждения личности для последующей выдачи карты. А вместе с тем, на телефоне установлена автозагрузка фотографий в облачный Google Images, с привязкой к геолокации и автоматическим размещением на Google Maps.

Скажете бред? А я отвечу, что я лично был в ситуации, когда наша команда готовились к Red Teaming'у одного градообразующего мобильного оператора и мы изучали местность по вышеуказанным картам. На наше везение, на здании ЦОДа, в которое нам необходимо было проникнуть, были фотографии серверной, разводки СКС, логины и пароли и еще много чего интересного.
В ходе разбирательства сотрудник пояснил, что злого умысла выгружать внутренние фото у него не было. Просто он озаботился бэкапами своей семейной галереи... в которую попали рабочие фотографии.

Сейчас, да что уж греха таить - уже как пару лет ваш телефон уже не ваш телефон (как и в Windows "Мой компьютер" плавно переименован в "Этот компьютер"). Все, что храните на телефоне, сразу становится достоянием общественности: разрешение на просмотр фото всеми приложениями, доступ к геолокации, камере и микрофону в фоновом режиме, доступ к контактам и самая прикольная тема, когда приложение запрашивает доступ на просмотр активности другого приложения...😂
Да и если почитать лицензионное соглашение, то и само устройство вам не принадлежит: ПО за компанией-разработчиком, а его реверс-инжиниринг и модификация запрещены уголовным законом. Что же касается железа, то эти кирпичи настроены на работу только со штатным кастомным ПО и драйверами, а всевозможные дебаг порты и флэш карты заблокированы.

В чем смысл моего повествования? Удобство использования всегда идет в разрез безопасности. Короткий и легкий пароль - удобно, но не безопасно; длинный и тяжелый - не удобно, но вряд ли вас взломают. Использовать все фичи телефона, включая камеру - удобно, но может все-таки рабочие и очень личные вещи оставить на "откуп" хотя бы оффлайн мыльницам?

В общем, есть над чем подумать на длинных выходных! А пока делитесь скриншотами своей телефонной галереи - давайте вместе оценим вашу работу)

🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте | ⚡️Бустануть канал

Service Desk для национальных платформ: клиентский сервис под миллионы пользователей и строгий SLA

26 февраля в 11:00 ITFB Group и ELMA проведут бесплатный вебинар, посвящённый трансформации сервисной модели в системах федерального масштаба. В центре обсуждения — практический кейс модернизации клиентского сервиса Национальной системы цифровой маркировки Честный знак.

Речь пойдёт не о теории и не о «коробочном» внедрении, а о реальном переходе с legacy CRM на отечественную платформу ELMA365 Service Desk в условиях высокой нагрузки, строгих SLA и миллионов пользователей по всей стране. Эксперты, которые непосредственно участвовали в проекте, подробно разберут архитектурные решения, подход к миграции и организационные изменения, без которых подобная трансформация невозможна.

Зарегистрироваться

В программе вебинара:

• Миграция без потерь. Как спланировать и реализовать перенос данных, процессов и историй обращений, не нарушив SLA и не остановив сервис. Какие риски возникали и как их удалось минимизировать.

• Архитектура надёжности. Какие технические решения обеспечили отказоустойчивость и производительность платформы под колоссальной нагрузкой. Как выстраивалась инфраструктура и какие требования предъявлялись к масштабируемости.

• Омниканальность в масштабах страны. Как объединить десятки каналов обращений в единую прозрачную модель обработки с контролем SLA и OLA. Что меняется в операционной модели при таком объёме обращений.

• Искусственный интеллект на практике. Почему AI-ready — это не просто наличие модели, а результат зрелых процессов. Как ИИ уже сегодня используется для повышения эффективности операторов и улучшения качества обслуживания.

• Масштабирование опыта. Какие управленческие и технологические выводы из этого проекта применимы для других крупных государственных и коммерческих систем.

Спикеры вебинара:

— Илья Грознов, руководитель клиентского сервиса «Честного знака»
— Дмитрий Мордвинцев, руководитель направления «Системная интеграция» ITFB Group
— Иван Софронов, Product Lead ELMA365 Service Desk

Если вы отвечаете за Service Desk, клиентский сервис, CRM, ITSM или архитектуру платформ с высокой нагрузкой, этот кейс будет полезен как с точки зрения технологий, так и с точки зрения управления изменениями.

Зарегистрироваться

Участие бесплатное. Зарегистрируйтесь, чтобы получить ссылку на трансляцию — она будет направлена на указанный e-mail.

Перед тем как купить Mac mini под ClowdBot, попробуй OpenClaw в Cherry Studio AI

Мне очень нравится клиент Cherry Studio AI, и я создал канал в котором пишу о нем, на Хабре пишу реже. Сегодня хочу поделиться как я случайно протестировал ClowdBot и оказался удивлен.

Сейчас многие скупают Mac mini и ставят на него хайповый «ClowdBot», чтобы поднять себе личного AI‑помощника 24/7. Идея классная, но есть нюанс: не хочется тратить деньги и вечера на настройку, пока не понял — вообще твоё это или нет. Для такого тест‑драйва теперь есть отличный вариант: OpenClaw появился в Cherry Studio AI.

Коротко, чем он крут. OpenClaw — это не «ещё один чат» и не привязка к одной модели. Это orchestration layer (оркестратор), который умеет работать с разными LLM (Claude / GPT / Gemini / DeepSeek и т.д.), подключать модульные skills (браузер, файлы, интеграции, свои API) и вести память в обычных Markdown‑файлах, которые можно открыть и править руками. То есть ты тестируешь не просто модель, а подход «агент + инструменты + память» — как это будет ощущаться в реальной жизни.

И вот где Cherry хорош: ты можешь спокойно пощупать OpenClaw прямо внутри Cherry Studio AI, без покупки отдельного железа и без возни с «подниманием сервиса». Плюс Cherry в такой связке даёт дешёвый доступ к моделям через HydraAI (или любого другого провайдера, который подключён в Cherry) — получается максимально бюджетный вход: попробовал, понял, надо ли тебе это, и только потом решаешь, покупать ли Mac mini под 24/7‑режим. Ссылки на всё нужное — в моём канале, чтобы не превращать этот пост в простую рекламу.

Конфигураций и вариантов внутри много: разные провайдеры, разные модели, настройки skills, памяти, интеграций — я сам только начал разбираться и копать глубже. Мне уже хочется купить себе Mac mini (а может и не один), чтобы собрать полноценный домашний AI‑хаб под OpenClaw, хотя не исключаю, что чуть позже остыну и подойду к этому рациональнее.

При первом запуске через Cherry (v1.7.19) под Windows сейчас есть небольшой баг с путём, из‑за которого установщик может ругнуться. Решается запуском установки из папки Cherry через PowerShell:

# для первого запуска OpenClaw в Cherry Studio AI, если у вас установлен Node.js
# запустите инсталляцию из папки, где находится CherryStudioAI

cd "C:\Путь_к_Cherry\CherryStudioAI"
& "C:\Program Files\nodejs\npm.cmd" install -g openclaw@latest

Я, честно, впечатлён. До этого пробовал связку Roo Code + сервер qDrant — не зашла: много возни, расходы неприятно удивили, а отдача не впечатлила. Похожую задачу OpenClaw решил сходу и стоил при этом копейки. Я пишу про Cherry у себя на канале, там-же больше ссылок.

Поделись с друзьями ссылкой на этот пост, пусть уже сегодня попробуют будущее =)

Выбор вакансии: как я кинулась во всё — и это не дало результата.

Есть разработчики, у которых развитие идёт линейно и предсказуемо: верстальшик → джун фронтендер → мидл → мидл в сильной компании → сеньор/лид/уход в бэкенд

Красиво. Понятно. Логично.

Но у меня кривая черта развития сначала бэк на Java в закрытом предприятии. Потом фулстек в фудтехе: в основном Vue, но ещё и Go (и все сопутствующее), и CUBA Platform (lowcode на java, он же «Тезис»), и n8n.

Широко. Разнообразно. Интересно.

Как я начала откликаться - на всё, что блестит

И сейчас Когда я вышла на рынок, то сначала я откликалась на все что близко:

1. Frontend - Vue / React / Angular
   Ну фронт же. Есть мнение, что «не нужно учить конкретный фреймворк — важны принципы».

2. Go
   а почему бы нет? Знаю , умею , курсы закончены, писала на нем

3. Fullstack (Go или JDK + фронт)

4. N8N, автоматизаторы особенно с ИИ
   Интересно. Растущее направление.

5. Lowcode платформы CUBA, тезис, WebTutor - замаскированный под фронтенд Опыт есть. Почему не использовать?

И это фатал еrror

1. Ошибка №1. Переключение контекста
   Очень сложно переключать контекст и даже синтаксис языка - на первом собесе по TS я не смогла вспомнить синтаксис (на ум приходил только java, так как он изучался более долго и в закрытой среде, ирония: хоть я на нем и не пишу, но разбуди среди ночи - код напишу)

2. Ошибка №2. Рынок
   Рассматривать вакансии на Angular, React без опыта в продакшене - на данный момент наивно.
   
   Рынок перегрет:
   - Vue ~ 1000 откликов за неделю,
   - React - 4000 ,
   
   Неужели Арина (или тот кто читает эту статью) ты думаешь, что кто-то будет рассматривать ваше резюме со Vue? Каким бы в целом хорошим инженером вы не были. Рынок не покупает «в целом».

3. Ошибка №3. Fullstack со связкой Go + Vue или JDK + Vue
   Фуллстеки со связкой go или jdk - это бред вакансии, это карьерный тупик.
   - PHP + Vue - норм
   - Node + Vue - норм,
   но Go + Vue - это нонсенс, это только подработка для поддержания штанов. Чаще это небольшие команды, поддержка, нестабильные проекты.

4. Ошибка №4. n8n — нравится, но это уже не совсем разработка
   Автоматизация, интеграции, AI — это интересно. Но это больше аналитика и orchestration, чем классическая инженерия. Если хочешь быть разработчиком — нужно понимать, куда ты смещаешь фокус.

5. Ошибка №5. Low-code — карьерный тупик
   Проблем с окружением больше. Кода меньше. Рынок уже. Ты становишься зависимой от конкретной платформы. И выйти обратно в «чистую разработку» становится сложнее.

Мой Hotfix: Фокус

Я поняла, что на падающем рынке выживают либо "универсалы" c ИИ подбоком, либо эксперты

Моя новая стратегия:

• Vue 3 + TypeScript + Nuxt (как зона роста)

• n8n — как подработку и интересный дополнительный навык.

Иногда рост — это не добавить ещё стек. А убрать лишнее.

Облака «потяжелели»: средний чек публичного облака вырос на 46%: данные Рег.облака

Публичное облако всё реже используют как среду для пилотов и тестов. По данным Рег.облака, в 2025 году средний чек публичных сервисов вырос на 46% — за счет притока проектов среднего и крупного бизнеса.

Количество заказчиков публичного облака увеличилось до 22 000 компаний, а общее число клиентов облачных услуг — до 27 000. При этом растет не только база, но и глубина потребления: компании переносят в облако не отдельные сервисы, а критичные для бизнеса системы.

Выручка от аренды виртуальных серверов выросла на 61%, услуги резервного копирования — на 77%. Максимальную динамику — 226% — показали платформенные и управляемые сервисы: объектное S3-хранилище, управляемые кластеры Kubernetes и другие managed-решения. Это косвенно подтверждает, что бизнесу важна не просто инфраструктура, а готовые сервисные слои с предсказуемой поддержкой и SLA.

Фактически публичное облако становится инструментом финансовой гибкости: вместо долгосрочных Capex-инвестиций в собственную инфраструктуру компании переходят к Opex-модели с масштабированием по нагрузке. Для IT это изменение архитектурного подхода, для бизнеса — способ снизить риски в условиях неопределенности.

По оценке Рег.облака, в 2026 году облачный рынок может вырасти до 35% — темп существенно выше ожидаемого роста всей IT-отрасли.

Больше данных — на сайте Рег.облака.

Стоит ли давать разработчику второй шанс? Кейс об «эффекте бумеранга»

Год назад мы расстались с разработчиком. Причины были классическими: просела скорость, пропал фокус, исчез драйв, перформанс ближе к нулю. Решение об увольнении было непростым, но на тот момент честным для обеих сторон. Процессы в моей кросс-функциональной команде требуют высокой вовлеченности, и «пассажиров» мы себе позволить не могли.

Недавно он написал снова. За этот год человек успел закончить вуз, сменить обстановку и, по его словам, переосмыслить приоритеты. Он хочет вернуться.

В такой ситуации тимлиду важно отделить эмоции от управления.

Второй шанс — это не про «пожалеть» и не про «наказать». Это холодный расчет изменившихся условий. Прежде чем принять решение, я задаю себе вопросы:

• Что изменилось в его ресурсе и фокусе?

• Появилась ли внутренняя мотивация вместо внешней?

• Готов ли он брать ответственность за результат, а не просто закрывать тикеты?

Иногда люди действительно перерастают свой прошлый этап, совершают качественный скачок. Иногда — нет, и тогда система просто воспроизведет прежний негативный результат.

Для меня критерий прост: изменились ли вводные данные настолько, чтобы математически ожидать другой исход?

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

А как вы относитесь к «бумерангам»? Стоит ли входить в одну и ту же реку дважды, или в ИТ это не работает?