Я всё чаще ловлю себя на мысли, что мой путь в AI и программной
инженерии не начинался с красивых ноутбуков, Python-ноутбуков, LLM и
удобных API. Он начинался гораздо грубее. С C++, микроконтроллеров,
проводов, странных плат, даташитов и того ощущения, когда ты пишешь код,
а потом он не просто возвращает JSON, а двигает ток, мигает светодиодом,
выводит байты в буфер или заставляет физическое устройство сделать хоть
что-то осмысленное.
Это совсем другое чувство. В обычной разработке ошибка часто выглядит
как stack trace. В embedded-системах ошибка может выглядеть как тишина.
Просто ничего не происходит. И ты сидишь, смотришь на схему, на
регистры, на питание, на тайминги, на код, и понимаешь, что железо не
будет с тобой спорить. Оно просто не работает. Очень честный собеседник,
хоть и довольно мерзкий.
Сейчас я веду несколько проектов, связанных с AI, правом,
LLM-системами, интерфейсами и автоматизацией. Это всё по-своему важно и
интересно. Но где-то под этим слоем всё ещё живёт старая любовь к
низкоуровневому программированию. К моменту, где софт перестаёт быть
просто текстом на экране и становится частью физического мира.
В студенческие годы я много возился с Arduino и другими
микроконтроллерами. Тогда это ощущалось почти как магия: несколько строк
кода, пара проводов, датчик, мотор, экран, и вдруг программа выходит из
монитора наружу. Не в философском смысле, а буквально. Ты можешь
ошибиться в логике, можешь ошибиться в подключении, можешь перепутать
питание, можешь устроить маленький электрический позор. Но именно в этом
была живая инженерия.
Отдельно в память мне врезался проект с эмулятором КР580ВМ80. Это не
самый громкий и не самый коммерчески полезный проект в моей жизни, но он
почему-то очень важен лично для меня.
Ссылка на проект: github.com/gotogrub/Emulator-KR580M80
КР580ВМ80 — советский микропроцессор, совместимый по духу с Intel
8080. В моём проекте была программа для эмулятора, которая выводила
символы в видеобуфер. Там не было модных фреймворков, красивых
dashboard-ов и презентаций для инвесторов. Были регистры, байты,
команды, переходы, OUT 00, цвет символа, код символа и
ощущение, что ты разговариваешь с машиной почти напрямую.
И это ощущение никуда не делось.
Недавно меня позвали участвовать в разработке C-UAS-направления по
зарубежному контракту. Из-за NDA я не могу рассказывать детали: ни
заказчика, ни архитектуру, ни конкретные компоненты, ни технические
решения. Это нормальная граница, и я не собираюсь её нарушать ради
красивого поста. Но сам факт для меня важен.
C-UAS — это область противодействия беспилотным системам. И здесь мне
особенно важно сказать одну вещь: я не люблю войны. Не романтизирую их,
не считаю красивыми, не считаю “естественным состоянием мира”. Я уже
успел достаточно поработать рядом с государственными структурами и
увидеть, как решения, отчёты, регламенты и чужая безответственность
превращаются в реальную человеческую усталость, страх и грязь. Война —
это не эстетика. Это не трейлер. Это не героический монтаж под музыку.
Это тяжёлая, тупая, дорогая машина, которая очень любит перемалывать
людей.
Поэтому для меня принципиально важно, что речь идёт именно о защитной
инженерии. О системах, которые могут снижать риски для мирных граждан,
инфраструктуры, городов, больниц, энергетики и обычной жизни. О
технологиях, которые не создают хаос, а помогают от него
закрываться.
Здесь неожиданно сходится почти всё, что мне всегда было интересно.
Embedded systems, обработка сигналов, компьютерное зрение, надежность,
реальное время, интерфейсы, AI, железо, ограничения, ответственность. В
таких задачах нельзя спрятаться за красивую абстракцию. Система должна
работать не в демо, не в ноутбуке, не в уютной песочнице, а в реальном
мире, где есть шум, задержки, ошибки, плохая погода, странные данные,
ограниченное железо и цена неправильного решения.
Именно поэтому embedded systems до сих пор так цепляют. Они
заставляют инженера быть честнее. Ты не можешь бесконечно прикрывать
архитектурную слабость красивыми словами. Не можешь надеяться, что
пользователь “поймёт”. Не можешь просто перезапустить контейнер и
сделать вид, что всё нормально. Если система работает с физической
средой, она либо справляется, либо нет.
В AI сейчас много разговоров о разуме, агентах, рассуждении,
автономности и будущем машин. Это интересно. Но мне всё чаще кажется,
что настоящее будущее начинается не там, где модель красиво отвечает в
чате, а там, где интеллект получает тело, сенсоры, ограничения,
ответственность и контакт с физическим миром.
Голосовой агент может говорить. Компьютерное зрение может видеть. LLM
может объяснять. Но embedded-система заставляет всё это действовать в
мире, где есть электричество, металл, воздух, помехи, люди и
последствия.
Наверное, поэтому меня так вдохновляет этот поворот. С одной стороны,
я продолжаю заниматься AI, архитектурой, командами и продуктами. С
другой — снова чувствую связь с тем самым началом: C++,
микроконтроллеры, регистры, байты, железо, странные ошибки и радость от
того, что машина наконец-то делает то, что ты от неё хотел.
Моя любовь к низкоуровневому программированию не угасла. Она просто
стала взрослее. Раньше это было любопытство: “а получится ли заставить
плату ожить?” Сейчас это другой вопрос: “можно ли построить систему,
которая будет реально полезна людям?”
И если когда-то я писал код, чтобы вывести символы в видеобуфер
старого микропроцессора, то теперь мне интересно строить системы,
которые соединяют AI, железо и реальный мир. Системы, которые видят,
слышат, реагируют, защищают и работают не ради презентации, а ради
результата.
Наверное, именно в этом для меня и есть инженерная романтика. Не в
войне. Не в оружии. Не в красивых словах про технологии будущего.
А в возможности взять хаос, сигнал, код, железо и ответственность — и
собрать из этого что-то, что делает мир хоть немного безопаснее.
I increasingly catch myself thinking that my path into AI and
software engineering did not begin with sleek laptops, Python notebooks,
LLMs, and convenient APIs. It began much more roughly: with C++,
microcontrollers, wires, odd boards, datasheets, and that feeling when
you write code and it does not merely return JSON, but moves a bit,
blinks an LED, writes bytes into a buffer, or makes a physical device do
something—anything—meaningful.
It is an entirely different feeling. In ordinary development, an
error often looks like a stack trace. In embedded systems, an error can
look like silence. Nothing simply happens. You sit there looking at the
schematic, the registers, the power supply, the timings, the code, and
realize that hardware will not argue with you. It just does not work. A
very honest conversationalist, if a rather nasty one.
These days I lead several projects involving AI, law, LLM systems,
interfaces, and automation. All of that is important and interesting in
its own way. But somewhere beneath that layer, my old love of low-level
programming is still alive: the moment when software stops being merely
text on a screen and becomes part of the physical world.
As a student, I spent a great deal of time tinkering with Arduino and
other microcontrollers. Back then it felt almost magical: a few lines of
code, a couple of wires, a sensor, a motor, a display—and suddenly the
program leaves the monitor and goes outside. Not metaphorically, but
literally. You can make a mistake in the logic, in the wiring, in the
power connections; you can stage a small electrical embarrassment. But
that was precisely what made it feel like living engineering.
One project that has stayed particularly vivid in my memory was an
emulator for the KR580VM80. It is neither the loudest nor the most
commercially useful project of my life, yet for some reason it matters
to me very personally.
Project link: github.com/gotogrub/Emulator-KR580M80
The KR580VM80 is a Soviet microprocessor, spiritually compatible with
the Intel 8080. My project included a program for the emulator that
wrote characters to a video buffer. There were no fashionable
frameworks, polished dashboards, or investor presentations. There were
registers, bytes, instructions, jumps, OUT 00, character
colors, character codes, and the feeling that you were speaking to the
machine almost directly.
And that feeling never went away.
Recently, I was invited to contribute to a C-UAS initiative under an
international contract. Because of the NDA, I cannot discuss the
details: not the customer, architecture, specific components, or
technical decisions. That is a perfectly normal boundary, and I have no
intention of crossing it for the sake of a pretty post. But the fact
itself matters to me.
C-UAS is the field of countering unmanned systems. And here it is
especially important for me to say one thing: I do not like war. I do
not romanticize it, consider it beautiful, or see it as the “natural
state of the world.” I have already worked close enough to government
structures to see how decisions, reports, regulations, and other
people’s irresponsibility turn into real human exhaustion, fear, and
filth. War is not an aesthetic. It is not a trailer. It is not a heroic
montage set to music. It is a heavy, stupid, expensive machine that is
very fond of grinding people up.
That is why it matters to me that this is specifically defensive
engineering: systems that can reduce risks for civilians,
infrastructure, cities, hospitals, energy systems, and everyday life.
Technologies that do not create chaos, but help shield us from it.
Almost everything that has always interested me unexpectedly
converges here: embedded systems, signal processing, computer vision,
reliability, real-time operation, interfaces, AI, hardware, constraints,
responsibility. In problems like these, you cannot hide behind a
beautiful abstraction. The system has to work not in a demo, not in a
notebook, not in a cozy sandbox, but in the real world—where there is
noise, latency, error, bad weather, strange data, constrained hardware,
and a price for the wrong decision.
That is exactly why embedded systems still have such a grip on me.
They force an engineer to be more honest. You cannot endlessly cover
architectural weakness with pretty words. You cannot hope the user will
“understand.” You cannot simply restart a container and pretend
everything is fine. When a system deals with the physical environment,
it either copes or it does not.
There is a great deal of talk in AI right now about minds, agents,
reasoning, autonomy, and the future of machines. It is interesting. But
I increasingly think that the real future begins not where a model
answers beautifully in a chat, but where intelligence acquires a body,
sensors, constraints, responsibility, and contact with the physical
world.
A voice agent can speak. Computer vision can see. An LLM can explain.
But an embedded system makes all of that act in a world of electricity,
metal, air, interference, people, and consequences.
That is probably why this turn excites me so much. On the one hand, I
continue working with AI, architecture, teams, and products. On the
other, I feel connected again to that very beginning: C++,
microcontrollers, registers, bytes, hardware, strange errors, and the
joy of finally making a machine do what you wanted it to do.
My love of low-level programming has not faded. It has simply grown
up. Before, it was curiosity: “Can I make this board come alive?” Now
the question is different: “Can we build a system that will be genuinely
useful to people?”
And if I once wrote code to put characters into the video buffer of
an old microprocessor, now I am interested in building systems that
connect AI, hardware, and the real world. Systems that see, hear, react,
protect, and work not for a presentation, but for results.
That, perhaps, is engineering romance for me. Not war. Not weapons.
Not pretty words about the technologies of the future.
But the possibility of taking chaos, signal, code, hardware, and
responsibility—and assembling them into something that makes the world
even a little safer.