_usefulcat

I'm pretty sure this article is written by AI as there are lots of those long hyphens in it that AI seems so keen to use. If it is I can't tell whether that's ironic or reinforces their argument.

So I'm not sure what I've learnt from it!

There are a lot of similar articles to this recently, and there will be many more. There will also be many articles with the opposite view. Both are interesting and offer different viewpoints to what is the biggest software engineers' existential crisis.

I don't agree with this article but equally I respect their opinion. My primary reason I use AI is that a lot of coding is boring and has often made me wonder what I am doing with my life. At least now I am able to focus more on the parts of software development that interest me, shifting more of my time to the left of the development lifecycle: innovation and design

You might be right! I had a copy of 'Slightly Magic' which had some speech synthesis. Great game. Never completed it though

> I’m Tired of Being on the Network

But I'll post about it on the network

I think there is a middle ground too. Well organised Engineering and Product teams using AI efficiently whilst actually talking together and making decisions. Neither AI zealots, nor doom and gloom.

> I’m going to make a prediction of my own… In the future we will see more and more companies proudly boasting their “NO-AI” policy as a competitive advantage. And they will be right

I'm going to make my own prediction: this isn't going to happen

That's interesting, less than I thought. I'm curious about this because I'm working on a sudoku variant that has two pieces of data in each cell - such as numbers and letters. I am keen to try out your process with that arrangement.

> Every mount generates a fresh pen sketch from seeded randomness, and the stroke boils like an animated doodle.

I've seen many hand drawn effect css libraries but what I like about this one is that each control has its own unique stroke. Pretty neat

I'd like to submit my counterpoint. I work on an established codebase building new features and fixing bugs. It has access to our story board, git and a couple of other mcps. As long as the story is well written with clear requirements and expectations it always produces quality code that I validate as a human with a variety of tests automated and manual. I peer review the code. My colleagues then peer review that too.

I have noticed two things - new features take at a minimum at least half the time it took me previously and bugs are much less frequent. Even faster when bug fixing.

My takeaway is that you need solid requirements, clear context and thoughtful human oversight primarily during planning but also during verification