Over the past couple of months, I've read a lot of articles about the consequences of AI dependency and one prominent finding is cognitive atrophy....
For further actions, you may consider blocking this person and/or reporting abuse
Great work Elmar!
I seen a lot of articles that talks about very similar aspects when it comes of using AI. This article in particular made me realized that "I have been using AI as my Step 1 instead of me thinking it first".
I realized that I have used AI immediately without me thinking of a solution first. This goes the same before AI where one relies on StackOverFlow for answers. I realized that relying decay my thought of thinking independently and prevented me from explaining the thing I built. Right now, I am currently trying to think of a solution myself before using AI or other tools to help me solve the problem. That way, I can be the person who is able to explain and help other peers on the project I am confident in.
Great write up and nice use of images lol. Student like Master haha
Thanks @francistrdev! Recently, I've been doing a lot in my power to bring more people to the responsible and disciplined side of using AI. Mostly through commenting on posts. This time, I'm just glad that I got to share my two cents in an article post.
When I notice atrophy it's hard for me to be sure if it's an over-reliance on AI tools or being in my late 30s and not always having the room in my head for all this stuff 🫠
@ben I'm 100% sure it's not about the age 🤣 My grandmother is 90+ years old and still as sharp as ever (though she never programmed, but she was a teacher).
What caught mine was distrusting any tool's summary of a diff. A CLI proxy I route git through reported two files as identical when they were not, and only re-running /usr/bin/diff showed the change. Reading the real diff is the review step I stopped skipping.
Woah, never encountered this AI error before. Thanks for the heads up!
The review step is necessary, but it can still become ceremonial if the engineer only checks whether the output looks plausible. One useful habit is to predict the failure modes before asking the model, then compare its result against those predictions. That keeps problem framing, test selection, and debugging muscles active while still letting the tool handle mechanical work. The skill worth protecting is not typing syntax; it is forming and revising a model of the system.
Thanks for this in-depth insight. Personally, I haven't thought about predicting the failure modes first. I always think about what I want my feature to look. I'll be sure to add that in my arsenal during development.
Think first, prompt later. Thanks for this post.
Your welcome @devmount
W article Elmar!
Avengers fan here!
Thank you for the support!
Make review start with predictions. Write expected behavior and failure cases before reading generated code then test those claims.
Yep, this is a much robust approach too. It has clear intentions, I like it!
Such a great point! Really enjoyed reading this.