Sign in or Join the community to continue
Two and a half wolves
Posted Nov 11, 2026 | Views 3
# Agentic AI
# Software Engineering
# AI Coding
# Engineering Careers
# Open Weight Models
# AAIF Munich
Share
Speaker
Svetozar Miučin
Solutions Architect @ Amazon Web Services (AWS)
Svetozar Miučin is a Solutions Architect at AWS, helping startups across Germany build scalable, cost-efficient cloud infrastructure and adopt GenAI solutions. He holds a PhD in Computer Engineering from the University of British Columbia and brings 12 years of experience in software engineering, AI/ML, and systems optimization.
+ Read More
SUMMARY
Are you paying attention? Software engineering has changed. Agents are here in force. Everything is in flux. To adapt in the long term, we must understand the foundations.
An open-weight model took Svetozar Miučin's naive PageRank in C from 4 seconds to 0.1 seconds in about five minutes. He spent six years of his PhD building tools for that kind of work.
In this talk, given in a personal capacity, Svetozar argues that inside every engineer are two and a half wolves. The builder wolf ships anything for the dopamine. The craft wolf cares about engineering excellence. The cub, the half wolf, decides what is worth building at all. Along the way, he covers why "we get paid for an outcome, not a verb", the shaky base of the engineering pyramid as fewer juniors come in, why the first question should be "can I sell it?" (get a letter of intent), and why the future is polymathic.
+ Read More
CONTENT & TRANSCRIPT
Thank you, Max, for the amazing talk on
the infrastructure factory. Um, we're
going to do a slight change of of gears
here. I'm not going to go very technical
on you tonight. Um, my name is Fedazar.
My pronouns are he, him, and today I'm
going to talk to you about two and a
half wolves. If you're a little bit
confused, that's because I want you to
be a little bit confused at this point.
Um, this is an unaffiliated talk. So,
all of the opinions expressed here are
completely my own. I do not represent
anyone here. All right. So,
let's get to know each other. Um, I told
you my name. I work currently at Amazon
Web Services. This is a list of places I
worked at. uh scaled to the amount of
time I spent there. This is roughly the
list of topics that are currently
occupying my brain over the course of my
life. I got to accumulate three higher
uh education degrees. More on that in a
little bit. And I come originally from
Serbia. I've spent nine years in Canada
and finally came to Munich 5 years ago.
All right. So before we start, I need to
disclose my AI usage because I think
it's fair. Um, all of the text on and
off screen is fully my own. I haven't
used AI for writing. Um, thank you. The
used AI for writing. Um, thank you. The slide,
thank you. Very kind. Uh, the slide
layout is executed by DeepSeek 4.1 Flash
in a PI harness uh completely directed
by me. So the way things should look are
driven by me but executed by an AI. All
of the you'll see the generated images.
They're done by a model uh by a very
good local Munich company called Pruna.
Uh there's some charts and diagrams.
Some of them I handcrafted in Draw.io.
Some of them I actually drew on paper
and took a photo of and then had Claude
transcribe them into Python codes to
regenerate them. Very fun. And some data
sets were obtained through claude in
research mode. And is this dying? No,
shouldn't be. Okay. Um, cool. So,
motivation. Why am I talking to you
about this today? Well, I've been on the
internet, as I'm sure all of you have,
and there's quite a bit of sentiment
coming from the software engineering
community. Oh, an agent.
It's an agent. Um,
okay, we'll try it a little bit more.
Um, and usually it boils down to two
camps. Some people are very worried
about where we are headed and they want
the good old times back, which is valid,
and some people are on the contrary very
bullish. They're running their agents
24/7, producing PRs as they sleep, you
know, all of that magical stuff. Um so
me being a software engineer by
education u and a long career um this
affects me personally right so I want to
know um or I can't know but I want to
try to figure out what software
engineering is and should look like in
the future.
The second part of my motivation I told
you I'm going to come back to the
education story. Um so I'm an academia
survivor. I did a PhD in computer
systems. Um namely memory performance
optimization. If you haven't done this
in your life, you're very very lucky. Uh
it's a very gnarly field. Uh memory
performance optimization used to be
extremely difficult. So during my stint
in academia, I built tools to help
people optimize memory performance
automatically through the use of um some
machine learning, some code analysis,
etc. This was a long time ago. Um and
then recently I
wanted to test how LLMs fare at this. So
I took page rank. Anyone remember page
rank? Yeah, some heads. Nice. Uh, page
rank is a graph algorithm for ranking
web pages. I think pioneered by Google
um way back, right? And it was used as
one of the interesting benchmarks in the
performance optimization community. So I
took page rank, I did a very naive
implementation of it in C with no
optimization, right? So linked uh
structures all the way everything sucked
and then I took my DeepSseek Flash 4.1
the other day and told it to optimize
the other day and told it to optimize that
and we got this. So the baseline it's a
small data set right it's fast 4 seconds
first iteration dropped to.3 seconds
second iteration dropped to.1 seconds
and that's where I stopped the whole
process because I can't take it anymore
right so this made me feel two things
one is I spent six years of my life
trying to figure out how to build tools
to do this and Now you know an openw
weight model can do this in 5 minutes.
Very bad. Um the other thing I felt was
you know zooming out a little bit. This
is what I set out set out to do
originally and you know we kind of got
there. That's cool and fun.
That's it for the motivation. So, um,
this talk is called Two and a Half
Wolves, and it's because of this thing.
There's a, if you don't know it, it's a
wall of text. I promise this is the only
big text slide. Don't have to read it.
I'm going to tell you. If you don't know
this, there's a folk wisdom tale, Source
Unknown, about a kid asking his grandpa
um about the struggle within people,
right? So the grandpa responds, "There
are two wolves inside of me. One
represents everything that is good, the
other everything that is bad." And
they're constantly at war. And the kid
asks, "Okay, but which wolf will win?"
And the grandpa sagely responds, "The
one you feed."
So news flash, there are two and a half
wolves inside of you. And today I'm
going to talk about these two and a half
wolves, who they are, what they feed on,
and how we can keep them in check. The
first wolf, the builder wolf,
it loves building. It just builds
anything. It'll build a house. It'll
build a SAS product. It'll build a
whatever, right? It doesn't care how.
It just builds. It gets high from
It just builds. It gets high from building.
Some evidence of the builder wolf in
action. This is from GitHub Octoverse
um last 10 years of
number of GitHub developers.
So you can see this knee in 2023 when
things started going north. Um
and this is just around the time that
Agentic coding tools started getting a
little bit more usable. Right? So in the
end last year, this is the last data
point. It was 180 million developers on
GitHub. GitHub got hugged to death. They
had to look for infrastructure
elsewhere. We brought down GitHub
because the builder wolf is a dopamine
because the builder wolf is a dopamine junkie,
right? It feeds on instant gratification
from having built something and released
it into the public. No matter what it
is, no matter the value.
Another story of the builder wolf. I'm
sure you're all familiar with this.
Someone in this last wave of craziness
of reverse engineering stuff went and
reverse engineered the very popular
creative suite. Um, so Photocraft is one
of the tools, right? They're all
rewritten in Rust, of course. What else?
Um, and it's very popular or it was very
popular for the whole of 3 days, right?
The internet hype cycle. Um, what I want
to outline on this slide is the number
of issues, right? So, if you if you read
any accounts of the people who actually
tried using this, there's a lot of rough
edges. I'm not I'm not saying they're
not going to fix it, but there's a lot
of rough edges and it was released
of rough edges and it was released somewhere.
So, be careful with the builder wolf,
right? The builder wolf builds, it
doesn't care what
your hobby project backlog is now empty
for the first time, right? There's no
backlog. It eats tokens for lunch and it
probably has a substack.
Uh, where does it feed? It feeds on
vtags. V tags for those less technical
are tags you typically use to mark
releases on GitHub, right? So, ship it
on LinkedIn. Um, it also feeds on
running the same old prompt on the four
newest models to produce a 3D rendered
scene. Oh my god. Wow. Um, right.
Because you built this somehow.
Max is operational word somehow. Um, it
also uh feeds on building while you do
other stuff because it doesn't care
about the process. It only cares about
that dopamine hit that you get at the
end. Things to look out for. Abandon
wear, right? If you're not familiar with
the term, it's stuff that gets released
and never looked at again, right?
There's a lot of that going around.
It doesn't care about quality. So all of
the tests are kind of going to be
tautologies, right? One equals one.
That's my test. It passes. Yay, release.
And also those hundreds of commits that
you did over the weekend, you're not
going to review them. That's the truth.
Right? So that's the builder wolf,
right? And before we go on,
we have a short intermission
because I need to talk to you about
programming as part of your identity.
A lot of software engineers conflate
their value with producing code.
This historically makes sense. If you
look at uh earning data, next slide.
Sorry. Sorry, Wilson. Uh if you look at
uh this is US census data on incomes,
software developers historically were
very well paid for
what essentially is emitting code into
something, right? So when someone comes
in and tells you coding is solved, you
are bound to take it very personally,
right? if you self-identify as a code
production engine.
But I think this is wrong. Right. So,
we're going to play a little game. Okay,
everyone ready? I want participation.
What is this wolf paid to do?
Drive the bus.
Drive the bus. Excellent. Except it's
wrong. This wolf is
taking workers to uh
taking workers to uh production.
Correct. I would say taking people from
point A to point B. Right, you got it.
This wolf,
it doesn't put out fire. Firefighters
sometimes actually set fires. Um, if you
have a large wildfire, u there's this
thing where they will burn a ring around
it to consume its f fuel. So I would say
that firefighters are paid to prevent
fire related damage to persons, nature
and property. I would prefer it in that
order. Um what is this we'll get paid to
order. Um what is this we'll get paid to do?
It's a trick question.
Right. Right. Code but only not right.
It solves business problems.
Right? We get paid for the outcome, not
the verb. Right? It's never the verb. If
I have a company and I need to hire
software engineers, I'm not going to
hire them because I love seeing code
appear out of thin air and that's kind
of my kink. I'm going to hire them to
solve the problem that my company set
off to solve through writing software.
Sure, that's fine. But the outcome is
going to be problem solved. So we've
seen the builder wolf. We did this
little game. And now the cra the crafts
little game. And now the cra the crafts wolf.
Uh so the craft wolf is a very proud
animal. It um strives for engineering
perfection. It loves, you know, staying
up late and debugging stuff. I guess
I would argue um that we still need the
crafts wolf. And I'm going to give you a
very contrived, very funny um anecdote.
So recently it was my wife's birthday
and I wanted to make her a cake. So I
took Claude Sonnet uh the the new one.
Um and I asked it I gave it the recipe
and I wanted a shopping list, right? I
told it what I have in the fridge.
Generate me a shopping list. So Claude
in its infinite wisdom, right? This is
new state-of-the-art models. It told me
that six egg whites, one egg yolk, five
more egg yolks,
um, comes up to 6 + 6 equals 11.
So me being the, you know, professional
at counting eggs, I was like, wait a
second, that's not right. And then claw
was like like f fair, right? It
corrected itself. We got to the correct
number. I didn't over buy on eggs. Don't
worry. Um,
this is funny and unrelated except if
you exchange the making of a cake with
creating software that handles people's
credit card information,
right? So, you want your equivalent of
an egg counting expert to always be
there and slap the thing when it goes
sideways, right?
But what does the craftswolf really
crave? I would say that the craftsswolf
does not crave
uh producing code. Producing code was a
challenge in the past. And that's what
us software engineers really love. We
love challenges. We love solving complex
love challenges. We love solving complex problems.
When agentic coding started, we had this
period where models were kind of crappy.
harnesses were almost non non-existent,
right? And then the game was prompt
engineering, right? Everyone's a prompt
engineer. So there in that brief period
of time,
sorry. Um, you actually got improvement
from learning a skill, right? You
prompted one way, it fails
spectacularly, and then you learn, you
get better, and then you improve. You
improve the output, you learn something
along the way. And it was fun and
rewarding except there was this one
point in time. I'm sure you all know uh
where AI models just got scary good at
stuff um and it became less important to
write a good prompt um to get a decent
outcome especially for kind of general
purpose code. At that point crafts wolf
was completely checked out right I'm out
of here. I don't care. So we need to
keep some level of human expertise
in agentic coding. Right? This chart
shows four quadrants. Uh comparing human
knowledge uh against AI capability. Not
comparing but just kind of seeing the
comparing but just kind of seeing the interactions.
If human knowledge is low, no matter how
capable your AI is, you don't know
what's happening. you don't know if what
it's building is good or if it's
absolute crap that's going to catch fire
tomorrow. However, if your expertise is
tomorrow. However, if your expertise is high,
low capability AI is going to slow you
down a bit. You're going to have to push
back, right, in your reviews.
A highly capable AI is, you know, you're
not going to have to correct it that
much, right? You're still going to have
to review, but it's that's a decent
combo, right? So we need to preserve a
certain level of domain expertise in our
certain level of domain expertise in our work.
How do we get high expertise?
Well, right, first we're a junior, then
we're just uh then we're a senior, and
then we're, you know, the top of the
pantheon, the gods of software
engineering, right?
The interesting thing that happens on
this pyramid is as you go up, your
knowledge goes up. Your leadership
skills typically need to go up because
you're going to start mentoring others,
right? But also, the amount of code you
put into production is likely to go
down. This is not a rule. It doesn't
happen always. This is typically what
you see, right? because you're moving on
to more strategic stuff into more
steering the project setting the
steering the project setting the foundations
and this is great this is what all
software engineers uh aspire to become
or not all right
so how does this look on projects in a
brownfield project which is something
we're already operating the juniors go
and fix the bugs right to get good uh
the middle levels
probably implement the new features and
then the most senior levels own the
then the most senior levels own the architecture.
Greenfield senior staff levels usually
set the architecture for a new project,
right? They set everything up so it can
be handed over then they hand it over
and then they walk away, right? They
move on to the next project or into a
more advisory role.
What happens when you drop AI coding in
What happens when you drop AI coding in there?
That might go away, right? The parts
where we're actually producing code, I'm
not saying it's going to go away, right?
I'm nobody has this uh Oracle power of
extrapolation to tell you what's going
to happen in 3 months anymore. Right?
Four years ago, we didn't have chat GPT.
Today, we have software factories.
That's crazy, right? So, I don't know.
But if that goes away,
the big game becomes owning the
architecture, right? Owning the system
design, understanding how everything
fits and making sure that this can scale
through infinite code production, right?
That the code production can remain good
throughout the project.
Why this is bad is now our bottom layers
of the pyramid are looking hella shaky,
right? So if you don't have juniors
today or you have no need for juniors or
no bugs to you know chase around and get
good in five years we're you know going
to have fewer seniors and and above
so how do we strengthen this right I put
this into two categories one is
individual work one is community work on
the individual level you can force
yourself to do a certain amount of
handcrafted artal code. Nobody's going
to do this, right? Some people are going
to do it, but they are a very small
to do it, but they are a very small minority.
You can read textbooks. I
I love reading textbooks. Every couple
of years, I go back and take one of the
university textbooks that I read, right?
Go into operating system design or
computer architecture, reread it, and
you figure out you had blind spots. you
learn a thing or two a new these are
very well structured for learning intake
right so textbooks are great
use LLMs for interactive learning right
so as a sparring partner to learn new
tech they are good retrieval engines for
most information and you can actually
have a conversation and go in a
direction that you prefer which is very
direction that you prefer which is very nice
and then most importantly This one we
can and must strive to do find
engineering challenges beyond producing
code. Not everything is solved. You
cannot dump all the problems into cloud
code and right it's miraculously done
right. So find right build I don't know
build software factories build
infrastructure factories build uh figure
out how to make agents not screw up I
don't know these are engineering
challenges right pick something that is
not really solved yet and try to
actually get in there and learn
on the community level mentor more
junior people I think juniors these days
are scared I spoke to some master
students from LMU recently and I asked
them like so what's going to happen
after masters and they're like we don't
after masters and they're like we don't know
it's it's very scary to be a junior
today um have discussions about software
and not just this got released look at
it uh but actually discussions about
what software is right how does software
work computer go fast
uh bring back staring at the screen
together. Pair programming was a great
tool to have uh two sets of opinions
challenging each other. Right? We can
keep this. We can build stuff and talk
to each other and build it together real
time. Maintains human touch and also
provides you a sparring partner that's
not clawed. Um finally, most
importantly, be nice to each other,
right? So, we're still a community.
We're still right. Software engineering
We're still right. Software engineering is
it's a it's a community I guess the best
word. Um being crappy to each other
doesn't help anyone, right? Be nice to
each other. Um so the crafts wolf,
back to the funny stuff. Um it's a proud
animal. Uh it thrives through learning
and challenges.
Where does it feed? It feeds on coffee
primarily. uh it feeds on learning new
stuff, right? So, attacking new
challenges, growing and making wonderful
feats of engineering. Things to look out
for with the crafts wolf. It can be a
little bit paranoid, right? Um sometimes
justifiably so. Sometimes it can be a
little um nearsighted and not see the
forest from the trees, right? Some
problems today seem catastrophic. I
think we need to zoom out and try to
right map out our trade all over again
because it's changing. It's prone to
bouts of nostalgia. Uh nostalgia is
great sometimes in small doses. Avoid
getting into rabbit holes.
So, going back to the wolf story, um,
there's a better version of this that I
prefer, and it only changes this one
line that says the one you feed. Right.
So, which wolf wins,
they both do if you feed them, right?
Right. So, apply that to the builder and
the crafts wolf. And it says both, but I
still owe you half a wolf. Right. Are
you ready?
Look at it. So cute. It's the cub. Uh
the cub is the new kid on the block in
software engineering. It sits on the
sidelines for now and judges, right? It
tells the other two, "Hey, uh maybe
that's really a stupid thing to build.
Let's not do that." How does it decide
what to build right now? Or at first it
decides on pure instinct. Us as software
decides on pure instinct. Us as software engineers,
we do not have this instinct honed yet.
We need to grow it, right? So some
things you can do on personal projects
to decide whether to build it or not is
ask yourself, is it fun?
Am I learning something new, Craftswolf?
Am I solving a problem for myself or
someone else?
Can I write a LinkedIn post about it?
This is sometimes a good piece of um
advice. Um maybe soon, right, once the
AI labs decide to stop footing 95% of
your coding bill, maybe token costs
become a a piece of criteria for
building. And finally, should I spend
this time with family and friends? For
me, the answer is almost always yes. Um,
that's non-commercial projects. In
commercial projects, I
lately have been talking to product
people, some of them here in the
audience. Um, and I really like what the
product community has kind of figured
out as the main north star in whether
you should do something or not.
Can I sell it?
Right? And this is not asking your
relative, hey, would you use this app?
Or asking someone, would you buy this
app? No. Get a letter of intent, right?
Get ink on paper that someone's willing
to pay money for what you want to build
and then it's justified.
So, the cub decides what not to build,
right? It focuses on ROI. Um, it chooses
where it spends time.
It feeds on failure.
It feeds on your failure and other
people's failure. Um by mapping out the
negative space and then learning what's
remaining, right? So you need to map out
what is failing out there or what failed
for me and then not do that, right? It
feeds on disillusionment, right?
Sometimes you have this amazing idea for
an app and then you go all in. You build
stuff um and then reality slaps you and
nobody wants it. Right? So disisconfirm
your beliefs. Go out there early. Test
it, right? Test the idea with people. It
feeds also on delighting users. This is
as a good product manager, right? Things
to look out for. It's still very small.
We're software engineers. because we're
not product people. They're better at
this than we are. Um, but we need to
feed it, right? Be careful because the
the little one will sometimes steal food
from the crafts wolf, right? And
sometimes the return on investment
doesn't have to be material. Sometimes
learning is a good enough return on
investment, right? So sometimes it's
fine to build it if no one buys it or
uses it as long as you learn something
uses it as long as you learn something new.
In a normal pro product life cycle,
right, they map almost um too cleanly
onto product ideation where the cub
leads, right? Decides what to build. Uh
the soft launch or pilot where you go
and like vibe, slop whatever and start
bringing it in front of people. And then
for production, you actually need to
bring in the big guns. This is where our
old skills as software engineers pay
off, right? And we need to feed all of
off, right? And we need to feed all of them.
Takeaway. We're nearing the end. So
where do we go from here? The future is
where do we go from here? The future is polymatic.
Polymats are people who are expert at
multiple things, right? You've heard the
terms renaissance engineer or product
terms renaissance engineer or product engineer.
I think this is a direction where we're
going because coding is,
you know,
not going to cut. It's not dead,
but it's not the only thing we're going
to have to do in the future, right?
We're going to have to find more
engineering challenges.
Understand your specific wolves. You
don't have to use my stupid wolf
analogy. I don't care. But the concepts,
map them onto how you operate, right?
Are you burning tokens on the weekend
for nothing or are you actually spending
time learning something, getting better,
and understanding more of the world?
Feed them accordingly. Right? If the
crafts wolf is starving, do something
that feeds it. Right?
Find your new challenges. Learn and
adapt. This field
is changing so quickly. It was
accelerating for a while while right
before AI. I've been around software
engineering for a minute. Um, and I
don't think anyone's seen this so far,
right? And the final one that I'm going
to steal from late George Carlin from
Bill and Ted's Excellent Adventure. Uh,
be excellent to each other, right? We
are a community. We need to figure out
the direction in which the community
needs to go in into the future and
define what the future holds for
software engineering. Right? So this is
a group effort. Talk to people. Discuss
how you do things. Don't be selfish.
Right? Um we're all in this together.
And that is not everything I had. You
can scan this. This is my landing page.
Um, I have like five more slides, but I
think we're out of time and I
deliberately cut it here. Uh, but I'm
happy to talk to you about the five
other slides offline.
+ Read More
Watch More
A Survey of Production RAG Pain Points and Solutions
Posted Feb 28, 2024 | Views 2.7K
# LLMs
# RAG
# LlamaIndex
Two Tools to get you 90% Operational ML, The Future of ML and Data Platforms
Posted Feb 03, 2021 | Views 828
# Tecton.ai
# Azure.microsoft.com
# Cleric.io
Going Beyond Two Tier Data Architectures with DuckDB // Hannes Mühleisen // DE4AI
Posted Sep 18, 2024 | Views 727