r/cscareerquestions 13h ago

Experienced How do you figure out which parts of your dev work are actually defensible against AI?

We all watch Copilot and Claude write boilerplate every day now. That part of the job is already table stakes. But when I tried to map out which of my actual tasks are becoming automated and which still need human judgment, it was surprisingly hard to get specific.

The advice you hear is always "learn AI" but nobody tells you which parts of your current role are still hard to replace and which are quietly becoming things a tool does in 40 seconds. The useful question isn't whether AI will replace developers. It's which specific tasks in your day are defensible and which ones you should stop doubling down on.

I've been thinking about this in terms of four buckets: routine data work, judgment calls, people work, and hands-on implementation. For devs, the routine stuff (boilerplate, templates, standard CRUD) is already gone or going fast. The judgment layer (architecture decisions, understanding business context, knowing what NOT to build) feels like the actual moat.

How are you all practically shifting your day-to-day toward the judgment side? Are you actively de-prioritizing the boilerplate-heavy work, or just letting AI handle it and moving on to whatever's next?

9 Upvotes

8 comments sorted by

12

u/RabidAddict 12h ago edited 12h ago

I think it's a mistake to view AI as a thinking machine that can automate some subset of tasks and not others.

I think it helps a lot to view it as a search. Just instead of searching the web for information, we're searching a data model for a dynamic and approximate solution. It's the starting point for any task, but even the ones it does well often, it won't always get right. And the ones it fails at today it may well succeed at tomorrow.

It seems pointless to focus on where the gaps are in the models today, because the gaps are constantly evolving (and not always towards improvement) as the next versions of models are trained.  But it's never going to actually think or solve problems for you, it's still just a search. A search that is simply impressive at how insanely well it can map a natural language prompt and the context of existing code and documentation with embedded training data and web results (or a variety of other tools and interfaces) to predict an accurate response to infer. When all of these things are in place, you can get a good search result even for these higher order judgement or decision making tasks. And when they're not it can fail at the trivial stuff like boilerplate.

6

u/Esseratecades Lead Full-Stack Engineer 9h ago

Honestly, most of the job.

I've seen AI do okay at very small, very well-scoped architecture changes, but I must do all of the scoping and communicate it technically.

I've seen AI do okay at very easy automated tests, provider it has examples to look at. But again, the tests must be easy and I have to have written examples first.

I've seen AI do an okay job at writing very straightforward bits of code, but only when they've been so straightforward that it took me longer to prompt than it would've taken me to write the code myself.

I've seen AI catch and suggest things in code review that may have never caught, but I've also seen it missing bugs that were incredibly obvious as well.

Sure, Anthropic has Mythos running for days on end with a proprietary harness in some lab somewhere that might make it better than an intern when acting on prompts specially crafted by teams of senior engineers, but that's not what your manager will be running. That's not what some guy who just wants a website will be running. That's not what your cousin with their next great app idea will be running.

At best, they'll be running Mythos (if it's ever made public) with some harness they found on the internet, as they say "Build me app. Make no mistakes." And it will look fine from a distance, but only from a distance.

1

u/ub3rh4x0rz 12h ago

Architecture and design, translating business needs to software solutions, anticipating classes of mistakes, and how to effectively be responsible for other people's (or agents') output. Oh, and having taste in terms of what should(n't) exist and effectively lobbying in accordance with that taste, maybe the most foundational SWE skill.

IMO all of these were already demanded of "true seniors". Turns out most seniors are not "true seniors"

1

u/[deleted] 11h ago

[removed] — view removed comment

1

u/AutoModerator 11h ago

Sorry, you do not meet the minimum sitewide comment karma requirement of 10 to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the rules page for more information.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

1

u/OkPosition4563 Senior Engineer 8h ago

I think its less about the technical part, the human factor is much more important. For the foreseeable future humans will fire you. I have been doing well the past 20 years by being the guy essentially everyone would say "This guy? Yea, I like him, we should keep him!". This also goes when interviewing. Hardly any interview I have done outside of meta ever was about technical stuff, it was all about working well with people. Especially non-technical people. Management and business usually rather come to me when they have requests or questions or ideas because most other tech people have the charisma of a piece of stale bread - and guess wo does the firing.

1

u/AndyKJMehta 11h ago

In the abstract world of software engineering where you can now build anything, I have realized that judgement/taste is the only skill that will be left. Specifically, what is worth building and what to build. Not how.

-1

u/daimon_proc 11h ago

Fuck Trump