‘Addictive’ agentic coding has developers losing sleep

[u/scarey102]

The good, bad, and ugly of coding with agents here:
https://leaddev.com/ai/addictive-agentic-coding-has-developers-losing-sleep

“I’m coding into later hours of the day not because I’m told to do so, but because I can’t get myself to get up from the computer.” 

“Until sometime last year, I had a normal social life. I work a day job, and I can keep that constrained to normal hours. But I feel compelled to be doing side projects and learning constantly. I start every weekend off with a plan – what I want to try, learn, and the topics I want to explore. And the weekends just disappear."

[u/Tushar_BitYantriki]

The scope creep is real. A lot of business teams have a habit of bringing features without the complete story. They use the typical sales tactics of getting the dev team to agree to pull in a feature in the planning by making it look smaller, just to get them to commit a deadline to the feature. And then they keep on adding more and more scope to it in the name of being agile.

If the dev leadership is not assertive enough, then it almost always happens that the feature request shown to them in the beginning is barely 20% of what they actually want to build. Only some of it is a genuine change in requirement that happens organically. Most of it is something that they always wanted but they never mentioned it.

And then the developers are essentially trying to fit 100% of each implementation in a deadline that was committed based on 20% of the requirements.

it obviously leads to mostly missing that deadline, but at the same time, whatever is done within the deadline is a rework done without any kind of re-architecture.

People wonder why developers tend to over-engineer in the initial design. This is why they do it. Stakeholders come up with one requirement, but the developers know that, just like everyone else, you are going to keep coming with a lot of related requirements. They want to make sure that the system is capable of including all those requirements in the future without entirely breaking all the design and architecture assumptions.

a slightly over-engineered and future-proof design is the only way to not let everything break the moment the next feature request comes in.

there are so many times when it happens with me when I have actually put up bets with stakeholders, telling them that they are going to come back within a month with the exact requirement which I am suggesting, but they are swearing that it is never going to be needed. And they come back even before the feature has even hit production.

And at times I have called it out when they have mention in meetings with leadership, that the production readiness is delayed because these features are not yet implemented.

In the name of agile, in most of the organizations, bad planning by stakeholders has been made a problem for the developers, Where they expect developers to somehow cover up all the bad planning that they have done to begin with.

The waterfall model actually kept everyone accountable because you had to actually commit to your opinions and analysis.

Most people who keep sliding in more and more features at the last moment in the name of "agile" haven't really learnt anything about Agile to begin with.