IMO, by the time todays juniors would have 5-10 years of expected experience, the entire field will be something different altogether. Language choice distribution will collapse (if not change altogether), whole new modalities of monitoring and progressive delivery guardrails will come into play, essentially creating a 24/7 incremental rollout of pure agentic code, correctness will be determined by a mix of language features and self-monitoring by models in production and automated testing against production snapshots in pre-production, and deep debugging will the be province of a select group of engineers and there will be a pathway to those roles for juniors, but those roles will be coveted and difficult to break into (and probably will require education and maybe even informal accreditation).

▲

bulbar an hour ago | parent [-]

Just as "use code for contracts" failed for crypto currencies, "use AI output as prod" will fail for AI. Both is based on "just don't make catastrophic mistakes anymore".

You also wrongly assume that requirements can always easily expressed as natural language.

Another point: Software Engineering always starts where tooling capabilities stop. You don't get a competitive advantage by building without engineers what anybody everybody else can build without engineers.

▲

throwaway041207 41 minutes ago | parent | next [-]

> Just as "use code for contracts" failed for crypto currencies, "use AI output as prod" will fail for AI. Both is based on "just don't make catastrophic mistakes anymore".

What I think will happen is AI will write code and it will do the best it can to mitigate mistakes prior to rollout, but once rollout time occurs, rollout will be incremental and it will self monitor by defining success conditions at rollout time. The nature of the code will mitigate "catastrophe" to a small group at worst, but most likely initial rollout will just run new versions of the code in a simulated context (language design could benefit from this) and analyze potential outcomes without affecting current functionality.

But when the code goes live... it will be slowly scope changes progressively (think feature/experiment flags) and if it fails in the initial cohort, it will redirect. If success is positive, it will increase the rollout cohort.

This is a normal software engineering practice today, but it's labor and process intensive when driven by humans. But in a world where humans are less involved, this process is scalable.

	▲	bulbar 24 minutes ago \| parent [-]
		This assumes failures can be detected and fixed more easily than generating the corresponding change. I am not convinced that's the case. Counter points to my own arguments: 1. We don't know yet in detail what AI is good at. 2. AI doesn't need to be perfect, just "good enough", whatever that means for a specific project. More failures while saving hundreds of thousands dollars each year might be acceptable, for example.

▲

throwaway041207 28 minutes ago | parent | prev [-]

> Another point: Software Engineering always starts where tooling capabilities stop. You don't get a competitive advantage by building without engineers what anybody everybody else can build without engineers.

I'd note here that the long arc of software engineering has been commodifying the discipline into tooling. Ask any unix greybeard how shitty modern abstractions are and they'll give you all you can stomach and yet the wheel turns despite their treasured insights.