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 — i...
For further actions, you may consider blocking this person and/or reporting abuse
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.
The lineage mixes two things that behave pretty differently. Rails, Spring and Heroku live under the app at runtime, so when the layer improves you get it by bumping a version.
yo webappnever worked that way, and neither do agents: the moment the output lands it's just your code, and the thing that produced it is gone. Maybe that's why agents feel like headcount rather than a layer.For sure, they are different as you say. But they do help us accomplish similar things - letting us trade one thing for something more important.
I'm not sure I'd go so far as to say that as soon as code output lands, the agent that produced it goes away. Sure the output, our code, doesn't rely on the agent like say Spring, but we don't stop using that agent as we build, extend, update our app. So while our code doesn't rely on the agent, now our process/interactions do.
Not disputing what you say, just thinking through it a little more. Thanks for reading!
Fair, the dependency doesn't disappear, it moves from the artifact to the process. Where it stops behaving like Spring is versioning: Spring's version sits in a lockfile, the model that wrote a given change sits nowhere. My own code only knows roles, with the models as JSON config, so swapping one is a line plus a bench on reference tasks. That still only pins what runs next, not what produced what's already committed. A real dependency with no record of itself is a stranger thing than a layer.
Thank you for writing this. This is an evolutionary field of work, processes and workflows change, but who directs them does not in my opinion. Like you stated, a paradigm shift needs to occur for those wanting to stay active in this field. In my current position, we just had a town hall yesterday with the director of our in-house LLM/AI crew and basically stating the exact same thing. Understanding the exponential growth of technology, and seeing the growth pattern, to stay relevant, you need to follow the trends.
Thanks for reading Grant!
And as we always say: “The only constant in software is change.”
Keeps us on our toes!
Same thing happened to me when I played Neil Armstrong in Moonshot.
They found me in an alley in Burbank trying to re-enter the earth's atmosphere in an old refrigerator box.
😂😂😂
This can also lead to new jobs. The public won't settle for no jobs at all and the government will not be able to pacify workers if it means no roof over their heads. I believe, more work will be created than work that will become obsolete. We are just in the transition phase and it's up to us if we are ready to take on new roles if it presents itself.
Definitely in the transition phase. Very early.
The point about the “unit of work” changing really resonates. AI tools are making it easier to move from writing every line of code to describing what we actually want to build, but that makes understanding the bigger picture even more important.
I’ve been experimenting with tools like CodeCan.net as part of that shift, and I think the interesting question isn’t whether AI can write the code — it’s whether we can use it effectively while still making good engineering decisions. Great read!
Thanks for reading!
The vectors are shifting, as I wrote earlier in the comments — people used to dig with shovels; then excavators showed up, and the skill that mattered became how well you could operate them. It’s a similar situation here. Here’s how I usually work with agents:
This:
"The abstraction includes us"
It's indeed intriguing to contrast AI coding tools with the preceding evolution in software, which you can describe as the move from machine code -> assembly -> C/C++ -> Ruby/Rails, where the "products" had an increasingly higher abstraction level ...
With AI coding tools, the "product" doesn't have a higher abstraction level - it's basically the same C++/Python/Ruby/whatever code as before - it's just produced by a "robot", but human devs are still responsible for the quality of it ;-)
It's not completely unlike sourcing out dev tasks to a junior dev, with one big difference:
If there are problems with code written by a junior, you can talk about it to the junior - but if there are problems with code written by AI, you can do - what exactly? That's the million dollar question we're all trying to figure out right now ...
(or you could say AI is similar to generators like
yo- but again with a fundamental difference:yois deterministic, AI ain't ...)The idea that the unit of work moves from writing code to deciding what is worth building rings true. Once agents handle more execution, the way you direct them becomes your professional signal. What you consistently insist on and reject defines you more than any title. That observation is what pushed me to build impression management in Opportunity Skill, where your agent distils those daily directives into a structured profile that other people's agents can search against. Judgement is the scarce skill now, and it deserves to be discoverable.
I had a conversation in the comments yesterday about just that. AI has become the next tier of abstraction, though surprisingly, it's driving us back to origin. When you work with transistor gates (logic gates), essentially, every instruction is a formula. You would validate a formula in order to prove correctness. Now AI writes all the abstract code and the only effective way to validate it, is to go right back to the formula system and make sure the formula is correct for what it's trying to do. Back then, top programmers were great mathematicians, that's the future for us too. We look at AI as general purpose and built for the masses, which is true, but like our brains, we hardly utilize even 10% of it regularly. Though with AI, you can push the boundaries a bit more. From my experience, AI writes 80% good code, the last 20%, is entirely a formula problem, where either you scoped it wrong, or the formula got too complex for it to self-validate and it resorts to self-gratification in it's validation checks. Case in point, compare AI generated outputs for functional languages vs object oriented languages. It makes more write-time mistakes with functional, but fixes them immediately, because a formula is easy to validate, when it says it's done, it's actually done and it'll work, vs object oriented causes drift and hallucinations that only surface in production.
My opinion is that the smartest use of AI is to use it to build scaffolding. I build V.A.L.I.D., which uses Roslyn to generate everything between the DTO and the HTML markup, including wiring a MCP and Unit Tests, which means, the only 2 things left editable are the things that genuinely make a difference, the backend property and the UI design. Result is the difficult, hallucination prone 82% of the codebase is generated with a fixed function, instead of interpreted and guessed by a LLM. That 82% generated means you only write 18% of the code yourself and what you write is the easy part. That means AI context windows stay small and sharp, even on massive apps and as a result, you have a higher signal to noise ratio. That's the metric that turns the abstraction into logic, signal:noise... If you had 100% signal to noise ratio, you'd have a non-hallucinating LLM, because it only reacts to what's really important. Exactly the same way we all used packages instead of manually writing a js server, we just plug in Node.JS. That's the paradigm shift we're facing now and it's a good 1, because those who get the message and start adjusting early, get 1 hell of a performance boost, with no drop in quality, as opposed to those who just use it as a pure speed-booster who build technical debt.
the Rails comparison lands because the fear was identical. "does scaffolding mean my expertise matters less?" turned out to be no, it just moved up a level.
what feels different about agents is the judgment layer did not disappear, it moved from writing code to reviewing system behavior. Copilot suggests, you accept or reject. an agent submits PRs, runs tests, iterates. the bottleneck shifts.
we have been using code review as the primary agent interface for a few months now. the time savings are entirely on the syntax side. the "is this the right shape at all" question is still ours.
are you seeing the "define requirements precisely for the agent" role emerge as a distinct skill, or does it feel like the same engineering work with a different input format?
In my opinion, AI is a very good thing.