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

Duolingo учит меня заказывать яблоки, ChatGPT-чат отлично объясняет грамматику - но не помнит, что я разбирал Present Perfect в среду и опять путаю его с Past Simple в пятницу.

Я хотел простую штуку:

написать модели «давай сегодня про багтрекеры»;

получить чат на 15 минут;

а в конце - три новых слова, которые она же мне и подобрала по уровню B1.

Чтобы завтра эти слова всплыли в упражнениях.

Через месяц получился Lexis:

Go · Clean Architecture · 4 LLM-модели · SSE-стриминг · JWT rotation + reuse detection

MIT, открытый репозиторий.

В статье - три инженерных якоря, которыми я доволен:

Pluggable AI-провайдеры через интерфейс из трёх методов.

SSE вместо WebSocket для стриминга AI-ответов.

JWT rotation + reuse detection как production-ready стандарт, а не «потом перепишем».

Плюс честный список того, что ещё не готово.

Анализ публично доступных HTTP-ответов и DNS-записей без аутентификации и активного вмешательства. Проверке подвергается только внешняя конфигурация: HTTP-заголовки, TLS/SSL, DNS, открытые порты.

Уязвимости не эксплуатируются, нагрузки на сервер нет.

### Cursor как общая среда для заказчика и разработчика

Google влил в Anthropic сорок миллиардов, Cursor "собрали" браузер на GPT-5.2, а я начал писать код совместно с заказчиком.

В этом посте я поделюсь экспирементом, который мы начали на проекте для бизнеса в сфере управления недвижимостью. Расскажу, как я организовал работу с заказчиком в Cursor, почему это оказалось технически интересно, где здесь бизнес логика, и почему общий workspace может стать новой средой между бизнесом, разработкой и ИИ агентами.

## А что если показать заказчику как работать с Cursor и использовать ИИ-агентов?

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

На старте клиент не был человеком из серии "хочу приложение, но не знаю какое" - он уже прошёл классический флоу разработки с командой разработчиков, который не дал желаемого результата. Затем пробовал nocode и ИИ инструменты для написания приложения с нуля. Они дают быстрые прототипы и классный старт, позволяют CEO очень быстро проверить гипотезу, почувствовать интерфейс руками. Но у них есть потолок, в какой-то момент появляются вопросы, которые уже не решаются перетаскиванием блоков - здесь и должна появиться инженерная составляющая, инженерное сопровождение.

Как правило в разрааботке бизнес софта есть классический разрыв. Заказчик знает как всё работает в реальности, а разработчик знает, как это положить в код. Между ними живут созвоны, документы, скриншоты, "а я имел в виду не это", "а вот у нас в сезон бывает иначе"... Если проект маленький, это терпимо, но в процессе масштабирования и усложнения всё начинает сыпаться.

Обзор серверного ускорителя NVIDIA Tesla V100 16 Gb в корпусе от RTX 4090: Часть 1 - Внешний вид, установка и настройка

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

Если вы летали по России в 2000-х, скорее всего, вы летали на Boeing или Airbus. Может быть, на стареньком Ту-154. А вот на Ту-214 почти наверняка нет, хотя этот самолёт серийно выпускался с 1996 года и стоял в каталогах как современный российский среднемагистральник на 210 пассажиров. Просто его почти никто не покупал.

За тридцать лет построили 36 машин. Большую часть этих тридцати шести Ту-214 забрали госзаказчики, спецборты для чиновников, силовых ведомств, президентский парк.

Авиакомпании уходили одна за другой: «Дальавиа» обанкротилась, «Красноярские авиалинии» закрылись, «Трансаэро» пересела на Boeing и тоже обанкротилась. К началу 2020-х Ту-214 в пассажирской авиации фактически не существовал.

А потом наступил 2022-й, Boeing и Airbus ушли из России, про Ту-214 вдруг вспомнили все.

Небольшой мысленный эксперимент на стыке машинного обучения и продуктового менеджмента. О том, почему одна и та же задача «определить, что нужно клиенту» может выглядеть по-разному со стороны product'а и data scientist'а. Разбор на примере корпоративного ДМС, где у одного контракта сразу три стейкхолдера с разными работами.

Вводная: почему эта тема вообще возникла

Я много лет проработала начальником управления аналитики в страховой компании, а сейчас прохожу курс Ивана Замесина по Advanced JTBD. В какой-то момент на воркшопе меня зацепила структура, которую он назвал «графом работ» — и я поймала себя на мысли, что она похожа на знакомую мне из Data Science модель. Только с противоположным назначением.

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

В данный период своей жизни я пытаюсь создать свой стартап. Но никакой стартап не будет существовать без инвестиций. Возможно, если бы за душой было несколько лишних миллионов долларов, то, возможно обошелся бы и своими силами. Но имеем что имеем. Сразу хочу рассказать немного о себе. У меня за мою жизнь уже было несколько стартапов, один из которых дошел до третьего раунда инвестиций в миллион долларов. Приятные ощущения, работающая компания, но кризис.com‑ов решил все иначе, к сожалению. Были еще небольшие разные стартапы, на которых получалось тоже немного заработать. Это я к тому, что опыт какой никакой все‑таки есть. И каждый раз, в каждом своем проекте всегда я слышал одни и те же вопросы от программистов в своей команде: «Зачем нам вообще пилить MVP?», «А сколько денег нам дадут?», «И что, а зарплаты не будет что ли?» Когда я им отвечал честно, что первые инвестиции не про заработок, то ответ мой их все время расстраивал, ведь денег хочется прямо здесь и прямо сейчас. Прежде чем продолжить, то думаю, что стоит рассказать вам о том, кто же такой бизнес ангел для стартапа. Зачастую, если вы небольшая молодая и зеленая компания, у которой в лучшем случае есть какой‑то прототип или минимально рабочий продукт, то всяким большим дядям из больших и богатых фондов вы не интересны, они не видят в вас реальную выгоду, не видят реальных клиентов (которых обычно даже и нет на начальных этапах), не видят то, куда все ваши фантазии могут их привести. Но вы можете найти бизнес ангела, который поверит вам и поверит в вашу идею. Он дает вам начальный капитал, с которого вы уже сможете стартовать и начинать развивать свой проект.

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

Я решил считать ~/.claude/ обычным кодом и хранить его в Git.

Так появился claude-config-template — репозиторий, из которого ~/.claude/ собирается через симлинки. В нём лежат скилы, агенты, команды, хуки и MCP-конфигурации.

Это даёт:
- переносимую конфигурацию между машинами
- единый источник правды для всех агентов
- версионирование и откат через Git

За последний год появилось множество видеороликов и статей по использованию нейросетей для изучения английского языка. Очень часто авторы, среди которых попадаются и «дипломированные» учителя, в очень немногочисленных и расплывчатых промптах‑инструкциях просят ИИ ограничиваться каким‑то уровнем CEFR, от A1 до С2. Как ни странно, никто из этих авторов даже не потрудился изучить, понимают ли ChatGPT, Gemini, Claude, Grok, что входит в конкретный уровень, а что — нет. Как это можно проверить?

Эван Шпигель, сооснователь и CEO Snapchat, редко даёт интервью. Недавно он подробно рассказал, как его компания с миллиардом пользователей пережила 15 лет копирования их новых фичей конкурентами. Snapchat не просто выжили, они изобрели Stories, свайп-навигацию и AR-фильтры, которые клонировали все остальные соцсети. Шпигель объясняет, как ИИ меняет правила игры в продуктовой разработке и почему важно фокусироваться на дистрибуции продукта.

Что делает нас креативными? В течение многих лет нейробиологи указывали на «динамическое сотрудничество» между двумя противоположными системами. И нет, речь не идет о полушариях. Суть в куда более сложных структурах, таких как сеть пассивного режима работы мозга (DMN), которая обрабатывает спонтанные ассоциации, и сеть исполнительного контроля (ECN), которая отвечает за способность сводить мышление в фокус на цели.

20 000 строк кода. 9 Python-модулей. 8 JavaScript-файлов. 11 HTML-оверлеев для стримов. 16 таблиц в базе данных. 678 коллекций в базе знаний с почти 11 тысячами embeddings. Десктоп-приложение с установщиком, которое можно скачать с сайта. Telegram-бот с памятью на 30 дней. Twitch-бот с викторинами, модерацией и системой заказа музыки через YouTube.

Я не написал ни одной строчки. Ни одной.

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

Более того, зашифрованное сообщение можно сделать похожим на обычный текст или даже скрыть в обычном контенте — видео, звуковых файлах и тексте, который не вызовет подозрений у «цензора». Это область стеганографии

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

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

Всем привет! Хочу рассказать, как мы проектировали кэш поиска отелей и почему за полтора года прошли путь от Infinispan к managed Redis а затем к Postgres. По стеку java-21, spring-boot-3, 1 вендор отелей, расчетная нагрузка 1000 RPS и 10M запросов в сутки.

Практический эксперимент с Meshtastic: две Heltec ESP32 LoRa 32 V4, связь на 702 м в городской среде, разбор LoRa-настроек, ролей нод, MQTT и Python-мост к локальной LLM через Ollama.

Полгода прошло с первой статьи https://habr.com/ru/articles/969230/ , вариометр летает и сигнализирует о наборе высоты и о потере высоты, пилоты довольны. Код сыроват конечно. EMA фильтр стоит, линейная архитектура стоит, записи высот в полете нет и экспорта нет. Как-то работает. Но можно качественнее сделать. А вот когда лень переписывать с нуля, знакомая херня? Но решился.

Развернул Hermes Agent, закинул на аккаунт DeepSeek4 40 юаней, это 430 рублей, и начал диалог в терминал. Работал в диалоге с консолькой, ну просто магия. Без промптов. "Сделай FSM вместо ифов, добавь зуммер в стиле Браунигер, компенсацию акселерометра по трём осям с учётом гравитации, а не по модулю, трек полёта на флешпамять кольцевым буфером с CRC, WiFi экспорт через вебморду."

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

И в этот момент код перестаёт быть инженерной задачей. Он превращается в бесконечное тушение пожаров.

Требования меняются быстрее, чем ты успеваешь их осмыслить. Приоритеты «на вчера». Технический долг растет не потому, что вы плохие разработчики, а потому что у вас просто нет времени быть аккуратными.

Почему Фрейд и квантовая механика объясняют бизнес-решения лучше, чем большинство MBA-курсов

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

И причина лежит не в стратегии, не в рынке, не в конкурентах.

Я работаю в PR с 2001 года. Тогда профессия пиарщика активно развивалась, на рынке было много политтехнологов и консультантов. За 25 лет профессия сильно трансформировалась, в том числе и по части подготовки контента в различных форматах. И если раньше мы по крупицам собирали информацию и превращали ее в разные материалы, то сегодня контент создается намного быстрее.

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

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

Я Java-разработчик и в основном работаю с backend: Spring Boot, базы данных, интеграции, авторизация, WebSocket — всё то, что обычно находится за интерфейсом.

В какой-то момент я поймал себя на мысли: я каждый день пользуюсь мессенджерами, но плохо понимаю, как они устроены внутри. Окей, JWT, WebSocket, PostgreSQL, Redis — это понятно. Но что технически означает фраза “end-to-end encryption”? Как сервер доставляет сообщения, если он не должен их читать? Где живут ключи? Что хранится в базе? Что происходит, если у пользователя два устройства?

Решил разобраться через практику. Написал мессенджер с нуля. Назвал Chaos Messenger.

Сразу честно: криптографическую часть я изучал вместе с Claude и ChatGPT — читал спецификации X3DH и Double Ratchet, разбирал примеры, задавал вопросы, пока не сложилась цельная картина. Frontend тоже делался с активной помощью ChatGPT: я backend-разработчик, React для меня не основная среда. Но архитектура, backend, интеграция WebCrypto, модель конвертов, хранение сообщений и принципиальные решения — мои.

Для меня AI здесь был не заменой понимания, а инструментом — примерно как документация, Stack Overflow и ревью коллег. Без понимания threat model и архитектуры такой проект всё равно не собрать.

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

Стек: Spring Boot 3, React 18, WebCrypto API, PostgreSQL, Redis, WebSocket/STOMP, Prometheus, Grafana.

Я готовил участок под модульный дом в тайге, находясь за 3 500 км от объекта. Нулевой цикл занял четыре месяца и стоил около 2,8 млн ₽ еще до первого фундаментного блока. В статье разбираю, как искал землю, делал топосъемку, подводил электричество, организовывал подъезд и контролировал подрядчиков удалённо – с цифрами, ошибками и выводами по планированию. 

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

В прошлой статье мы с вами полностью разобрали схемотехнику и изучили компонентную базу легендарного телефона из 90-х годов — Motorola StarTAC. Девайс 1997 года отличался очень низким уровнем интеграции: даже такие базовые вещи, как модем (бейсбенд), DSP и RF-фронтэнд представляли из себя отдельные модули на плате. Однако уже через год, в 1998 году, Motorola представила StarTAC, где наконец объединила DSP, аудиокодек и процессор в единый кристалл.

Казалось бы, вот оно чудо инженерной мысли и дальше развиваться некуда. Но уже в 2001 году, Texas Instruments представила легендарную систему на кристалле Hercules, которая позволяла засунуть практически весь телефон в один чип. Одним из самых известных аппаратов на базе Hercules стал легендарный Sony CMD-J7, о котором мы с вами сегодня и поговорим!

Последние несколько лет в рамках своей работы в коммуникационном агентстве «ЛАМПА» я  активно занимаюсь  пиаром  IT-бизнеса: облачные провайдеры, инфраструктурные продукты, ИБ-вендоры, стартапы на разных стадиях. За это время насмотрелась на сотни корпоративных сайтов, пресс-релизов и экспертных статей, могу с уверенностью назвать главный парадокс рынка: компании, которые разрабатывают сложнейшие IT-продукты, нередко оказываются совершенно беспомощны в том, чтобы объяснить, зачем они нужны. Потенциальный клиент заходит на сайт, читает первый абзац, ничего не понимает и уходит. Даже если сам продукт качественный, удобный и решающий бизнес-задачи, текст не объясняет, почему продукт нужен именно ему прямо сейчас.

Откуда берется облако из buzzwords (модных слов и сложных терминов) 

Посмотрите на главные страницы большинства российских облачных провайдеров, и вы увидите удивительное единообразие: «надежная масштабируемая инфраструктура», «высокая доступность», «гибкое ценообразование», «инновационные решения для цифровой трансформации вашего бизнеса». Если убрать логотипы, вы, скорее всего, не отличите один провайдер от другого. Дело не в случайности и не в лени конкретного копирайтера. Это системная болезнь отрасли, у которой есть понятная причина: технические специалисты, которые пишут или согласовывают тексты, говорят на языке архитектур и стандартов, им кажется, что «IaaS с SLA 99,982%» уже достаточно понятно и убедительно. В то же время маркетинговые команды, насмотревшись на западные тексты корпоративных ИБ-вендоров, копируют их интонацию и специфический новояз, в котором каждое слово звучит внушительно, но не несет конкретного смысла. А у многих PR-специалистов, занимающихся коммуникациями таких компаний, существует страх сказать что-то конкретное и ошибиться, поэтому им кажется, что гораздо безопаснее писать расплывчато. Но расплывчатые тексты не запоминаются.

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

Год назад на рандом-кофе мы с коллегой обсуждали так называемую (мной) цифровую экологию и проблемы работы с большими данными, и он мне посоветовал доклад "The Unbelievable Insecurity of the Big Data Stack" с конференции Black Hat USA 2021 - в целом название полностью описывает содержание доклада. И вот только сейчас, спустя год, у меня дошли руки его разобрать и поделиться с вами своими мыслями на этот счёт. За пять лет доклад совершенно не утратил актуальности и, кажется, стал только более насущным.

Доклад делала Sheila A. Berta - специалист по offensive security из Аргентины, которая много лет занимается поиском уязвимостей и исследованием инфраструктур. В последние годы она сфокусировалась на безопасности Big Data и cloud-native систем. Это не теоретическая работа, а результат практического ресёрча.

Задача была простая: протестировать два веб-приложения перед деплоем. Next.js-портфолио и SaaS-чат — accessibility, консольные ошибки, отзывчивость на мобильных. Рутина.

Открыл Claude Code, подключил Playwright MCP, написал «протестируй приложение». Агент начал работать, делать скриншоты, проверять элементы. На 51-м снапшоте /compact сработал. Текстовый контекст был заполнен на 18%. Я не понял что произошло.

Через час разбирательств я нашёл невидимый image-лимит. Через три часа — понял, что Playwright MCP сжигает в 50 раз больше токенов чем CLI на том же workflow. Через три дня — у меня был рабочий инструмент, который уже тестируют реальные пользователи.

Эта статья — про путь от «хочу просто протестировать» до open-source инструмента, и про архитектурные проблемы, которые заставили его собрать.

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

Обычно, когда говорят про чиптюн, вспоминают звуковой чип SID на Commodore 64, или же Амигу и её MOD-файлы. Если речь про ПК, это будет тот же MOD и его наследники в лице форматов XM и IT. Но в истории программ для MS-DOS был один краткий музыкальный период совершенно другого рода. Он одновременно родственен и самому ПК, и чиптюну на 8-битках, и компьютерам практически с другой планеты, многочисленным японским ПК — небольшая, малоизвестная, замкнутая на саму себя и параллельная всему и вся вселенная.

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

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

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

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

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

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

Финал серии: Agent Teams, GitHub Actions, Agent SDK, TDD, Ralph-loop на ночь и осторожный прогноз на 2027

Серия на Хабре: часть 1 - что Claude Code умеет из коробки · часть 2 - настройки, хуки и Context Rot · часть 3 - автономная работа и параллелизм.

Однажды вечером я дал Claude Code не задачу "сделай фичу", а уже написанную спеку и сложный план. Дальше работал не один чат, а цепочка: оркестратор разобрал план на независимые куски, поднял кодеров в отдельных worktree, дождался их diff'ов, потом вызвал ревьюеров на каждый кусок и собрал итоговый отчёт. Утром у меня был не "ответ ассистента", а несколько веток, замечания ревью и список решений, которые всё равно должен принять человек.

Это третья и финальная часть серии. В первой я показал что такое Claude Code и почему я называю его командой из 15. Во второй - десять настроек, которые эту команду делают управляемой: CLAUDE.md на 30 строк, permissions, хуки, совещание ботиков через Codex и Gemini, Context Rot.

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

Дальше начинается параллелизм, автоматизация и автономия. Десять приёмов, которые превращают Claude Code из "умного помощника" в систему из отдельных агентов, scheduled tasks и CI-задач.

И в конце - честный разговор про то, куда всё это идёт в 2027 и что останется разработчику.

Я поставил себе два челленджа.

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

Второй — попробовать сделать полноценную игровую механику, причем не просто UI-игрушку, а что-то с 3D, сценой, камерой, эффектами и состояниями персонажей. Я не разработчик в классическом смысле, поэтому для меня это был хороший способ проверить, насколько далеко можно уехать с Codex, если у тебя есть продуктовая голова, дизайн-насмотренность и нормальное понимание, что именно ты хочешь получить.

В итоге получился Telegram-бот, который принимает фото чека, скрин банковской транзакции, PDF или просто текст операции, вытаскивает из этого сумму, дату, мерчанта, позиции в чеке, предлагает категорию и сохраняет трату. А поверх этого я привязал игру «Катись и дерись», чтобы учет расходов не был тупой таблицей, а стал живым циклом с прогрессом, дофамином и возвращаемостью.

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

Altos Computer Systems — американская компания, которая одной из первых сделала многопользовательские системы и Unix‑серверы доступными для малого и среднего бизнеса. Фирма появилась в 1977 году в Сан‑Хосе (Калифорния) и изначально продавала собственные одноплатные компьютеры, на базе которых партнеры строили целые системы.

В отличие от производителей массовых персональных ПК, Altos изначально делали ставку на многопользовательские конфигурации: один сервер и несколько терминалов, подключенных по последовательным линиям. Это была попытка перенести возможности миникомпьютеров и систем уровня IBM в ценовой диапазон, приемлемый для небольших предприятий. Уже к концу 1980‑х Altos установили порядка 128 тысяч систем по всему миру. Рассказываем, как это было и что же пошло не так. 

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

В этой статье я пробую сформулировать облегчённую методологию разработки для кросс-функциональных команд. Центральная идея — явный handover: задача не переходит молча, каждая передача — это осознанное действие с контекстом. По идее, методология должна одинаково работать, когда в команде 3 человека, 15 человек, или когда один или несколько из «участников» — AI-агенты. Это концепт, идея, черновик, открытый для критики и комментариев.

---

## Откуда это взялось

Я руковожу центром разработки клиентских и аналитических решений — 50+ человек в семи кросс-функциональных командах с разными стеками. Аналитики, разработчики, QA, DevOps, сопровождение — всё в одной цепочке, от детализации требований до эксплуатации.

За несколько лет мы перепробовали стандартный набор: Scrum, Kanban, Scrumban. Каждый из них решал что-то своё, но во всех трёх я обнаружил одинаковый пробел.

Ни одна из методологий не отвечает на вопрос: что происходит, когда задача переходит от одной роли к другой?

Вот разработчик написал код и поставил статус «Готово к тестированию». Что дальше? Тестировщик это видит? Знает контекст? Понимает, что конкретно нужно проверить? А если тестировщик заболел — задача просто лежит? Кто за это отвечает?

Ни Scrum, ни Kanban на эти вопросы не отвечают. Они описывают итерации, доски, роли — но не сам момент передачи. А именно там живёт большинство операционных потерь.

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

Автор: Александр Никулин, архитектор цифровых двойников ГК "ПЛМ Урал"

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

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

Факт 1.  Максимально циничная и максимально честная фраза, услышанная мною от одного из топ-менеджеров компании Siemens. В переводе на русский она звучит как «Деньги все расставляют по своим местам».

Факт 2.  Более 25 лет на просторах всемирной сети существует шутка, потрясающе точно отражающая реальный мир. В споре двух ученых, один воскликнул: «Вспомни историю человечества! Первая обезьяна, которая взяла в руки палку и начала работать, стала человеком!». Второй же ученый сочувственно взглянул на своего коллегу и сказал: «Не хочу обижать старика Дарвина, но, когда первая обезьяна взяла в руки палку, работать начала вторая».

Теперь вернемся к цифровым двойникам. Четвертая промышленная революция (Индустрия 4.0) постулирует цифровой двойник как основу жизненного цикла изделия. Причем в качестве изделия может выступать как физический объект, так и технологический процесс, логистический процесс и даже конкретный индивид. (да-да, цифровой двойник клиента уже реальность: имитация поведения, предпочтений и реакций на внешние воздействия в реальном времени. Все уже используется для вашего… разумеется удобства).

Выдуманный мир тёплых (до)ламповых технологий – это не обязательно «стимпанк». Можно заглянуть и глубже, в «клокворкпанк», ведь спиральная пружина – двигатель более древний и при этом более компактный, чем паровая машина. Она широко используется с середины XVII века: именно благодаря металлической спирали часы стали карманными. Часовая пружина крутила шестерёнки заводных игрушек, музыкальных шкатулок, граммофонов и много чего ещё, зачастую совершенно шедеврального a la лесковская блоха. Послужила она и науке — вспомним хоть «аэродинамическую машину» Ломоносова. А в конце XIX века её пытались приспособить для привода «серьёзной» техники: мотоциклов, автомобилей, торпед... и трамваев!

$800 на видеокарту которая устареет через год или $200/мес с доступом к frontier-моделям? Вот мои цифры

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

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

Именно под такие задачи и создавалось отраслевое решение 1С:ERP Агропромышленный комплекс. Оно построено на базе 1С:ERP Управление предприятием и дополняет корпоративный контур специализированными инструментами для растениеводства и животноводства. По сути, это цифровая основа для современной агрокомпании: от планирования посевной и учета полевых работ до аналитики по стаду, технике, затратам и эффективности.

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