Thread regarding Optum layoffs

It's hype. Coding is only a small fraction of a good engineer/architect's work.

@pv Not what I said. I said they do nothing to benefit delivery. And they don’t report to me. They report to higher level do nothings but set up calls and report on the work others are delivering and enforce antiquated delivery processes. Way too heavy processes.

The people who adapt raise the ceiling. The people who complain about the new failure modes stay at the old ceiling and call it wisdom.

@ew Your employees are LITERALLY doing nothing? Seems like a leadership issue. Do better.

Tokens cost same price offshore or onshore..so I see it as a silver of hope for onshore engineers who care about quality n user their tokens to fix outside slop!

It is awesome! Get rid of the worthless employees lreporting out others work and not doing any true work to benefit delivery. About time! See ya dead weight!

What about the DFC- AWWG staffing

Pure shyt.

@ax Have you shared these feedbacks with your leaders? Or they just don't care?

AI allows teams to generate significantly more code with fewer developers. On the surface, this looks like a major productivity gain. However, the amount of code being produced can grow much faster than the team's ability to understand, review, test, and maintain it.

More Code + Fewer Developers + Less Understanding = A Disaster Waiting to Happen

If developers increasingly act as “AI supervisors,” junior engineers may get fewer opportunities to develop their fundamentals by actually implementing and solving problems themselves. Over time, this could weaken the team’s ability to understand and diagnose problems without relying on AI.

I also worry about the long-term impact on career development. If junior engineers rely on AI to generate most of their code instead of using it as a tool to learn, they may never develop the depth of understanding and problem-solving skills required to become strong senior engineers. There is a difference between using AI to accelerate your learning and development and simply outsourcing the learning to AI. If the latter becomes the norm, we could end up with engineers who can produce a lot of code but don't truly understand what they are building.

The problems have shifted from simply writing code to specifying, reviewing, and controlling AI-generated code.

AI-generated output still requires substantial review. Unfortunately, when AI generates large amounts of code or documentation, people often don’t take the time to thoroughly verify the output. This can quickly lead to inconsistencies, incorrect assumptions, and ultimately a mess that becomes difficult to maintain.

AIDLC also relies heavily on specifications and documentation being precise and complete. If even a small detail is missed or unclear, the AI can make assumptions or hallucinate, and it may efficiently build the wrong thing.

Debugging is another major challenge. AI can generate a large amount of code very quickly, but when something breaks, it can be difficult to understand the root cause—especially when the engineers reviewing it didn't actually write the code themselves. This can make debugging and maintaining the system significantly more challenging.

All in all, from my experience, I feel that AIDLC has made things worse rather than better. While it can significantly increase the speed at which code is produced, the additional effort required for reviewing, validating, debugging, and maintaining that code can outweigh the productivity gains.

It su-ks!