In 2021 I built a tool called Cypax that turned plain English into working Python. It used NLTK. There were no ChatGPT style models to lean on, so the whole thing was parse trees, intent matching and a lot of careful rules. It won Hackerflow, the annual hackathon run by SurveySparrow, against teams from across India.
Four years later a model does what Cypax did, better, in one line. I am not sad about it. But building that tool taught me something about the shape of this problem that I keep coming back to now that everybody has a model in their editor.
The hard part was never the generation. It was working out what the person actually wanted.
The skill nobody taught us
There was a specific skill, and every good programmer had it, and nobody ever ran a class on it.
You would hit an error. You would not paste the whole thing into Google, because
that returned nothing. Your stack trace had your own file paths and your own
variable names in it, and no other human had ever produced that exact string. So
you stripped it down to the part that came from the library. You dropped the line
numbers. You quoted the fragment that would be the same on every machine. You
added the version number, because the answer for 2.x is wrong for 3.x and will
cost you an afternoon. Then you added site:stackoverflow.com, because the SEO
farms had already eaten the open web.
And then the part that actually separated people. Reading the results.
The accepted answer was not always the right answer. Very often it was the 2011 answer, accepted by somebody who never came back, and the correct answer was sitting below it with more votes and a comment starting with "this is deprecated as of". You learned to check dates. You learned that a comment with forty upvotes under a mediocre answer is worth more than the answer. You learned to tell, from the shape of a reply, whether the person writing it had actually run the code.
That was the skill. Not knowing things. Knowing how to find out, and how to judge what you found.
It did not disappear, it changed shape
I do not think we lost that skill. The surface moved and most of the muscle transferred.
Searching was a retrieval problem. The answer exists somewhere, get to it, judge it. Prompting is a specification problem. The answer does not exist yet, so describe the shape of it precisely enough that something can produce it, then judge what comes back.
The judging half is identical. This is the part people miss when they say AI makes programmers worse. A bad Stack Overflow user and a bad LLM user fail in exactly the same way. They accept a plausible looking answer because it is in front of them and they would like to be finished. Copying the top answer without reading the comments, shipping generated code without reading it. Same mistake, nicer interface.
What actually makes prompts work
Most writing on this is content marketing. Here is what has held up for me after a couple of years of using these tools daily on production systems.
Context beats phrasing. The biggest single jump in quality is not how you word the request. It is giving the model the actual code, the actual schema, the actual error, the actual constraints. A clumsy prompt with the right three files attached beats a beautifully written prompt with none. Most bad output I see is a context problem dressed up as a prompting problem.
Say what you are optimizing for. "Write a function that deduplicates this list" has a dozen reasonable answers. "Preserve first seen order, for a list of up to ten million strings, where memory matters more than speed" has one. This is the same instinct as adding the version number to a search query. You are narrowing to the answer that is right for your situation, not the one that is right in general.
Ask for the approach before the code. For anything non trivial, ask for two or three options with tradeoffs first. Rejecting a bad approach in a paragraph is far cheaper than rejecting it in three hundred lines you now have to read. It also surfaces the model's assumptions while they are still easy to correct.
Give it a way to be wrong. "If this does not fit the existing pattern, say so rather than forcing it." "If you need to see another file, ask." Without an exit you get confident invention, which is the model's version of that Stack Overflow answer written by somebody who never ran the code.
Fix the prompt, not just the output. When the answer is wrong the reflex is to reply "no, do X". It is better to work out what the prompt failed to say, and put it in. Same discipline as reformulating a search query instead of scrolling to page two.
What I would tell a junior engineer
The worry I hear often is that people entering the field now will not build deep knowledge, because they never have to sit with a problem long enough.
I understand the worry but I think it is aimed at the wrong thing. Nobody ever built deep knowledge by memorizing API signatures. That was always cheap knowledge and looking it up was always fine. Deep knowledge came from debugging things that should not have broken, from reading code you did not write, and from being on call for something you built.
None of that is automatable, because all of it involves an unfamiliar system behaving unexpectedly under conditions nobody wrote down.
What has genuinely changed is that the floor came up. You can produce working code in an unfamiliar language on your first day. That is real and it is good. But telling whether the code is any good, whether it will hold at scale, whether it fits the system it is joining, whether its failure modes are acceptable, has not got cheaper at all. If anything that is now the whole job.
Generating code was never the bottleneck. Deciding what to build and knowing whether it is right were the bottleneck, and they still are. Making the part that was never the bottleneck faster is useful. It is not the revolution some posts claim and it is not the apocalypse others claim.
One habit worth keeping
Read the output the way you used to read the comments.
When Stack Overflow was the tool, the mark of a good engineer was that they scrolled past the accepted answer. Now it is that they read the generated code before running it. They notice the swallowed exception. They notice the assumption about input size that is not true here. They notice the library version that does not match. Ask what would make this wrong before you ask whether it runs.
That was the skill in 2012 and it is the skill now. The search box just got better at answering back.