Subscribe
Share
Share
Embed
Dan and Niels Bantilan discuss how AI agents are changing Niels's work on two open-source projects, Flyte and Pandera. Flyte began as an MLOps orchestrator and is evolving into an AI runtime for the code, compute, and execution systems around models and agents. Pandera remains a smaller, community-focused data-validation project.
Niels finds agents most useful in mature codebases with strong structure, linters, type checks, and tests. He estimates that his coding velocity has increased at least threefold. Local models handle small fixes, while commercial tools perform better on longer tasks that require broad codebase analysis. Pull requests and code review remain central, with reviewers checking for code smells, security problems, and performance issues.
Agents now participate in Niels's debugging loop inside live Kubernetes clusters. Through Flyte's MCP server, an agent can inspect logs, identify an out-of-memory error, update the Flyte configuration, and retry the workload. In one case, an agent found an off-by-one error in tensor loading within five minutes, fixing a model that had been emitting garbage symbols. The experience also exposed a risk: Niels has started skimming the agent's report instead of reconstructing every bug himself.
At Union, internal agents have narrow responsibilities and return reviewable artifacts. Nody handles customer requests to change node-pool limits and opens pull requests for engineers to review. Doxy monitors SDK changes and proposes documentation updates. Niels applies the same pattern to PRDs, go-to-market writing, and code examples. Agents should have clear access boundaries and produce work that people can inspect.
Niels imagines Flyte letting agents assemble workflows instead of following fixed DAGs. Typed tasks define the available building blocks, while Pydantic Monty safely runs the control-flow code an agent writes. Flyte can move files between pods, route heavy work to suitable compute, and resume a 100-step pipeline at step 98 instead of starting over. Niels sees this as the foundation for an AI runtime that combines agents with training, inference, and reinforcement-learning rollouts.
Agents have also made it easier for Niels to maintain Pandera while raising a young family. He is exploring validation schemas for vectors, images, and tensor containers, with Narwhals and LanceDB as possible paths into multimodal data. The design remains open. Pandera's concise plain-text errors work well for agents, while HTML reports may better serve people. Across both projects, Niels sees a continuing human responsibility: understand enough of the system to decide whether an agent's output is worth keeping.
Chapters
⠀
Links from the show
--------------------
⠀
Guests
-------
Niels Bantilan, Chief Machine Learning Engineer, Union
⠀
Follow the podcast
-------------------
⠀
Follow Dan Gerlanc
-------------------
The podcast about agentic AI, agentic software engineering, and entrepreneurship.
Each episode is a conversation with people building with agentic AI. Join me as I follow the stories, the behind-the-scenes, and the people behind the code.
About your host, Dan Gerlanc:
Dan brings his experience as a 4x founder with 20 years of experience in ML and software to find unique insights on the impact of AI in tech, software engineering, and entrepreneurship.
I'm Dan Gerlanc and welcome to Agents and Engineers,
the podcast about agentic AI and software development.
Today our guest is Niels Bantilan Niels is the Chief Machine Learning
Engineer at Union, a core maintainer of Flyte an open source
AI orchestration platform.
The creator of Pandera, a data validation and testing tool for data frames.
His mission is to help ML and AI practitioners be more productive.
He has a master's in public health informatics,
and prior to that a background in developmental biology and immunology.
His research interests include reinforcement learning,
NLP, ML in creative applications,
and fairness, accountability, and transparency in automated system.
Niels thanks for joining us today.
Hey Dan, thanks for having me.
Excited to be here.
Likewise. So tell me a bit about
how Agentic AI has changed the different open source projects
you're involved in and maintain.
I'll let you let you pick where to start.
Yeah.
Yeah. I guess I'll I'll start with Flyte.
I am as you said, the maintainer of Flyte and and Pandera.
Two very different flavors of open source.
Flyte, just for context, is kind of MLOps.
It grew up in the ML ops orchestration space.
We're kind of pivoting, we're kind of changing like how we talk about ourselves
and talking more.
AI runtime and what that means,
but
Effectively, it solves the problem of how do you build systems
in production that have a machine learning component and with agents
and AI increasingly what is the I guess cognitive architecture,
if you want to call it that, around the the code that supports the code
and the other pieces in the stack that supports the typically LLM that helps
you build very flexible, powerful systems.
So Flyte is that type of project similar in the problem spaces like
Airflow or other orchestrators out there with a few,
or I would say a couple of core assumptions that that make
it particularly well suited for machine learning and AI workloads
at its like primitive level.
So that's Flyte. And then Pandera is a data frame validation library that supports
all sorts of data frame formats now.
I'll start with Flyte just because it's there's a very interesting kind
of balance that you may relate to as well around open source and commercial.
So whereas Pandera is very much a pure open source
project that
I have not made any moves to commercialize at this point.
That that may change at some point in the future.
But right now it's it's like a labor of love.
I started it as a side project,
kind of merged it into Union as an open source project after I joined.
and so that has some different properties,
but I think for Flyte
And for both, right? But in particular,
Flyte Agents has really, I think,
helped me and and the Union team,
who is like the main maintainer and shepherd of of that project.
Flyte is also it's owned by the Linux Foundation.
but I mean I can start at the front line,
right? So a lot of our developers are now just using agents like to implement
features and do bug fixes. I I would say if you already have
a pretty well structured and opinionated project that has linters
and type type linting, type checking,
like a s kind of a style guide,
so to speak.
and fairly mature in this the structure of how modular modules are laid out,
how the unit tests are all structured.
Actually agents at this point in June 2026 are are really fantastic.
I use kind of a mix. I generally use Claude or Cursor.
I'm slowly migrating over to Pi.
I've dabbled with OpenCode but yeah,
I'm just trying out the whole local sovereign AI story and it's you know,
it's it's not as good, I would say,
off the bat, as the commercial offerings out there,
but I think I'm slowly getting there.
a lot of it I think just has to do with
the prompting and like sort of the there's a little bit more work you need
to do in terms of like the skills and the harness you have to attach
to these open source agent harnesses.
Do you have a Mac with a
lot of RAM?
Yeah, I have a DGX Spark actually.
Okay.
So I I host I'm currently hosting Qwen 80 Billion Coder Next on it.
And yeah, I think the the class of tasks in
my job that the local AI does really well are mostly bug fixes
and very small scoped changes.
Like, hey, I need to add a flag to the CLI.
And make sure all the changes proc propagate through all the relevant parts
of the code base does that super well.
if it's a longer running task that might take an hour to complete.
I found that I can give
a pretty sizable like part of a PRD pro product requirements
doc over to like Claude and it will kind of
For the most part, hit it out of the park.
And as I yeah, as I mentioned earlier to you before we started recording,
it's like a lot of reading. So it's sort of like you have a you have
a coworker and they can spit out thousands,
hundreds of thousands of lines of code.
So you just you wanna be careful because you're not you don't want to review like
a PR that's massive, just like with irregular,
like pre-AI agent workflows.
So the
Is that something
you have fairly strict requirements around that like things still go through
a PR workflow into very well-defined changes?
For the most part in the project,
yes. our team is has an engineering background.
Most of us at at Union AI are backend engineers.
I am a MLE data scientist by training.
but I have I would say I do have more of an engineering mindset than like
a researcher mindset. I do get a little,
more particular about sort of like style and and formatting and
and things like that. I mean we have linters that for that now to like abstract that
away.
So yeah, I mean we we still do PRs,
we still do code review. most of it I would suspect.
I I haven't like asked this of my team,
but I suspect most of us are have a fairly high level of trust of these systems now,
and we're mainly looking for code smells,
security-related things,
performance-related things.
that just immediately kinda stand out to us.
but our velocity is like I would say much faster.
What would you say compared to before if you had to estimate increase in velocity?
I mean I I wouldn't say it's 10x I would say it's like
At least three.
I mean as I said, I it's it's been a while for me that I've
got into the weeds and gone into like the into the traditional debug
like REPL loop of running the debugger on like
VS Code or Cursor. And like my debug loop is literally the agent making those
changes. I'll like add I'll add tests.
via prompting. It was like, hey,
you didn't catch this, you know,
like, hey, test this part more and you know,
maybe do I mean we don't use hypothesis like
the the property-based testing thing quite yet.
but you know just add more test cases to cover this like part of the execution path.
and then yeah for the most part if if my prompt
is is small enough in scope it'll like do that very well as well.
when I debug stuff also, so Union and Flyte,
it's like a cluster, it's a Kubernetes cluster on some cloud somewhere.
I literally point we have a Flyte MCP now,
so I just point
My agent to the config file that that will authenticate through my browser
and then open up a session and it'll just like run workloads and
the MCP exposes logs and errors that happen on the Kubernetes cluster.
So my agent basically has access to Kubernetes arbitrary computes within limits
to test test out what I'm building.
And do you think this is a good use case for MCP?
I know there's some talk of people say,
like, skills or MCP, which I mean at the end of the day you can do
the same things with either or CLIs.
How do you feel
Yeah.
about that implement do you feel like in this case?
There was a strong reason to go with MCP because you're then hooking into
a Kubernetes cluster.
Yeah, I would say kind of the latter.
So I could have created
a skill that like the answer is auth,
basically. Like I could have created a a s a skill that describes
the kubectl commands to like get the logs from the pods that are erring out.
But Flyte also is like an abstraction over Kubernetes,
so I
Like I don't want to deal with Kubernetes as much as possible.
that's just you know.
Most people don't.
An
an explicit decision that yes,
that I've made. I'm not a platform person.
I don't ever really want to interact with it as much as possible.
so
The Flyte MCP that we have just I I provide my like Flyte API key,
and that just you know it has access to whatever parts of the Kubernetes
API surface we surface to users through the Flyte API.
so it's a it's a much smaller constrained surface.
It gives me all the logs and errors and stuff.
That's mostly what I need for a proper like agent debugging loop.
and it's nice too because the agent can figure,
hey,
this was an out of memory error,
so let me just like slightly change my Flyte configuration to ask ask
for a little bit more memory. it can even like potentially profile
the data set that I'm working with and analyze it a little bit
and kind of estimate like okay now I need to provision maybe four more gigs.
so yeah it's I I don't know I feel very spoiled that like I have
Access to agents in general for development,
but then as an ML person, ML
is like the the core diff difference between a software engineer and
an ML engineer is like generally compute.
Like a software engineer, you can like unit test stuff,
right? You can like mock out things,
which you could do to a certain extent in machine learning,
but
For anyone out there who's like trained a model,
like the magic only really happens at a certain scale.
You have to wait for a while for like the loss to go down enough,
for things to start kind of snapping into place.
How does it feel to be seeing the whole world
of AI engineering as a traditional ML engineer
Ha ha
developer?
it's it's funny 'cause you can say that I've been chasing titles all of my career,
right? 'Cause
Mm-hmm.
I've I started off as a data scientist.
Because I I mean I enjoyed the visualization part,
the understanding of the data part,
the modeling of it. at the outset when I sort of like came in from grad school
and and started learning about the space.
soon after though,
when I started productionizing stuff at my first startup job,
That's sort of that's when I learned about like build systems.
I I wasn't I'm not like a CS or classically trained software engineer.
I guess software engineers generally like you learn on the job actually anyway.
So all the stuff around CI testing,
unit testing, integration testing,
all that good stuff. That that part actually was fun for me also.
And so I my sh my
Mindset kind of shifted to okay,
it's cool to have like stuff in notebooks and like analysis that provide insights
and may help you make decisions,
but it's like when you start serving models in production,
there's like a whole set of other concerns that you have to learn about
on top of like the all the other skills that I think it's is good to pick
up as a data scientist. and so now with AI engineering,
my my
kind of reasoning by analogy is inference has taken up the r this
the oxygen in the room. Like ML was all about training.
AI engineering is mostly about inference time things you can do with the model,
which before was like all I do is predict a thing,
right? And it's just like a scalar,
like for the the regression or a classification thing.
Now with LLMs and like the multimodal stuff,
it's whole documents and whole videos and images,
right? So
the the space of applications has just exploded on the inference side.
And you're kind of now seeing a little bit of a return with RL
and like a j it's an overloaded term,
right? You have RL agents and then you have AI agents and there's an overlap,
obviously. and so a little bit more emphasis coming back
to RL and like training.
And it's a little bit it's a hybrid thing because with RL there are rollouts,
so you need like an inference server somewhere generating rollouts
for whatever your latest checkpoint is or your latest policy is.
So we're starting to, you know,
we're we're because we're a platform company,
Union AI is, we
We have to serve our existing customer base and as trends shift and
as people's use cases change, we turn our attention to those things.
And so RL is something I have the the RL textbook here,
you know, so I've kind of like picked it back up
Yeah, nice.
and just the the Sutton and Barto Barto one.