В серии «В центре внимания авторов» редакторы TDS беседуют с членами нашего сообщества об их карьерном пути в области науки о данных и искусственного интеллекта, их писательстве и источниках вдохновения. Сегодня мы рады поделиться нашим разговором Майк Холс.
Майк — технический руководитель, который работает на стыке инженерии данных, искусственного интеллекта и архитектуры, помогая организациям превращать сложные ландшафты данных в надежные и удобные системы. Имея обширный опыт работы в сфере полного стека, он разрабатывает комплексные решения, которые сочетают в себе техническую глубину и ценность для бизнеса. Наряду с работой с клиентами он создает и делится практическими инструментами и идеями о платформах данных, системах искусственного интеллекта и масштабируемых архитектурах.
Считаете ли вы себя Full-Stack разработчиком? Как ваш опыт работы со всем стеком (от внешнего интерфейса до базы данных) меняет ваше представление о роли специалиста по данным?
Да, но не в смысле создания каждого слоя по отдельности. Для меня полный стек означает понимание того, как архитектурные решения на одном уровне формируют поведение системы, риски и затраты с течением времени. Эта точка зрения важна при проектировании систем, которым необходимо пережить изменения.
Эта точка зрения также влияет на то, как я рассматриваю роль специалиста по данным. Модели, созданные в блокноте, — это только начало. Реальная ценность проявляется, когда эти модели внедряются в производственные системы с соответствующими конвейерами данных, API-интерфейсами, средствами управления и интерфейсами, ориентированными на пользователя. Наука о данных становится эффективной, когда ее рассматривают как основную часть более крупной системы, а не как отдельный вид деятельности.
Вы освещаете широкий спектр тем. Как вы решаете, на чем сосредоточиться дальше, и как узнать, что новую тему стоит изучить?
Я слежу за повторяющимся трением. Когда я вижу, что несколько команд борются с похожими проблемами, техническими или организационными, я воспринимаю это как знак того, что проблема носит скорее структурный, чем личный характер, и ее стоит решать на уровне архитектуры или процесса.
Я также сознательно экспериментирую с новыми технологиями не ради новизны, а для понимания их потенциальных преимуществ. Тема становится достойной написания, когда она либо решает реальную проблему, с которой я сейчас сталкиваюсь, либо раскрывает риски, которые еще не получили широкого понимания. В конечном счете, я пишу о темах, которые лично мне кажутся интересными и достойными изучения, потому что постоянный интерес — это то, что позволяет мне копать глубже.
Вы писали о Langgraph, MCP и автономных агентах. Как вы думаете, какое самое большое заблуждение сегодня существует у людей об агентах ИИ?
Агенты действительно сильны и открывают новые возможности. Заблуждение состоит в том, что они просты. Сегодня легко собрать облачную инфраструктуру, подключить агентскую среду и создать что-то, что будет работать. Этот доступ ценен, но он скрывает множество сложностей.
Как только агенты выходят за рамки демо-версии, возникают настоящие проблемы. Управление состоянием, разрешения, контроль затрат, наблюдаемость и управление сбоями часто недооцениваются. Без четких границ и собственности деятельность агентов становится непредсказуемой, дорогостоящей и рискованной. Это не просто знаки с инструментами; Это долгосрочные программные системы, и их необходимо проектировать и эксплуатировать соответствующим образом.
в твоей статье многоуровневая архитектураВы упомянули, что добавление новых функций часто напоминает «операцию на открытом сердце». Каков ваш главный совет по настройке архитектуры начинающим или небольшим командам, работающим с данными, которые хотят избежать этого?
«Единственная константа — это изменения» — это клише по уважительной причине, поэтому оптимизируйте изменения, а не первоначальную скорость доставки. Помогает даже минимальная форма многоуровневого мышления: разделение логики предметной области, потока приложений и проблем инфраструктуры.
Целью не является архитектурное совершенство или полная классификация с первого дня. Речь идет о создании четких границ, которые позволяют системе развиваться без постоянных переписываний. По мере роста системы небольшая первоначальная дисциплина существенно окупается.
вы сравнили Стратегии вставки PostgreSQL и отметил, что «быстрее не всегда лучше». В каком сценарии производственного конвейера машинного обучения вы бы намеренно выбрали более медленный и безопасный метод вставки?
Когда чистота, отслеживаемость и возможность восстановления важнее, чем пропускная способность сырья. Во многих конвейерах сокращение времени выполнения на несколько секунд дает мало пользы по сравнению с риском, связанным со слабыми гарантиями.
Например, конвейеры, которые передают нормативную отчетность, принятие финансовых решений или долгосрочные наборы обучающих данных, выигрывают от транзакционной безопасности и явной проверки. Скрытое повреждение данных обходится гораздо дороже, чем принятие незначительных компромиссов в производительности, особенно когда данные становятся долгосрочным активом, на котором будут строиться другие.
в твоем личный помощник агента Статья, вы создали 100% частную платформу с собственным хостингом. Почему для вас было важнее избежать «стоимости токенов» и «утечек конфиденциальности», чем использовать более мощный облачный LLM?
В своей повседневной работе я убедился, что доверие к системе имеет основополагающее значение для ее принятия. Стоимость токенов, непрозрачные потоки данных и внешние зависимости тонко влияют на то, как используется система.
Я также сделал осознанный выбор не отправлять свои личные или конфиденциальные данные через внешних облачных провайдеров, поскольку существуют ограниченные гарантии того, как данные будут управляться с течением времени. Сохраняя систему на автономном хостинге, я могу разработать поддержку, которая будет предсказуемой, проверяемой и соответствующей европейским ожиданиям конфиденциальности. Пользователи имеют полный контроль над тем, к чему имеет доступ Помощник, что снижает барьеры для использования Помощника.
Наконец, не для каждого варианта использования требуется самая большая или самая дорогая модель. Отделив системы от одного поставщика, пользователи могут выбрать модель, которая лучше всего соответствует их потребностям, сохраняя при этом баланс мощности, затрат и рисков.
Как, по вашему мнению, изменится повседневная работа специалиста по обработке данных в 2026 году?
Несмотря на распространенные стереотипы, разработка данных и программного обеспечения — это очень социальные профессии. Я твердо верю, что самая важная часть работы происходит до написания кода: согласование с заинтересованными сторонами, понимание проблемного пространства и разработка решений, которые подходят существующим системам и командам.
Эта предварительная работа становится еще более важной, поскольку разработка с помощью агентов ускоряет внедрение. Без четких целей, контекста и ограничений агенты скорее увеличивают путаницу, чем производительность.
В 2026 году специалисты по данным будут уделять больше времени формированию систем, определению границ, проверке предположений и обеспечению ответственного поведения в производственных средах.
Заглядывая в оставшуюся часть 2026 года, какие важные темы, по вашему мнению, будут определять год для профессионалов в области данных? Почему?
Генеративный ИИ и агентные системы будут продолжать развиваться, но большим изменением станет их превращение в первоклассные производственные системы, а не в эксперименты.
Эта трансформация зависит от надежных, высококачественных и доступных данных и эффективных инженерных практик. В результате комплексное мышление и проектирование на уровне системы будут становиться все более важными для организаций, которые хотят ответственно и масштабно внедрять ИИ.
Чтобы узнать больше о работе Майка и быть в курсе его последних статей, вы можете подписаться на него в TDS или LinkedIn.
