For decades, it didn't really matter what your title was: programmer, engineer, developer.
Our titles changed, the languages we worked in changed, the
stack definitely changed, but the core of the work stayed the same. We crafted
code. We used code to express our intent. We took problems, broke them down
into explicit logic, and told machines exactly what to do. If it worked, it was
because we got the instructions right. If it didn't, we debugged until it did.
That was the craft.
And it was a craft. It took skill. The kind that comes from
hard-won experience. You could look at a system and see the fingerprints of the
people who built it — their decisions, their trade-offs, their patterns. And
depending on where you work and how far along they are with AI, those days may
already be over, or at least on the way out: the days when an engineer sits
down and writes every line of code by hand.
But crafts evolve. They always have. Hand typesetting gave
way to the printing press. Film photography gave way to digital. Entire
professions, like switchboard operators and draftsmen, were replaced or
reshaped when new technology changed what the work required.
This isn't the first time a craft has shifted out from under
the people practicing it. And it won't be the last. AI is doing that to software
engineering right now. This doesn't make engineers obsolete. The question we
need to ask is: if we're no longer crafting code, what are we crafting now?
If we used to express intent through code, what do we use
now?
We don't have a clean answer yet. But some patterns are
starting to show up. We're still expressing intent, just not through explicit
logic. Instead of writing the exact steps, we're shaping the outcome.
A few of them are starting to look familiar:
- We craft prompts that guide behavior instead of functions that define it
- We assemble context instead of wiring together conditionals
- We explicitly define what good looks like, something we used to handle by intuition
- We curate examples and data instead of encoding every rule
None of these feel as concrete as code. They're softer. That can be uncomfortable, which is normal. The thing you were good at, the thing you built your identity around, starts to shift under your feet. Of course that feels unsettling.
Because what we craft has changed, our tools have changed too.
We used to focus on IDEs, compilers, and build tools. Now we need to know how
to work with prompts, agents, and context, and we need to learn them fast. Not
that long ago, AI skills weren’t even a thing. Being good at the craft still
means knowing how to use the tools well.
But for all of that change, one thing hasn't moved. The
human side of the work is still the same. We're still trying to understand what
someone actually needs. Still translating messy, ambiguous problems into
something a system can work with. Still negotiating trade-offs, aligning with
other people, and making judgment calls about what "good" looks like
in context. That
part of the craft didn't go away. If anything, it matters more now.
We're moving from
crafting instructions to crafting outcomes. Our craft is becoming less about
the code itself, and more about how a system behaves over time. I still read
code. Until I'm no longer the one getting paged at 2 a.m., I'll keep reviewing pull
requests myself.
What does this mean for junior developers?
This is where people get nervous. If the craft is changing,
it's easy to wonder what's left for someone just starting out. But this isn't
the end of fundamentals, and it's not a shortcut past them either.
Understanding how systems work still matters. You need to
know how data flows, where things break, and how to break down a problem. Those
are the skills that keep you grounded.
The risk is skipping understanding. You can build something
that works without knowing why, and that doesn't hold up for long. When it
crashes in production, shrugging and saying "I dunno, the AI wrote it"
is not a defense. The main thing that changed is who wrote the code, not who is
responsible for it, and not who still has to push it safely to production. The
AI may have written the code, may have even committed it,
and even created the pull request. You, the developer, are still responsible
for that code. Too many people shipping code they don't understand may explain
why New Relic's 2026 State of AI Coding report found that AI-generated code tends
to look better in review than it performs in production.
And none of this means teams no longer matter—if anything,
they matter more. You may not need the classic two-pizza team ideal that Amazon
popularized under Jeff Bezos, but junior developers still need a team
around them to learn how good debugging works, how people build healthy
suspicion into the process, and how to develop judgment over time. AI can help
individuals move faster, but software still gets built, operated, and improved
by groups of people with shared context, trust, and good judgment. That lines
up with Google’s Project Aristotle: team effectiveness depends less on who is
on the team than on how the team works together.
The opportunity is to move fast and build understanding at
the same time. Move fast, use the tools, but stay curious. When something
works, ask why. When it fails, dig in. The tools will keep changing. The craft
will keep shifting. The people who grow in it are the ones who learn how to
understand both the system and the behavior it produces.
Automated tests now matter more than ever
That also means automated end-to-end and integration tests
matter more than ever. If AI is helping us produce more code, faster, then
these tests are part of what keeps us from doing something dumb at scale. But
to really have value, they need to be automated and they need to run in the
CI/CD pipeline. If they only run sometimes, or only when someone remembers,
then they are not a safety net, just a nice intention. These tests tell us
whether the system actually works when all the parts are involved, not just
whether one small piece is working correctly. And reviewing those tests matters
more too. If we are depending on them to help us ship safely, then they can't
be treated like boilerplate or an afterthought. They need to be treated like
first-class citizens. Moving forward, in a lot of cases, they matter more than
unit tests. Unit tests aren't going away, but they are not the safety net they
used to be. End-to-end and integration tests are often the thing standing
between "looked fine in the pull request" and "why is production
on fire?"
So, what do we craft now? We still craft software systems.
The main difference now is who writes the code, not who is responsible for it,
and not who pushes it to production. We craft clarity, judgment, and the
understanding that sits between a messy human problem and a system that can act
on it safely. And we still need the things that make that possible: teams that
build shared context and judgment, and tests that tell us whether the system
actually works. The code was never the point. It was just the medium. The
medium changed. The craft didn't. What matters is that you recognize the shift
and keep honing your craft.
I'd love to hear your thoughts. What does the craft look
like for you right now? What's changed, what hasn't?
Further Reading
·
New Relic, 2026 State of AI Coding Report
https://newrelic.com/sites/default/files/2026-06/New-Relic-2026-AI-Code-Report-06-09-2026.pdf
·
DORA, ROI
of AI-assisted Software Development
https://cloud.google.com/resources/content/dora-roi-of-ai-assisted-software-development
·
DORA, 2025 State of AI-assisted Software
Development
https://cloud.google.com/resources/content/2025-dora-ai-assisted-software-development-report
·
Amazon Web Services, Amazon's Two-Pizza Teams
https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/
·
Google re:Work, Understand Team Effectiveness
https://rework.withgoogle.com/intl/en/guides/understand-team-effectiveness
