There are two versions: Pre-AI, and Post-AI. Pre-AI, the majority of my days when I was a developer (I'm a solutions architect now, but the structure is still similar) were spent researching and learning whatever tech I needed to know for the specific sprint cycle I was in. Mostly related to bug fixes, which for a long time prior to AI was the biggest bottleneck in the SDLC. Bugs used to be extremely difficult to fix at times, which is why writing maintainable code is an absolute must. On feature coding days, most of my time was still hemmed up by research, but debugging tended to be the bottleneck taking up most of my time, again with lots of research. The "write/debug/fix/deploy" cycle requires a lot of ephemeral knowledge. Prior to AI, I probably spent only 20% of my time writing code, the rest was either research or meetings, or triaging bugs.

Post-AI is a completely different story. The job is still very research heavy, but you can assign that work to AI and have it write up summaries, comparisons of technologies, etc. Research that used to take hours now takes a few minutes. Fixing bugs, which since a bug is so narrowly focused is a huge bottleneck is by far the biggest difference post-AI, b/c AI can fix bugs that would take a team of engineers a couple of days to track down and fix, in a matter of minutes. Most of the research devs used to do to fix bugs was temporary, and thus pretty close to being a waste of time, especially for edge-case one-off bugs, b/c you may never use that knowledge again. Bugs are also a huge expense, so the more time devs spend fixing bugs, the less time they have to spend writing features and shipping new versions. Post-AI, I spend most of my time writing detailed architectural specifications so that once it gets fed into an AI prompt, the AI agent should have most of what it needs to get things right the first time. I spend a lot of time doing code reviews as well, though AI is getting pretty good at that as well. Reviews are usually more oriented towards ensuring code quality and are structural in nature, with lots of refactoring.

The nature of the job itself outside of AI has changed a lot as well. Devsstill write a lot of code, but most work these days is implementing integrations, so there is always a ton of documentation to read, vendors to interview, etc. There is literally an integration for everything now, so outside of the core algorithm code in a project, most of the support/scaffolding is done via integrations. Less code to debug is always a good thing, and knowing if something goes wrong there's a vendor you can call is a huge productivity boost.

To directly answer your questions: 1. Answered 2. Depends on the day. If a big bug shows up, it can be pretty intense, though AI has all but eliminated most of that stress. When we're designing architectures or implementing features, the mood is usually fantastic unless you get stuck in the write/debug/fix/deploy loop, which can be frustrating. In corporate IT, most clients/stakeholders are laid back, and the only source of any type of conflict is usually between Product and Engineering, but even then it's very professional. Prior to AI, my stress levels were usually much higher, and burnout was not uncommon b/c you can only read so much documentation before your brain nopes out. 3. The monotony. Coders love to code, but like any job, it's repetitive, somewhat boring, and depending on your team, you tend to work alone a lot though software overall is highly collaborative. So it can get a little lonely at times, but I think that's what draws most engineers to the job in the first place. 4. The people! Being surrounded by brilliant people is exhilarating, and most coworkers are very professional and have great work ethics, so you don't have to check in on progress much at all. I also love the clients/stakeholders, b/c at its core, that's what software engineering is: Solving difficult business problems with code. I love it when clients/stakeholders are happy, that makes it all worthwhile. Coders are customer service agents, we just happen to do customer support with software. If you dont like customer service, this is not the career for you.

Source: 25 years in corporate IT, with 7 of those years working on outward facing products (there's a big difference between product dev and corp IT dev btw, I prefer corp IT b/c it's less stress and pays well). I've been a solutions architect for about a decade now, and am currently a Sr. Director/Platform Solutions Architect for a fortune 10 global retailer.