I build real-time systems for broadcast and live production — and I put AI inside them. Years of signal chain on one side, working software on the other. Very few people stand in both places.
Most people who can build the model layer have never patched an audio feed under time pressure, never lost a session to a genlock problem, and have no instinct for what happens when the deadline is the doors opening and there is no second take.
Most people who live in that world — vMix, NDI, SRT, SDI infrastructure, FFmpeg — have never written the software that would automate it.
I work in both. The projects below are the evidence: a live speech pipeline that self-corrects against primary sources, a secure remote-control platform running in production across five platforms, and a tape archive engine that talks raw SCSI on three operating systems. Each page is written for an engineer, includes what went wrong, and states plainly what is not finished.
A live, self-correcting transcription pipeline for classes taught in three languages at once. The interesting part is not the transcription — it is designing a system whose output a human can verify in five seconds, and refusing to publish an accuracy number I cannot defend.
Secure remote control across Windows, macOS, Linux, iOS and Android, with a Windows service agent that reaches a machine at the login screen. Includes the production incident that destroyed fifteen days of customer data and the four rules that came out of it.
LTO tape archive software that speaks raw SCSI through three different operating-system mechanisms behind a single trait — and treats the tape, not the database, as the source of truth. An architecture study: the design is done, the engine does not yet write a tape.
A large share of the code in these projects was written by AI. What I do is the other half: I have the idea and define what the system has to do, I choose the technology, I write the instructions that direct the implementation, and then I test it against real signal, real audio and real hardware and adjust it empirically until it behaves. I disclose this on every case study, because the interesting question about an engineer in 2026 is not whether they typed each line — it is whether they can stay responsible for a system that now produces code faster than any human can read it.
That last part — testing and adjusting — is not a small share of the work. A model will produce something that compiles, looks finished, and is quietly wrong. Knowing that the output is wrong, and why, is the scarce skill here, and it comes from years of watching real signal misbehave rather than from anything a model can supply.
That takes more process than writing by hand, not less. My repositories carry a written briefing every session reads before touching anything, architecture decision records so a model with no memory cannot quietly re-litigate a choice that was already paid for, one feature per commit, rollback as a precondition rather than a contingency, and runbooks for the night something breaks. Those rules were not adopted from a blog post — each one exists because something went wrong first.
What I do not do is integrate code I have not read. That builds a system only the model can maintain, and the invoice arrives about six months later.
AV, broadcast and post-production operations that want AI or automation in the workflow and need someone who understands both halves.
Live captioning, archive systems, remote operations and production automation, delivered through VENG.
Applied AI and media engineering for AV and broadcast professionals, in Portuguese, English or Spanish.
Remote technical collaboration with teams outside Brazil — contract projects, partnerships and joint work across time zones.
Partner at VENG (Vídeo Engenharia), São Paulo — professional AV, broadcast technology and technical training. Working in Portuguese, English and Spanish, across the São Paulo–Rio axis and remotely.