In Part 1, I explored why making AI engineering easier doesn't automatically make software delivery easier. In Part 2, I looked at what changing ou...
For further actions, you may consider blocking this person and/or reporting abuse
I think the bigest change is the size of developer teams which is decreasing. Because right now not need so many programmers and time to solve a problem this is lead to our focus moving from a tiny ticket solving day by day to bigger problem solving action. For example standard workflow not allow to us to make a new programming language if we would like to use a new one. Or change so large open source programming language like a TypeScript
Other one is the technology freedom. My experience with agents is so flowfull and creative which is allow to me a completly different highly free workflow. Right now I really don't need using a laptop instead a phone is enough for a development.
My final is: we have more time to think. But also the whole stuff is scary
I agree! Having more time to think and explore is great. But the scary part is how quickly everything is changing. We just need to make sure we're still in control of the tools, not the other way around.
The part about not needing to justify doing things the old way sounds nice, but in a lot of places it’s not really the engineer’s choice. Some companies are now tracking how much people use AI tools, or pushing them in from the top because it looks good to leadership. Then you’re not changing because you found a reason, you’re changing because someone above you decided you should. I think that’s where a lot of the pressure actually comes from.
Yeah, and that’s what makes it tricky. Even if you know what works best for you, it’s hard to stick with it when you’re being measured against something else.
The line that lands hardest is 'change because you've found a reason, not because the technology has given you permission' — most workflow redesigns I've seen start from the tool's capability and work backwards to a justification. The visible-activity trap is real too: more agents and more generated code are not outcomes. When you do decide a change is warranted, what outcome do you measure first — delivery time, reliability, or something quieter like maintenance load months later?
I'd look at reliability and long-term maintenance first. Faster delivery is great, but not if it leaves us with more problems to fix later. More code doesn't always mean more progress!
Reliability first is the right order — delivery speed shows up immediately, while maintenance load only bills you months later, which is exactly why the visible-activity trap works. The quiet metric I'd watch is how often a change forces a second change: if new code keeps generating its own follow-up fixes, the delivery gain was borrowed, not earned. Do you track that follow-up rate, or is it more a felt cost when the team slows down?
The bit about missing 2019 is less about the year and more about having room to explore without chasing every new tool. Is that room something a team can actually protect once delivery pressure picks up?
I think it's possible, but it takes a conscious effort. Once deadlines start piling up, exploration is usually the first thing we sacrifice. Teams need to make room for it, not just hope it happens.
That deadline point is the catch. Exploration is always first on the chopping block, so making room has to be deliberate.
Change because you've found a reason, not because the technology gave you permission — that line alone is worth keeping. I've felt the 2019 bit too, not nostalgia for the tools, just for having room to try something without it instantly becoming a workflow redesign. When a team genuinely can't tell yet whether a change is friction or just unfamiliarity, do you wait for evidence, or pick a small experiment and timebox it?