Does Joel still disagree today?

Worth noting that this article is 25 years old. The world was very very different back then, especially when it comes to software engineering.

Context switching is a problem when the cost of switching contexts is non-negligible -- but in the age of agentic development is that still really true? Surely yes for some problems, but for many others I would argue it no longer is.

A personal anecdote for you:

At my company we have a local development CLI our devX team built, it allows for agents to interact with standing up, tearing down and managing local stacks for our software suite. When I receive customer feedback about a broken button, or a poor UX experience, I simply start up a prompt:

/metal user X reported an issue on the trial balance page, they encountered a blank page when using the inception to date filter. We need to investigate the root cause, spin up a new stack, and resolve the bug.

Then off to the next task, maybe some few hours later I'll check back in on the session and I'll see:

> PR created: https://github.com/company/repo/pull/12758295 > QA URL: http://localhost:8400/<url> > Summary of root cause and fix: lorem ipsum lorem ipsum

After a quick QA session I validate the fix, confirm that our claude reviewer has approved the PR and merge the PR to deploy. The mental burden of switching to this task is quite low, orders of magnitude lower than it would be 25 years ago.

▲

feanaro 4 days ago | parent | next [-]

What is also lower is your understanding of the change. So yes, if you are now essentially only doing the final mile of paper pushing for the LLM, then the mental burden is lower but so is the assurance of what has just transpired.

Whether this mode of working is going to be long-term viable is going to depend on how important it is for you to be aware of what has happened for the system in question, how viable the economics are for the LLM usage at this level of assurance and how much ownership you exert over the LLM used or another similarly powered one (because otherwise the LLM can be taken away from you, leaving you at the mercy of a third party with goals that do not align with your own).

▲

Syntaf 4 days ago | parent [-]

Both very fair observations.

> Whether this mode of working is going to be long-term viable is going to depend on how important it is for you to be aware of what has happened for the system in question

This is the million dollar we'll see answered in our lifetime. Software engineering exists to automate work, are we arrogant to think we are not destined to the same fate? Is this truly a job befitting of a human over an agent?

Ever since I discovered my dad's C++ book in highschool I've absolutely loved coding, but i'm not convinced I have a long stable career ahead of me in SWE -- I'm 30 now and have already seen so much change in the industry during my professional career.

> how viable the economics are for the LLM usage at this level of assurance and how much ownership you exert over the LLM used or another similarly powered one

This piece scares me the most, a world where the next generation models are capped behind capital infeasible for the common person to access, further separating the ultra wealthy from what little remains of the middle class.

My hope is that open source models will fill the moat all of these AI companies so desperately want to dig, aready models like Qwen and Kimi are unfathomably better than what we had just a year or two ago.

	▲	feanaro 3 days ago \| parent [-]
		> This is the million dollar we'll see answered in our lifetime. Software engineering exists to automate work, are we arrogant to think we are not destined to the same fate? Is this truly a job befitting of a human over an agent? There is a fine distinction here that I believe is often glossed over, so the two things it's delineating get muddled together. One of those two things is coding—the rote, mechanical encoding of meaning into computer instructions. It can be argued the LLM is fit to take this out of hands hands almost entirely, and it's almost indisputable the LLM is better at this in at least a certain sizeable subset of coding tasks. But the other thing is the choosing, determination, specification of the intended meaning itself. This I think is squarely the job of the human, because letting this fall through to the AI means it is no longer the human that is making the decisions. This then becomes not merely automating work but ceding control. This, ultimately, is a bad thing. So if we accept the premise that the specification of the intended meaning is the job of the human, the question is how you do that. Today many of us do it somewhat half-assedly, by writing lots of natural language text at the LLM and hoping it sticks. It is our hope that the text, given that there is a lot of it, will drive the stochastic machine in a sufficiently correct direction. This works to a degree—meaning we've ceded some control but not the majority of it—not least because we still read (most) of the code but cannot work in the limit, if code reading ceases. A more proper way to specify the intended meaning is to specify (or "model") your system formally in a system that is mechanically verifiable. Then the final artefact produced by the LLM can be validated by verifying that it aligns with the specification. However this type of high-assurance specification looks a lot like a certain type of programming. In my opinion, writing this kind of specification is the future of human software engineering. I do not accept the approach of simply rolling the dice and hoping the machine knows better than us, though I'm sure that church is also going to have its acolytes.

▲

skydhash 4 days ago | parent | prev [-]

This behavior is how you get:

> user X reported an issue on the trial balance page, they encountered a blank page when using the inception to date filter.

It’s whack-a-mole with bugs.