[Music]
Good morning everybody and welcome back
to PyCon AU 2025.
Excited to see you all here. Now, it is
my great pleasure to introduce our first
speaker of the day in this room, uh, a
friend, uh, Derek Bingham, who is going
to be speaking to us on the continued
developer evolution. A big round of
applause, please.
Thank you, Jack. Thank you. Thank you,
everybody. Too kind. So, I'm going to
start this talk with an image. Um, and
I'll explain the image at the end of the
talk. You can have a look at it. You can
draw some insights. Uh, and you may have
an idea of where I'm going with this,
but you may be surprised
and he clicks. So my journey started and
this is a very personal journey uh over
the last 12 months by sitting down with
my son who's 12 and building a game
using a coding assistant because I'd
heard a lot about coding assistants and
the term v coding and I really wanted to
get my son into computer science and
learning Python and so we built this
game a cross between Pac-Man and Snake.
He loved it and now he can't get enough
of writing code.
So I being the software engineer of uh
20 odd years and I thought well what
sort of code is this actually creating
and so I used a a prompt and I wanted to
introspect the code and see well how
well is it structured
and so using mermaid and the coding
assistant I got the following class
diagram and at this point I went wow
that is quite It's impressive. Uh I
remember creating class diagrams.
Anybody here actually created a class
diagram from scratch using the UML
modeler? Took a bloody long time. Uh
rational rows I believe is one of the
classics. Um took a long time. 2
minutes. It's pretty good.
And then having seen all this, I went to
where all uh developers go into Reddit
uh developer humor and I saw something
which was quite different than what I
experienced um was a number of uh things
about Vibe coding which weren't exactly
um
as interesting as I they were
interesting and funny but uh not what I
had experienced. And then digging a
little bit deeper, I came across some
articles around how um some people have
had not had a very nice day uh vibe
coding. Um
I I especially like this one. Uh Paul's
actually from Perth where I'm from. Uh
and um but boy was it beautiful. And I I
could absolutely uh understand that.
And so I then dug a little bit deeper
into this vibe coding thing and I came
across this gem. I don't know if you've
seen this vibe coding very inefficient
but entertaining. Has anybody seen this?
Lionus Torvald gold. Absolute gold. So
Lionus is someone I respect deeply. And
so again, I um I I was um I got more of
a an idea uh of how software
practitioners like myself were viewing
uh this thing called vibe coding.
And then I talked to a lot of developers
in my career as a developer advocate. Uh
and I'm hearing a lot of this uh from
junior developers, early career
developers, people coming out of
university, they're going, Derek, what
what does my career like look like? Is
there even a job for junior developers
anymore? And this concerned me even
more. Um so
we're at a crossroads.
Are we going to think about taking the
blue pill and continuing down the vibe
vibe coding path or are we going to
ignore it completely and continue in our
own way of creating code? And so this is
the journey that I've just been on
and this is the talk that I've built to
describe it. So my name is Derek. I'm a
developer advocate at AWS. I've been
writing code for more than two decades.
Um, and I've built a lot of
applications. I've had a lot of fun in
this career. And I want to explain to
you how I see it evolving because it is
evolving. There's nowhere to hide.
Things are changing. You can build a
snake game in two minutes. You know,
things are changing.
So, I started uh like most of us of my
generation reading this book about
software craftsmanship. when I uh
graduated and started building
applications, it was all about craft
craftsmanship. Coding is a craft and I
firmly believe that still it is about
building something that works that when
you put it into the hands of the your
paying customers, it works. And if you
want to change it, you can change it
pretty easily based on the features that
they want. It is a craft. I still
believe that.
But when I started the craft was more
around
creating uh code in vi. So this I was
started off as a Java programmer. Java
1.1 believe it or not. And this is how I
coded in vi
painful. When I look at that now, I
recorded this uh yesterday or the day
before and uh I couldn't believe how
much it it hurt just to do a static main
entry point to a Java program.
It took it took actually uh I timed as
well two two minutes and then once we've
coded it I then I had to compile it if
we were using compiler language and then
we had to run it
and imagine building a software system
like that
takes time yes there's a craft involved
but the craft is sometimes caught in the
detail of the code
and then after getting out of vi um I
still use vi actually we got into
evolved into ideides and it became a lot
easier because we didn't have to switch
contexts you know we were in the editor
we could compile it we could run it
inside the IDE saved us a bit of time we
could concentrate bit more on our craft
and then through my career it did not
start in the 70s just to point that out
um but I have wrote cobalt um and
throughout my career I have done a lot
of these uh languages I've written and
working software with quite a lot which
scares me when I put this slide
together. Um, and now we're in the next
evolution and this is this is what I'm
seeing is I haven't actually written
anything in code uh for 12 months. I've
been writing everything in prompts which
is is quite an evolution for me and
quite confronting. And so this was the
prompt I used with my son to create the
Pac-Man game. Uh, so if you don't know,
Nibbles is the name of Snake.
Yeah. Um, and so this is actually the
the one and only prompt I we wrote um to
get the basics of the game. We had to
fix up some of the game play with a
number of prompts, different prompts,
but that's just the nature of what we
did.
And so,
as I said, it's time to investigate this
thing. it's time to see what it would
take to create a crafted piece of
software using these agents. And so
that's what I started to investigate.
And so over a number of months, I've
started to use different AI agents in
coding assistants and I've came up with
a way that works for me. And what
actually works for me might be different
from you. So the best way to demonstrate
that is through a little flash demo I
put together. So it's a very simple CRUD
slask application that you log in, you
create an element. Uh but the one thing
I want to focus on is there is a missing
feature. So I put this like we would in
the real world. We put this in front of
our customer and the customer after a
day goes it's rubbish. I want this
feature that you've never thought about.
And in this case, I'm going to talk
about the delete feature because I have
an app. I can create stuff, but I can't
delete stuff. So that's the feature
that's missing.
And so the first powerful thing that I
found with these AI coding assistants is
introspection.
So if I had been given this application
uh and told Derek, "This is the
application. Go fix it." I'm like,
"What's Flask?" I'd be googling Flask.
I'd be going uh trying to work out what
Flask is. But the within the assistant,
you stay inside the IDE. So no context
switching,
it speeds things up. I'm faster. Um
also, if you look inside the well
doumented Flask app that's created with
zero documents, zero uh docs, you can
actually document it as well. And the
assistants are pretty good at doing this
as well. Uh so here I'm I'm actually
doing an introspect at a a function
level and so it'll tell you what the
function does and at every line that's
that's handy as well. A if you've never
used Flask before, B if you're um early
creators developer who doesn't know
Python,
this will tell you exactly what this
function is doing. Super handy.
And then finally adding docs because
docs are good uh really good at doing
that. So I found this super helpful.
And then the next bit that I found
helpful is adding features. And so this
is where the agentic functionality of
these coding assistants comes in where
you can define
um the details of a feature that you
want to add to an application. And so
this I'm in my prompt land again.
Add a new method to remove an item.
Update HTML and code.
And even the SQL query uh in the
persistence layer. And so the agentic
flow will some agents if you let them
will do it for you all in one step. I
like verifying um call me oldfashioned
but uh I like verifying what they're
trying to do, what they're planning to
do. And so I let this agent go. It it it
it um tells me that it's reviewing um
number of files. This is uh Amazon Q
developer inside um Visual Studio Code
as a plug-in.
And so as it goes through works out what
it wants to do, tells me what what files
it wants to change. I then have control
over what I I am happy with it doing. So
a lot of the feedback that we're seeing
uh and I showed earlier where the agents
are getting into an infinite loop and
really create really uh doing not very
much uh not very quickly we can control
and I think control is important and so
as the um the file changes are um put
through by the agent I can approve and
deny as as I would uh any code review
and then of course like any good
developer I test my change which I
didn't write any code for but I did
build it I think And I think that's key.
I'm still crafting this application.
Uh I test it and the delete
functionality is there. So that's that's
how I'm starting to evolve my uh
working.
So let's try and address the gap between
what we're being sold the I'm hearing
lots of quotes that they will take over
the world, developers are dead, the end
is now, and what the reality actually
is. And I think that needs to be clearly
um defined.
And so I'm hearing three key things. The
first one is AI will replace developers.
Now if the example I showed you
previously, you'll notice that I knew
exactly how to prompt that tool. If you
put that tool in the hands of someone
who did not have a level of experience
that I had, you would get a very
different result. It would not be as
efficient. Uh you would not get to
production as quickly. AI will not
replace developers. It is a tool for
developers. This is nonsense. And if I
could swear, I would. I feel very
strongly about this.
But I also hear the the flip on this AI
code generated is inferior. Now again
that is nuanced, incredibly nuanced. Um
the code that it generates
can be inferior if it's not supplied the
right context in the right knowledge
about the application that it's updating
or building.
So it can in fact generate inferior
code. But the person who is the
developer or the engineer who is telling
it what to do is the one who dictates
how good that code is.
And then finally the saddest part. Uh
learning to code is pointless. This
makes me incredibly sad. Um learning to
code is absolutely not pointless. The
only reason that this application works
that I showed you in the demo is I
looked at all the changes the AI told me
that it was going to make and I verified
them. I was able to verify them because
I know how to code.
Yes, I could use the AI to introspect.
Excuse me.
I I could use the AI to introspect code
and understand the code and that would
give me a level of knowledge, but I
still need to know how to code. I need
to know how to compose an application. I
need to know about how if this
application was talking to an API that
was remote, best ways to res to make
that resilient, best ways to do backoff
retry. I need to know this information.
Yes, the AI can teach me this
information if I don't know it, but I
need to know at some stage.
And what I'm saying is controversial. Uh
I hope it's not. I think this will be
the way we go forward is more AI
actually equals more developers
because
of a thing that happened many years ago.
So this is called the Jevans paradox.
Has anybody heard of the Jevans paradox?
Yes, my friend. Too magnificent. So the
Jevans paradox comes from the industrial
revolution where something happened.
Well, lots of things happened, but one
key thing happened. This is a steam
engine. And steam engines are very
efficient at making power from coal. And
when they f were first created,
um,
the industry as a whole was like, well,
as these steam engines are more
efficient in power powering things, I'm
from Ireland, so my W's are quite hard
to say, powering uh things, then we need
less coal. What happened was quite the
opposite.
uh the industry demanded more steam,
more power. They needed more steam
engines. And so what did what happened?
Demand for coal went up.
And so the same thing will happen for
developers and engineers. What these
coding assistants and jai are creating
is efficiencies. So we can get things to
market quicker.
Erggo, the demand for our skills will go
up.
But it's on us to evolve.
And how can we evolve?
Well, first of all, there are problems
that have not been solved. There are new
terms and skills that you must learn.
I'll highlight a few. There are many.
The first one is a term that I've I've
coined called token theft. So if you
give an AI assistant ultimate uh perfect
context, perfect knowledge about the
application you're building and a
perfect prompt to do what you wanted to
do, it can still hallucinate. It can
still give you nonsense, it can still be
wrong. But what's it done by doing that?
It is stolen your tokens because all
these AI assistants need and work on and
and cost models are on per token. So
it's stolen your token. How do we fix
that? That is something that has not
been solved.
Checkpointing.
These AI systems write code really fast.
Really, really fast. You need to slow
down. You need to checkpoint. You need
to say prompt. What's it created?
Verify. Okay, let's go. Checkpoint here.
So many people I've talked to don't know
how to use Git, but they're they're vibe
coding their hearts out. Good luck to
them.
Checkpointing very key. And then things
like pair programming. These are
fundamental software development
practices.
They can be used in this context and be
used very very well. Pair programming
one. Somebody writes the code, somebody
writes the tests. In AI land, get a
model to generate the code if if you
need it, get a different model to
generate the tests,
verify,
and there are many others that will come
along come up as we go down this
evolution.
One of them that has just been released
is spectriven. So spec driven
development is something that has come
up in the last couple of months and it's
all about giving
um structure to this chaos the chaos
that I'll I'll call vibe coding. Uh and
what it does is at its heart is that
implementation bit. So prompting,
getting the output that you want from
the from the assistant and then
verifying,
but up front you're giving it better
context, better understanding of what
you're trying to build. You're helping
it. And that's where the specifications
come in, more information about the
application that you're building. That
then feeds into what the um the the AI
assistant is generating. And then of
course we test everything. So we then go
through that test cycle and before
finally deploying structure around the
vibe coding chaos
and that's the bit that's called spec
driven. Now if anybody's like me and has
written software for a long time this is
waterfall development 101. Hooray. Um
and then into maintenance. So waterfall
is a very old way of uh building
software and it's now come back again.
Now this will evolve as well. We'll get
the V model. We'll get um high um
iterative uh techniques as well. But
this is where we're currently starting
with these um AI assistants. And the the
tool that I'm using to do that is Kira
uh that we've released about six months
ago.
But there's other tools, right? I'm not
here to talk to you about what tools are
good for you. I want you to find out
because every engineer and developer in
this room needs to evolve and it's your
personal evolution. I've went through
mine. It's time for you to go through
yours. So, assistants, I've used Kira
and I've used QD in these um demos.
There's also client, excellent
assistant, and cursor and many, many
more. I can't talk about the rest. I've
just used those.
There's a link there to Kira, but also
to give these a these agents are
actually built on agent frameworks. It's
really interesting and you should
understand what these agentic frameworks
are and build one yourself. Gives you a
great insight into what these coding
assistants are doing and even how you
can change them. So two that I've I've
used uh are both Python uh strands and
pedantic AI worth looking at and there's
a link there to strands and then finally
how to extend these agents how to um
make them work for your use case and
currently there's two ways you can do
that. There's actually three but two
that I've used MCP and A2A.
And if you're curious about how to use
strands and MCP together, I'm giving a
workshop on Monday and we're going to
build something with those two
frameworks.
So what is my key takeaways from today's
talk? If you've listened to nothing else
uh than my Irish accent is humans are
important. Craftsmen are still valid and
a AI agent cannot craft. We craft. We
are important.
And this is a quote from a very large
aentic AI CEO.
Uh with AI
he hears that with AI we can replace all
of our junior people in our company. I
was like that's one of the dumbest
things I've ever heard. And I actually
agree with this quote. And I was
surprised that this came from Matt
Garmin, who is the CEO of AWS. That is a
fact.
So, back to our car.
My first ever job, I worked for a very
large airline, and there were people
driving in in sports cars, really fancy
sports cars, and the number plate was
Cobalt One. I was like, "Who are these
people?" I just started. Who are these
people? and they're like, "Derek, these
are the cobalt programmers.
They are fixing up all the legacy Cobalt
code um that the company has created.
They're also and I'm saying, well, poor
them. Uh they don't know how to use
Java." And and I was told in no
uncertain terms, yes, they do. They just
make more money fixing cobalt, hence the
cars. So the number plate is important.
There will always be work for developers
and engineers in future. Maybe fixing up
all the vibe coding mistakes that people
thought that was a good idea at the
time. Maybe when the first feature drops
from their customers and they have no
idea what that vibing has created.
Now go build. Thank you.
Thank you very much, Derek.
Thank you.
Here is your mug.
Thank you so much for your time. Uh, we
have a few minutes for questions, uh, if
people would like to ask them. Um, I'm
going to grab the roaming mic and come
and chase you all. Uh, we've got one up
the front here and another one up the
front there. Go for that one first.
Thanks for the talk, Derek. Great talk.
Pleasure.
Um, I'm involved with behavior-driven
design testing, building a hold of tests
for 3D CAD programs. And to me, the
challenge, if all this vibe coding goes
ahead and goes really well, we still
need what we can do as humans to put
together those corner cases and things.
How can AI come up with really good
tests as short the smallest set of
really good tests especially to catch
those corner cases?
Yeah, 100%. So I I have been thinking
about BDD intensely uh over my 12-month
journey because that is the answer right
we have not we've had have not I don't
know the answer to your question first
of all uh but there is absolute avenue
for BDD to have a strong influence in
where we go with this I absolutely
agree um yes it is a just like the
waterfall techniques BDD and and prayer
programming
BDD and those techniques that we've
learned over years that work that that
make sure our our software works we need
to harness uh in the AI domain as well.
Yeah.
Hi Derek. Thanks for your talk.
Pleasure.
Um I noticed that in your VI coding
coding example you didn't commit your
code before letting the AI edit it. I'm
always scared of the AI deleting stuff,
so I always commit before. But um then
you addressed it later in the slides,
right? Like Git's really important.
Yes.
Um
I think I wanted to ask Yeah. Do you
think we might need something even
better than Git? Something that's
tailored so that the AI can actually
read it without spending a ton of tokens
reading your entire Git history.
Something that's optimized. Yes.
So they can do that better. And um
also so you can see the commits that are
from the AI and the commits that have
been the bits of the code that have been
read by humans and edited by humans and
yes 100%. So I had a good discussion in
Seattle about this very thing a couple
of weeks ago. Uh that's why I termed it
checkpointing and not committing and git
using git specifically. I think the
evolution of how we do that is not a
simple git commit. it is more complex
than that and more subtle and more
nuanced. Um, and so that will evolve.
That slide was all about we haven't we
haven't got a a fix for them or we don't
know how to do it yet. And checkpointing
is one of them.
Thanks.
Thanks so much Derek. Excellent talk.
Um, we started at a point where we had
software craftsmanship.
Now we have vibe coding that is creating
code at the speed of tokens.
Yes. Nice.
How does it change us as developers, as
engineers, as creators of things that
are more disposable, more throwable away
and further away from a craft?
I disagree. So that was the whole intent
of this talk was to to highlight that
we're not disposable. Um, we are still
crafts people. We still understand
um what we're trying to do. We
understand
how we're trying to get where we're
getting, right? We have insights. We
have knowledge. Um, we we can build
things. An AI assistant just does what
we tell it. It's a n it's a nick word
prediction algorithm, right? That is not
a creation algorithm. You know, you look
at the AI slop that's out there. Code is
no different. An artist or and a creator
can use the tools that are there to be
more efficient, but ultimately
still you still need us in the loop.
Uh I think we'll we'll leave it there.
We've got about a minute, but I don't
think it's going to be enough time for
another question. So, thank you so much,
Derek, for your time. Are you going to
be around for the rest of the
conference? So I'll I'll be at the AWS
stand all day and tomorrow and the
workshop on Monday. So come have a chat
and uh love to talk to tough about
software development techniques p
practices. Love it. Love those
conversations.
Thanks very much Derek. One more big
round of applause.