Всем привет! Сейчас делаем сварочный проект: в симуляторе провариваем 3D-модель детали, собираем траектории и смотрим, как горелка проходит все швы на этой геометрии.

🔎 На этом этапе проверяем порядок проходов, подход к сложным местам и саму логику сварки по детали. Скоро покажем фотки уже с завода.

Всем привет! На связи Иван, руководитель НИИ Крокодил

Недавно прочитал на Хабре статью о том, на чём будут учиться нейросети в 2026 году. Там был тезис, что «интернет как универсальный бесплатный датасет» больше не работает в прежнем виде. Согласен с автором и вот почему:

AI-контента становится всё больше, юридические ограничения усиливаются, знания постепенно уходят из открытых источников в корпоративные базы и закрытые каналы. Обучать можно, дообучать можно — вопрос в качестве и происхождении данных.

Но в прикладном ИИ проблема ещё приземлённее.

Мы редко упираемся в отсутствие данных вообще. Чаще — в отсутствие данных под конкретную среду.

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

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

Поэтому вопрос сейчас не только в моделях, а в том, насколько компании готовы системно работать с данными. А вы что думаете по этому поводу?

Всем привет! На связи Иван, руководитель НИИ Крокодил 😀

Это продолжение истории про медицинское приложение для клиники.

Часть 2. Как устроена медицинская система изнутри

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

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

🧪 Отдельная история — тестирование. Мы проверяли не только интерфейс, а связку «мобильное приложение + сервер клиники». Запись и отмена приёма, конкуренция за слот, обработка ошибок, загрузка PDF-документов, корректная работа вложенных структур в истории посещений — всё это нужно было прогонять реальными сценариями.

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

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

Всем привет! На связи Иван, руководитель НИИ Крокодил 😀

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

Часть 1. Как устроена медицинская система изнутри

Мобильное приложение не содержало бизнес-логики. Все расчёты, проверки, сценарии и данные находились на стороне backend-сервиса клиники. Приложение работало как тонкий клиент: отправляло запросы и отображало результат.

📦 Данные в приложении не хранились

Каждое действие пользователя превращалось в запрос на сервер: авторизация, запись к врачу, список анализов. Сервер возвращал актуальное состояние системы в ответе. Если данные менялись на сервере, пользователь сразу видел это в приложении.

🕓 Запись к врачу была не одной формой, а сценарием

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

⭐️ В следующих частях разберу технические сложности, с которыми мы столкнулись при разработке таких систем.