[throwaway041207]

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]

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]

> 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]

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]

> 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.

This I think is the unexplored aspect of what's happening right now. Guardrails around "good enough" systems is where the future value lies. In the future code will never be as good as when the artisans were writing it, but if you have an automated process to validate/verify mediocre code (and kick it back to AI for refinement when it fails) before it's fully productionized, then you have a pathway to scaling agentic coding.

[bulbar]

Validating / Verifying mediocre code is pretty hard as nobody was able to agree what that even means.

[throwaway041207]

If you are working with AI to define the purpose and goal of the change -- which is to say planning how the changes to the code should result in some sort of feature/bugfix/whatever, then planning phase should ask you to define clear success conditions for the code that it writes. These could be otel/datadog metrics, or some kind of funnel metric or some cessation of errors in your APM, whatern. In any case the outcome of the change is what I mean by validate/verify. Mediocre code can solve issues and we can tolerate mediocre code in that sense. The guardrails kick back failing "mediocre" code, it accepts working mediocre code.

And this could easily apply to every change we made by hand before AI, it was just a tedious process to layer these things into code when we were just fixing bugs and whatnot. In an AI writes all the code world adding this kind of stuff as table stakes for a changeset is zero cost, effort wise.

[amoss]

> rollout will be incremental and it will self monitor by defining success conditions at rollout time.

This sounds a lot like allowing an LLM to define tests as well as implementation, and allowing the LLM to update the tests to make the code pass. Recently people have come to understand (again?) that testing and evaluation works better outside of the sandbox.

[throwaway041207]

Sorry I wasn't very clear about that part. I think success conditions are described by stakeholders, whoever that is, and then the implementation of monitoring them is probably created by the LLM. For engineering level stakeholders that's going to be metrics, performance, etc. Whereas for more business side stakeholders that'll be a mix of data metrics and product feature metrics, click-through rates, stuff like that

[throwaway041207]

> 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.

[bulbar]

Well, ask any engineer about any code... ;-).

[blks]

Everything looks a nail for our hammer-shaped chat bot.

I think you’re overly hyped if your actually believe this is going to be a reality in 5-10 years.

[munksbeer]

Up until about four months ago, the sentiment by so many programmers online (here, reddit, etc) was that LLMs were absolutely useless at coding. And yet, many of us were puzzled, because we were having success with them, at coding.

People were burying their heads.

Today, there are not many of those people left. Some, but not a lot. Because you can only deny reality for so long.

I don't know what the coding world is going to look like in 5-10 years, but everything has changed radically in the space of a year from maybe 10% of people using agents to code to probably 95% of people now. In about a YEAR.

I don't know, but my assumption is these things will get better to a point where they will be automating close to 100% of coding, and deploying, and verifying, etc. The old job we had will be completely changed well before 10 years. I still think us "engineers" will have a role to play, but I genuinely don't know what it will look like.

[lelanthran]

> I don't know what the coding world is going to look like in 5-10 years, but everything has changed radically in the space of a year from maybe 10% of people using agents to code to probably 95% of people now. In about a YEAR.

Last I saw about a week ago, the stats were about 35%. There may be some confusion around this:

1. The absolute number could have remained the same but the sheer volume of vibe-coders who never coded before raised the percentage. For example, if 100 out of a population of 1000 people uses AI then the percentage is 10%. If, over the next year 9k new vibers were created but none of the existing 1000 people changed their workflow, you will see 9100 people out of 10000 people using AI - that's now a 91% rate of people using AI to code even though none of the people since last year changed the way they work.

2. Last I checked, pre-AI, there were about 12m working developers in the world (SO survey extrapolated). As of February this year, CC, by itself, had 60k subscribers. Even if we err on the side of optimism and assume every single subscriber is running the agent, that's still not 95% of developers.

> I still think us "engineers" will have a role to play, but I genuinely don't know what it will look like.

??? We already know what it looks like - "Business Analyst" has bee a role since forever (at least since 1995, when I entered the workforce). If you wanted a role where you wrote no code but merely drew up specs for the programmers to code, you could have had it as a BA.

It's just that few of us wanted to do that as it paid half what an engineer made. Now with the supply of BAs potentially doubling, it will pay a quarter of what an engineer used to make.

[munksbeer]

I don't know what industry you work in or what developers surround you, but the number of developers NOT using agentic coders in my workplace is 0.

And I know this is the same in peers workplaces.

[lelanthran]

> I don't know what industry you work in or what developers surround you,

Why would that matter? I'm not giving you my experience of developers next to me, I'm telling you what I gleaned from published reports.

[munksbeer]

I don't believe those figures. Perhaps we could discuss more if you linked the reports.

In any case, I know how these arguments go. It doesn't really matter.

[blks]

In my workplace number of “agentic coders” users is 1. And among principle and seniors - 0.