Comment by fibonachos
8 days ago
My personal experience: writing code has always been the easy part. AI does most of that now.
Understanding the problem and the existing system well enough to design the right solution, even with AI assistance, is a higher cognitive load. I’m doing a lot more of that lately.
I’m more productive, but also more tired. This may be due in part to the breadth of what my team owns, which makes my day a bit more context-switchy than other teams.
As others in this thread have noted, the situation is still evolving. However, I worry less each day about being replaced by AI. There has always been more work than available bandwidth in my experience.
What seems clear to me is that expectations around velocity and throughput will increase (are increasing). AI use will be required to meet those expectations. Learning to use this new tool effectively will be essential for career progression (and preservation).
> My personal experience: writing code has always been the easy part. AI does most of that now.
The only reason dev jobs paid more (by a factor of two or more) than pure solution modeling was because "writing code" was the hard part.
If you wanted to get paid just modeling the solution and handing it off to a coding team, those jobs were available for decades, typically called Business Analysts but few devs moved from dev to BA.
> Understanding the problem and the existing system well enough to design the right solution, even with AI assistance, is a higher cognitive load.
I've found that the act of physically writing refines my understanding a lot more than simply reading.
We don't typically expect a person to read a trigonometry textbook and then perform well on an exam. They have to drill problems to surface their misunderstandings to themselves.
My fear is that, with developers adopting your approach, they're "designing" systems in much the same way that a read-the-book-only trigonometry student solves trigonometry problems.
GP's "design the right solution" is a role between "programmer" and "business analyst" that got merged with "programmer" to become "developer" decades ago. That's where the high salary came from. It's been reemerging as "architect" now that "developer" has been watered down to include "programmer".
thank you for putting into words that which has been hard for me to describe — I’ve noticed the worse a dev was at their job the more high their opinions of AI seem to be. The subject textbook analogy (trig book in your ex.) is a perfect frame of reference for why that might be the case…
to further that example, many people with the help of AI are ostensibly copy pasting trig problems from the book without understanding the mechanics running through them and labouring under the impressions they’ve become closer to skilled mathematicians
other thing could be also true, if you are great developer who spent decade honing their craft (vim, working on hobby projects, grinding when your friends party) you would hold cognitive bias against it as it flips the script. I don't think our profession is going away, but the shift is happening and it's not very comfortable one.
Perhaps solution was the wrong word for me to use here. It was intended to encompass the implementation details (abstractions, architecture, observability, etc)… All the decisions the engineers would normally make during planning and execution. Once I have that nailed down, the act of writing the code is largely mechanical.
That’s the source of my “easy” framing. It has always had the lower cognitive load in my experience. Now that I can offload the mechanical part to AI, I spend more time on the hard parts.
I still read plenty of code along the way, maybe less of it now because it’s easier to surface which parts of the code I need to read.
There was a time back in the 1980s (and probably before) when "analyst" paid better than "programmer". The programmer wrote the code; the analyst figured out what the code was supposed to do to meet the business need.
In my view, "programmer" merged with "analyst" to become "software engineer".
Who hires “pure solution modelers”? I don’t think I’ve ever encountered someone like that.
> Who hires “pure solution modelers”? I don’t think I’ve ever encountered someone like that.
They're called Business Analysts, sometimes simply Analysts, and that's effectively their job - come up with a spec and give it to the software engineers.
2 replies →
Aren't they simply called "consultants"?
From my experience, BAs don't model the solution - they translate and document stakeholder requirements
It’s still lower level than a business analysis though so it’s not the same
> What seems clear to me is that expectations around velocity and throughput will increase (are increasing).
This is why I don’t understand why folks around here (that are employed) feel so enthusiastic about AI. We are going to be working more in a rush to produce stuff that we won’t be feeling as proud of as we did before AI. Unless you were in the profession for the money, the delights of crafting software simply go away and AI is pushing us closer to be just… well, I don’t know, but I don’t like it. Sure thing, if you are a CEO, this new state of things must be wonderful
There was a recent interview with Dax Raad on the Pragmatic Programmer podcast, and they talked briefly about it. We would like a future where we do just a bit more work and are happier with legacy codebases or work on getting rid of tech debt, but that definitely won't be something our employers are interested in.
> AI is pushing us closer to be just… well, I don’t know, but I don’t like it.
"software plumbers"
> My personal experience: writing code has always been the easy part. AI does most of that now.
That's exactly why I don't have AI writing my code. It is doing the easiest part of the job (making symbols appear in the text), which isn't actually valuable to me. A good tool should help me to do hard things, not easy things.
I seem to only have discussions about architecture with it.
I didn’t know modern (2015-2026) software engineers were making such a strong distinction between “writing code” and “designing solutions”. It’s not the majority of engineers “design” and then hand over the implementation to others (at least Ive never seen that before).
From my experience, a typical software engineer needs to understand the business (e.g., knowing who your users are), design a solution (e.g., we probably need an event-driven arch right here) and write the code (e.g., we should use select for update skip locked to avoid over claiming). They all are equally challenging imho
Agree. Also, there is a lot fog at the moment. AI generates more code, we need a lot of markdowns now to teach it how to write "good code"... and <insert here a lot of AI processes>. But at the end... a programmer has to take ownership of that code and responsibility, meaning: reading A LOT of code and/or coding more code.
Spot on, in my experience.
exactly like this https://x.com/TBreakyour85306/status/2070811834131546196?s=2... An experienced coder can do faster, a business dev can launch faster, but a rookie coder without business cannot
Responding to my own comment to add that I think this moment favors the curious and passionate. None of what I wrote above is a complaint. I’m having more fun now than I have in a long time.
Coding is the easy part, huh? Sure, buddy.