Hacker News new | ask | show | jobs
by declan_roberts 376 days ago
These posts are funny to me because prompt engineers point at them as evidence of the fast-approaching software engineer obsolescence but the years of experience in software engineering necessary to even guide an AI in this way is very high.

The reason he keeps adjusting the prompts is because he knows how to program. He knows what it should look like.

It just blurs the line between engineer and tool.

5 comments

The argument is that this stuff will so radically improve senior engineer productivity that the demand for junior engineers will crater. And without a pipeline of junior engineers, the junior-to-senior trajectory will radically atrophy

Essentially, the field will get frozen where existing senior engineers will be able to utilize AI to outship traditional senior-junior teams, even as junior engineers fail to secure employment

I don’t think anything in this article counters this argument

I don't know why people don't give more credence to the argument that the exact opposite thing will happen.
Right. I don’t understand why everyone thinks this will make it impossible for junior devs to learn. The people I had around to answer my questions when I was learning knew a whole lot less than Claude and also had full time jobs doing something other than answering my questions.
It won't make it impossible for junior engineers to learn.

It will simply reduce the amount of opportunities to learn (and not just for juniors), by virtue of companies' beancounters concluding "two for one" (several juniors) doesn't return the same as "buy one get one free" (existing staff + AI license).

I dread the day we all "learn from AI". The social interaction part of learning is just as important as the content of it, really, especially when you're young; none of that comes across yet in the pure "1:1 interaction" with AI.

I learnt programming on my own, without any social interaction involved. In fact, I loved programming because it does not involve any social interaction.

Programming has become more of a "social game" in the last 15 years or so. AI is a new superpower for people like me, bringing balance to the Force.

To me, LLMs are just a different kind of social interaction I mostly don’t want, tedious and frustrating.
Junior devs using AI can get a lot better at using AI and learn those existing patterns it generates, but I notice, for myself, that if I let AI write a lot of the code I remember and thereby understand it later on less well. This applies in school and when trying to learn new things but the act of writing down the solution and working out the details yourself trains our own brain. I'd say that this has been a practice for over a thousand years and I'm skeptical that this will make junior devs grow their own skills faster.

I think asking questions to the AI for your own understanding totally makes sense, but there is a benefit when you actually create the code versus asking the AI to do it.

I'm sure there is when you're just getting your sea legs in some environment, but at some point most of the code you write in a given environment is rote. Rote code is both depleting and mutagenic --- if you're fluent and also interested in programming, you'll start convincing yourself to do stupid stuff to make the code less rote ("DRY it up", "make a DSL", &c) that makes your code less readable and maintainable. It's a trap I fall into constantly.
> but at some point most of the code you write in a given environment is rote

"Most of the code one writes in a given environment is rote" is true in the same sense that most of the words one writes in any given bit of text are rote e.g. conjunctions, articles, prepositions, etc.

If your code is that boilerplate you can do it by rote, you need to abstract it already. Or write a generator/snippet
You learn by doing.. eg typing the code. It's not just knowledge, it's the intuition you develop when you write code yourself. Just like physical exercise. Or playing an instrument. It's not enough to know the theory, practice is key.

AI makes it very easy to avoid typing and hence make learning this skill less attractive.

But I don't necessarily see it as doom and gloom, what I think will happen - juniors will develop advanced intuition about using AI and getting the functionality they need, not the quality of the code, while at the same time the AI models will get increasingly better and write higher quality code.

If a junior engineer ships a similar repo to this with the help of AI, sure, I'll buy that.

But as of now, it's senior engineers who really know what they 're doing who can spot the errors in AI code.

Hold on. You said "really know what they're doing". Yes, I agree with that. What I don't buy is the coupling of that concept with "seniority".
Have a better term for "knows what they're doing" other than senior?
That's not what "senior" means.
If I’ve learned anything from the past few decades, something completely unexpected and even weirder than both will happen.
> The argument is that this stuff will so radically improve senior engineer productivity that the demand for junior engineers will crater.

What makes people think that an increase in senior engineer productivity causes demand for junior engineers to decrease?

I think it will have the opposite effect: an increase in senior engineer productivity enables the company to add more features to its products, making it more valuable to its customers, who can therefore afford to pay more for the software. With this increase in revenue, the company is able to hire more junior engineers.

> It just blurs the line between engineer and tool.

I realise you meant it as “the engineer and their tool blend together”, but I read it like a funny insult: “that guy likes to think of himself as an engineer, but he’s a complete tool”.

> prompt engineers point at them as evidence of the fast-approaching software engineer obsolescence

Maybe journalists and bloggers angling for attention do it, prompt engineers are too aware of the limitations of prompting to do that.

I don't know why that's funny. This is not a post about a vibe coding session. It's Kenton Varda['s coding session].

later

updated to clarify kentonv didn't write this article

I think it makes sense that GP is skeptical of this article considering it contains things like:

> this tool is improving itself, learning from every interaction

which seem to indicate a fundamental misunderstanding of how modern LLMs work: the 'improving' happens by humans training/refining existing models offline to create new models, and the 'learning' is just filling the context window with more stuff, not enhancement of the actual model or the model 'learning' - it will forget everything if you drop the context and as the context grows it can 'forget' things it previously 'learned'.

When you consider the "tool" as more than just the LLM model, but the stuff wrapped around calling that model then I feel like you can make a good argument it's improving when it keeps context in a file on disk and constantly updates and edits that file as you work throguh the project.

I do this routinely for large initiatives I'm kicking off through Claude Code - it writes a long detailed plan into a file and as we work through the project I have it constantly updating and rewriting that document to add information we have jointly discovered from each bit of the work. That means every time I come back and fire it back up, it's got more information than when it started, which looks a lot more improvement from my perspective.

I would love to hear more about this workflow.
The sequence of commits talked about by the OP -- i.e. kenton's coding session's commits -- are like one degree removed from 100% pure vibe coding.
Your claim here being that Kenton Varda isn't reading the code he's generating. Got it. Good note.
No, that's not at all my claim, as it's obvious from the commit history that Kenton is reading the code he's generating before committing it.
What do you mean by "one degree removed from 100% pure vibe coding", then? The definition of vibe coding is letting the AI code without review...
> one degree removed

You're letting Claude do your programming for you, and then sweeping up whatever it does afterwards. Bluntly, you're off-loading your cognition to the machine. If that's fine by you then that's fine enough, it just means that the quality of your work becomes a function of your tooling rather than your capabilities.

You ever get the feeling someone didn't look up Kenton Varda before criticizing the code he's generating?

I guarantee you that Kenton Varda's generators generate more code than any other code generators that aren't compilers. ;)

I mean yeah, the very first prompt given to the AI was put together by an experienced developer; a bunch of code telling the AI exactly what the API should look like and how it would be used. The very first step in the process already required an experienced developer to be involved.