@quimnuss @lumi
I will say, keep in mind that this is software development related. It may not apply directly to another area.
I would sort this by competency:
Beginner/Learner:
* Polarising confidence, either very low or very high
* Quickly get a kind of "Pull the lever again" behaviour, similar to someone at the pokies who wants to re-roll and spends on trying to get the solution again
* Gets heavily exposed to this via Copilot in VSCode when they first download it - assumes this is how it has been all the time
* If they have developed good learning strategies prior, you may find they lean into the machine more - so people who use to write and note things down just use the LLM to explain things
* Uses the LLM chat window for notes
* Does not like explaining code without comments littered through out it all
* Concerns themselves with aesthetics of trivial code (in part, semi-deceptive behaviour)
* Long term use usually results in barely being able to solve trivial problems - they find something like "Building a linked list" hard when the interface is different
* Mismatch between understanding of language constructs and their code submissions
* Will build very poor associations, example, associate for loops with a loop that prints 1 to 10 and treat things as an incantation.
Intermediate/Expert:
* Confidence ranges, can be overconfident and arrogant or confident - however they start making subtle mistakes that get considered as "wins" in the workplace
* Is aware of what are decent measures and actions of good software but tries to automate them (see - automating test cases, they will miss things where the LLM will invent things or have a mismatch to meet the requirement of ensuring that things pass)
* Either never had a good sense of systems and accepts that everything it generates is good enough (example, when LLM will generate solution to a problem involving scheduling tasks to run at certain times, it may generate some signal based approach that they assume is correct)
If the user is comfortable with that space, they usually overlook things for the sake of time.
* Quality and scrutiny degrades, this is because of two things:
a) You stop writing and therefore it isn't fresh in your head what quality looks like
b) You get conditioned to the slop sent your way that you become less engaged and you also are overwhelmed.
* What you should observe is practical read times for people in the profession. If the generated code is 10000 lines.
Are they actually reading that many lines within time-to-gen and time-to-commit. The obvious answer is no for most people but I'll say, some will scrutinise for a long period but when conditioned to this, it becomes a "hassle" and they will start preferencing risk if it means "getting more done" and "looking good".
* Conduct and detail in written communication not matching verbal
I found that it is always an interesting experience to just hop on a call with a sloperator and get them to explain their patch/PR/commit. Just asking questions that they never asked themselves.
In addition, there is a formulaic way in which the written communication occurs and speaks to others in.
* They become unimaginative
This is just a side effect of outsourcing your ability to think and understand a problem domain.
* No upskilling will result in antiquated knowledge and skills
When programming languages evolve and change, a experts knowledge is kinda locked when they started using them more so, it means that they start backsliding and build very poor associations with things.
---
What you will find that consistent is that there is a general euphoria they get from these things.
They become happy they got it done and live to survive another day rather than not which unfortunately speaks to a fairly understandable world view.
In some cases: Memory issues occur and these can be quite severe, generally there is an impatience and frustration with themselves for "need to describe it better" or "not being smart enough".
---
However, let's think about this another way as well.
Many software engineers have learned a variety of languages before, let's take C and Python.
When people don't practice C and have been practicing nothing but python, they will view and depend on structures in that environment lot and the transition to C is going to be fraught with either needing to remember a bunch of things you hadn't practice or just re-learning foundations again as if you are a beginner.
What is worse here is the randomness and lack of precision here. If your writing ability gets compromised your ability to write spec is too, the spec that I am referring to are the prompts to an LLM.
Oct 21, 2026, 1:07 PM
