You cannot tell me that letting anyone do something for you does not affect the skills that you outsourced, unless you are some sort of a superhuman.

As an example, I have been drawing portraits for quite a few years now, and whenever I go on a hiatus and come back after a few months, I can notice my skill not being anywhere close to where it was before I stopped using it.

Sure, after 2 or 3 portraits they mostly come back because of the previous experience, but skill rust is a real thing, and if you think your coding skills are the same because you used to code 20 years but haven't coded for some time, you are probably just lying to yourself.

Yeah he’s living in denial.

His skills are slowly eroding. Given that he spent 20 yrs building it up it won’t happen overnight. But the trade off is happening in real time.

My "digging for roots to eat" skills have also atrophied. Fortunately I don't need those much anymore because of modern agriculture.

I wonder how much of this "you are gonna lose your skills!" stuff matters. And if knowing how to properly iterate a for loop with my eyes closed matters all that much anymore.

Aren't we all unique? A person is not just a mish mash of his career and hobbies.

How do you know what good output should look like with little code experience?

Yes but currently I don't know of a single company in my area that doesn't make you use AI daily because of the supposedly increased productivity. That means that juniors also absolutely have to use AI, probably sabotaging their learning process in the long run.

Here's a great one: https://pikuma.com/courses/cpp-2d-game-engine-development

What stops a small, or even a large group of people to intentionally "poison" the LLMs for everyone? Seems to me that they are very fragile, and that an attack like that could cost AI companies a lot. How are they defending themselves from such attacks?

This is already a thing: https://www.scworld.com/brief/poison-fountain-initiative-aim...

We'll see if they succeed.

I think it might be too late.

The instances should be based on the context. For example we had a few different API providers for the same thing, and someone refactored the separate classes into a single one that treats all of the APIs the same.

Well, turns out that 3 of the APIs changed the way they return the data, so instead of separating the logic, someone kept adding a bunch of if statements into a single function in order to avoid repeating the code in multiple places. It was a nightmare to maintain and I ended up completely refactoring it, and even tho some of the code was repeated, it was much easier to maintain and accommodate to the API changes.

I have, and in each sprint we always had tickets for reviewing the implementation, which could take anywhere from an hour to 2 days.

The code quality was much better than in my current workplace where the reviews are done in minutes, although the software was also orders of magnitude more complex.

You are comparing compilers to a completely non deterministic code generation tool that often does not take observable behavior into account at all and will happily screw a part of your system without you noticing, because you misworded a single prompt.

No amount of unit/integration tests cover every single use case in sufficiently complex software, so you cannot rely on that alone.

I just rewrote a utility for the third time - the first two were before AI.

Short version, when someone designs a call center with Amazon Connect, they use a GUI flowchart tool and create “contact flows”. You can export the flow to JSON. But it isn’t portable to other environments without some remapping. I created a tool before that used the API to export it and create a portable CloudFormation template.

I always miss some nuance that can half be caught by calling the official CloudFormation linter and the other half by actually deploying it and seeing what errors you get

This time, I did with Claude code, ironically enough, it knew some of the complexity because it had been trained on one of my older open source implementations I did while at AWS. But I told it to read the official CloudFormation spec, after every change test it with the linter, try to deploy it and fix it.

Again, I didn’t care about the code - I cared about results. The output of the script either passes the deployment or it doesn’t. Claude iterated until it got it right based on “observable behavior”. Claude has tested whether my deployments were working as expected plenty of times by calling the appropriate AWS CLI command and fixed things or reading from a dev database based on integration tests I defined.