Dear past Jenna,
There will come a point when you wonder whether your career — the one you went to school for (twice) and spent decades honing — is going away. No, it won't be because you can't handle being the only woman (or one of a few) at your company or on your team. No, it won't be because you're too old to do the work. You know it's keeping you young! And no, it won't be because you decided to leave tech.
Instead, it'll be because the craft of software engineering is changing beyond recognition. And that's a super scary thing when so much of your identity is tied up in the work.
When Rails felt like magic
If you recall, we read Ruby for Rails in a book club at work early in our career. We were coming from a legacy enterprise Java world, and Rails introduced us to convention over configuration, code scaffolding, and an MVC architecture that was already wired together. The framework made decisions for us. It encouraged and sometimes enforced its idea of good practice.
It was productive, but more than that, it felt magical. Rails abstracted away complexity I didn't need to think about every time, even though I still needed to understand what it was doing under the covers. The legacy Java environment I worked in didn't have those helpful tools yet.
That magic didn't make me or my work less valuable. The opposite happened. I spent less time bootstrapping projects and wiring basic components together. I was able to focus on solving the harder problems for customers and clients: whether to build something, what to build, and how to build it.
And Rails didn't only make existing engineers faster. Higher-level languages had already enabled people to program without working directly in machine instructions. Rails made web development approachable without requiring every developer to assemble every layer from scratch. The pattern was already there: as lower-level work was packaged up, more people could build software, and experienced developers could attempt more ambitious things.
What abstraction buys us
Now, zoom out a bit. Software has always evolved by putting another layer between us and the machinery underneath. Assembly gave us readable names instead of numeric instructions. Higher-level languages let us describe logic without thinking in CPU operations.
Frameworks like Rails and Spring packaged up common application structures. IDEs and autocomplete took on pieces of manual coding. Generators like yo webapp, ionic start, and eventually create-react-app handled setup and boilerplate. Heroku (hello, my old friend) made infrastructure provisioning easier, especially for my Rails projects.
Every abstraction asked us to stop worrying about one thing so we could worry about something more interesting.
That didn't mean we could forget what was happening underneath. We still needed to understand the layers we depended on, especially when they failed. But we no longer had to carry every detail in our heads for every task. Each abstraction bought back a little mental bandwidth. What would we do with it?
Then tools like GitHub Copilot, Amazon CodeWhisperer, and Amazon Q Developer started generating the code itself. The abstraction was moving closer to the part of the work we had always thought of as programming.
When the tool becomes a collaborator
But AI coding agents feel different from the abstractions that came before them. Those abstractions mostly felt like tools that helped us build software.
Agents feel like collaborators and sometimes competitors. Because they are building the software.
Being able to give an agent a set of GitHub issues and have it work through them hit different. It made the requested changes, tested its work, and iterated until it met the requirements, with minimal babysitting from me.
And that's scary. The abstraction appears to include us.
Whether that's actually happening isn't the point. It's why so many of us are asking: If the computer can do more of what I used to do, where do I fit now? And companies are asking a more unsettling version: If agents can do more of an engineer's work, how many engineers do we still need?
Where the engineering moves
But here's the deal: typing code has always been one part of the work. The goal was to solve problems. As the abstractions changed, the focus moved.
Instead of wiring up XML, we designed systems. Instead of configuring build tools, we built products. Instead of writing boilerplate code, we focused on behavior. Instead of memorizing APIs, we solved customer problems.
What once looked like a shortcut became the new baseline. Few of us would give up autocomplete, frameworks, generators, or the cloud just to prove we could do it the hard way.
If the pattern holds, agents will widen that doorway again. More people will be able to start building software without first understanding every layer underneath. That possibility can feel threatening. But enabling more people to build is also part of how software got here.
And now, we can spend less time writing every line ourselves. The unit of work is changing, too: from completing a line to generating a component to asking an agent to implement a feature. That doesn't eliminate engineering; it changes where the engineering happens.
That shift won't be painless, and it doesn't promise that every engineering job will survive unchanged.
Every generation of engineers has had to redefine what being an engineer means as the tools changed. This time, that may mean seeing ourselves less as programmers who produce code and more as engineers responsible for the systems we build.
All of which brings you back to the question from the first postcard: You can build it. Should you?
Maybe the history of software engineering isn't about writing better code.
Maybe it's the history of moving our attention away from telling computers how to do something and toward deciding what is worth building.
What if we've been preparing for this moment longer than we realize?
Until the next postcard.
I've spent my career helping people build software. This is a series of letters to my past self about what happens when the tools for building change faster than the principles behind building. Each one is a reminder that while the technology changes quickly, the questions that matter often stay the same.
Top comments (1)
The uncomfortable part is that AI does not remove abstraction; it moves it up a layer. Engineers still need to understand the system well enough to judge generated changes, contracts, failure modes, and what the automation is optimizing for.