That’s where we come in, citizens of the world. They’ll give us free or cheap access to A.I. tools, embed them everywhere and see what we come up with. These things are so powerful and so impressive, they just have to be equally useful, and ultimately valuable. They must be. If you don’t think so, you must be using it wrong. It’s too important not to try. There’s only two left, going fast, buy now.

I guess in some sense that’s not unlike the internet, which is not a product in of itself, but a platform upon which lots of innovation and profit was made. Maybe that’s the case here too?

In this case the profits will be built not only on the effort that went into creating the content they are trained on, but also on the work that will go into figuring out how make them useful.

What’s different about programming?

The main reason why these tools may seem to be better at coding than other tasks is due to constraints. Programming languages have very precise syntax, they have compilers, linters, automated testing frameworks, feedback mechanisms (output, logging, etc.). All of these constraints provide guardrails that keep the LLM’s propensity for hallucination in check. LLM’s can hallucinate incorrect syntax, non-existent api calls (and they often do), but they don’t get far because the code won’t compile. They can hallucinate sloppy code and incorrect implementations, but the linters will alarm, and the tests will fail. Further, these failures provide information back to the LLM’s so they can correct their mistakes (trial and error style) until they get something that compiles, passes static analysis checks, and passes the tests. While these aren’t perfect and don’t guarantee success, they are much more strict and provide much more iterative feedback than a legal document, or medical advice, much earlier and more cost-effectively.

It may not be that they are “better a writing code”, they are just more constrained. Some of their unreliability can be mitigated. That has the advantage of making more sense, as well as demonstrating how they can be made safer both in software development and beyond.

If rather than specifying intent with programming languages, configuration and deployment tools, I can specify my systems with terse natural language prompts spinning up agents capable of generating, managing, deploying and monitoring all of those artifacts, what do I need to be good at?

• Do I need to understand all those technical details (coding, testing, compiling, debugging, deploying) in order to construct prompts, or can I trust the A.I. and not bother with the details?

• Do I need to be able to understand architecture, security and cost trade-offs, or can I prompt an A.I. to generate an architecture?

• Do I need to be able translate business requirements, and technical documents into prompts, or can I feed them directly to an A.I.?

• Do I need to understand the business in order to create business requirements, or can I get an A.I. to generate them?

• Can I prompt an A.I. to do all of that in one step? Can I just provide the business overview, general need, a problem statement?

• Is the only skill required, an ability articulate prompts? What exactly is that skill?

• Can I get an A.I. to articulate prompts? What is the fewest number of prompts I need?

Am I a race car driver with a faster car, or a race car driver with a self-driving car? Am I driving or just telling the car to win the race? What makes me a better race car prompter than anyone else?

I doubt we can get anywhere close to this imagined intent-based world with the current LLM technology but if we could does that seem desirable?

To get that huge productivity boost we’d need to hit the time savers, and avoid the time sinks. Unfortunately the tasks capable of the greatest time savings, by virtue of doing lots of work for us, are the ones that are most likely to generate time sinks when they go awry.

To optimize our productivity, we need to define tasks for the CA that are narrow enough that it is likely to complete quickly and correctly on the first try (or rapidly iterate) and that we can verify efficiently. But that leaves us with a conundrum:

1. A task too narrow is actually less efficient with a CA than without (e.g. renaming a method). The instructing, thinking, editing, summarizing is slower than a typical refactoring tool would be, and carries with it the possibility of error.

2. A task too broad will increase time sink potential.

We need to choose tasks that are narrow enough to have high success rate, and broad enough to accomplish more work faster than could be done without the CA. That’s the goldilocks zone. But even if you hit it, you’d need to string a lot of them together to get to 10X average productivity boost.

How would things look if we used a different term? Assume this new term is just another name for the same LLM systems with the same capabilities that we currently call A.I. What if we called it Advanced Autocomplete (A.A.) or Interactive Autocomplete (I.A.) with its companion Agentic Autocomplete?

It would be more difficult to ascribe intelligence to autocomplete. Afterall we all have experience with the unreliability of autocorrect. Would we be so quick to anthropomorphize consciousness in an autocomplete system? Would we be as concerned that most white collar work could be replaced by autocomplete agents? Would we see huge valuations of autocomplete companies?

Because we so loosely use the A.I. term for all of these tools and systems, the presumption of intelligence get’s smuggled in, and is often conflated with AGI. It causes us to muddle the potential benefit and impact of true A.I.(AGI) with the benefits and impacts of current technology (LLM’s).

Before we can evaluate we need to know what we’re talking about.

Recently, I had a what I thought to be the classic use case for a coding assistant to remove the tedium and do in seconds something that would take me minutes or hours.

Case study

I recently upgraded my application MSTests to the newer Microsoft.Testing.Platform. This migration was done a few weeks back. But it left behind hundreds of analyzer warnings imploring me to adopt the new MSTest conventions.

Ripping through hundreds of tests and swapping out well defined implementations seemed like the perfect use case for a coding assistant.

Take 1

I started out in Visual Studio Copilot with Claude Sonnet 4.5. I instructed Copilot to find and correct all of the MSTest analyzer warnings.

Copilot did a reasonable job of compiling the solution and analyzing the build output to identify the MSTest warnings. It started to replace occurrences of [DataTestMethod] with [TestMethod], which is reasonable. But it got stuck processing for at least twenty minutes. It updated a few dozen occurrences, then declared victory. This was already off-track, because a simple find and replace would have accomplished this in seconds, yet Copilot processed for long durations, and missed a lot of them. I then instructed it to finish the rest. Copilot more or less engaged in the same process of long processing time, fixing a few warnings, and then giving up again declaring it was done. I tried this a few more times, prompting it to finish which it restarted. Eventually Copilot made a change that created a compiler error, and then went off the rails breaking and fixing unrelated things.

I eventually stopped it. This exercise took me a few hours and I didn’t really have anything useful to show for it.

Take 2

I decided to give Copilot CLI with GPT-5-mini a shot. The experience was different but similar. In the first attempt Copilot decided to suppress the warnings rather than fix them. After I rejected the warning suppression change, Copilot then performed like the Visual Studio attempt although it required much more interaction. Copilot stopped frequently requiring me intervene. It often declared it was done. Sometimes it claimed there were no more warnings several times in a row before eventually continuing.

I eventually stopped it. This exercise took me a few hours and I didn’t really have anything useful to show for it.

Take 3

I decided to try Rider with Junie for a completely different tooling perspective. The results were similar. In this case it did seem to successfully perform some edits, albeit extremely slowly, spending hours to get about 20% the way through. It did crash a few times, where I had to intervene and tell it to continue. But like the others, taking too long and needing to be periodically corrected, prompted to continue, or reminded that its not done was not helpful.

Summary

Needless to say these tools did not remove the tedium of a rudimentary task. In fact they failed miserably. Now one could argue it was too many files, or too vague an instruction (I should have told it to use find-replace for example), but isn’t this what its supposed to be good at? If it can’t do this, how much autonomy can we give these things?

Even if it took hours to complete, without requiring intervention, that would have had some value. I could have let it do its work and comeback at then end of the day to find it all done. But they couldn’t even do that.

I often feel like a gambler. When I get the good result in the morning, and the coding assistant does something impressive or makes things easier for me, I should take my winnings for the day and walk away from the table. If I play long enough, inevitably I lose my winnings.

Would I gladly pay for it, or would I decide not to use it?

Presently, there are unnatural economics around these tools. They are produced at great cost, but provided for free or dollars a day. More than provided, they are thrust upon us. I think that should suggest something about their value.

That picture tends to assume a zero sum between employers that will thrive at the expensive of workers. But its a picture that only examines the supply side (labor), what about the demand side (consumers)? What does a company produce that will generate massive wealth without consumers?

If everyone is unemployed, who’s buying tech devices, apps and subscriptions, traveling, dining out, attending events? How am I, as a business owner, going to get rich selling my product to the unemployed masses? Are my products recession proof? Are they great depression proof? Are they great destruction proof?

Do I sell products to others businesses used by a human workforce? What if those businesses no longer have a human workforce? Do I have a government contract? Can the government afford to buy my product when there is no tax base?

Are all these businesses racing towards their own destruction, aggressively adopting the seeds of their own demise? The one dimensional view of employers get rich, workers get poor in the A.I. economy seems too simplistic.

If I’m not ten times more productive and haven’t been able to do and learn things never before possible, it’s because I’m not using it right. Go back to step one. I need better prompting techniques, or I have the wrong combination of tools and models.

But if it’s as powerful as the hype, why do I need to spend so much time learning how to use it and adapting to its peculiarities? The question is three-fold:

1. Shouldn’t it mostly just work? Shouldn’t I be more less able to give it instructions and it do the right thing? Shouldn’t it ask for clarification? Shouldn’t it know and automatically configure whatever tools and dependencies it needs, and know what the latest tricks and techniques are best? Isn’t all this learning and adapting to the tools a drag on productivity?

2. How is it possible to be left behind? Maybe it’s not “there yet” but is getting better all the time. Can’t I just wait until it “mostly just works”, and wouldn’t I immediately catch up? How do I fall behind in a race to democratize programming and obsolesce software engineers?

3. Why do I need to learn a job it knows how to do better than me, so that I can better instruct it to do what I want?

In some sense you’d have to doubt the hype if you’re spending time mastering it. Whatever advantage you’d gain, by your own admission, would be fleeting. If you spend all your time mastering this generation of tools, and I just wait for the next one, won’t I just leapfrog you in an instant? I’d be eleven times more productive! On the other hand, if it’s an expert tool (like a mass spectrometer) only mastered by those in the field, and its somewhat plateaued in capabilities, then it makes sense to master it. But then isn’t it more like a programming language, framework or IDE, reserved and mastered by software engineers, an incremental improvement but not revolutionary?

Setting aside, for the moment, the suggestion that reading, writing, (thinking) are the mundane tasks that we want to be freed from, its unclear to me how having A.I. do things for us is good for learning.

The most common form of the learn faster with A.I. approach is the “summary”. Feeding books, research papers, podcasts, email threads into A.I., and having it provide summaries. The idea being that A.I. can read text faster, and therefore provide all the required information in a quick summary. All the learning, in a fraction of the time.

This would imply that all those books, research papers, podcasts and email discussions are mainly superfluous language. All that bloat can then be stripped out and the core information distilled down like a form of lossless compression. One wonders why the authors didn’t think of that? Imagine how great a movie buff I’d be if instead of wasting time watching movies, I just watched trailers?

As suspect as “summary” based expertise is, that’s not the only flaw. We’re also playing two truths and a lie with the A.I. We know they hallucinate, but since we didn’t actually read anything, we’re very unlikely to catch the lies. We’re asking an A.I. to read and summarize information that we can’t be sure it actually read, or that the summary it produces is true to the source. I guess that’s vibe learning, we’ll know its correct because it sounds plausible?

How well will I retain this information that I didn’t actually read? I guess I can always ask the A.I. for the answers again. Like using a Star trek replicator to learn to cook, I won’t be using my critical thinking, analysis and problem solving skills, so they’ll be out of practice.

Maybe I won’t need those mundane skills anymore, but I will acquire new ones. I’ll need prompting skills, because how I ask the question is just as important as what I’m asking. The butterfly effect of token bias means slight changes in the phrasing or context of my A.I. prompt can lead to different results, making them more akin to genie wishes and incantations, producing answers that are more based on wisdom of the crowd than expertise.

That also means that either I’ve already done the learning, and know what the expected results should be, or I have a feeling what I want them to be, either way I can keep prompting until I get the “right” answer.

While engaging and fun to work with, at least experimentally, I’m not sure that’s quite delivering on the promise. What we really want is the dramatic productivity and business value gains, right?

Well, that’s nowhere in sight. I’ve set it loose on a number of fairly discreet real refactoring tasks or a real codebase, and its slow, error prone, in constant need of correction, sometimes wildly off-base.

The experience reminded me of off-shoring years ago, and it may be analogous in more than one way. The promise of off-shoring was not unlike A.I. coding assistants. It promised access to a dynamic pool of engineering resources that could be scaled up and down according to demand, cheaply. With those resources being in different time zones we could have around the clock coding taking place, and unlock massive throughput.

However, my experience with off-shoring didn’t match those ideals. While they may have been cheap and “easy” to scale, it was not productive. There were language barriers and cultural differences, unfamiliarity with the domain and the code, skill gaps and work hour mismatches, high turnover. There was even the issue of allotting 5 engineers, but really having more than 5 people rotate in and out of the 5 engineer slots, exacerbating the above issues. To overcome this, we needed to spend more time specifying the work, more time reviewing it, explaining it, requesting rework, quality issues, etc. In many cases we had to explicitly provide a pre-coded solution to the off-shore team showing them exactly what to type. Rather than a software production boon it was an inefficiency quagmire.

Agent-mode coding assistance has had that same character for me. A task that I could implement myself in an hour, often takes several hours of me experimenting with the right incantation to get a reasonable solution. Time spent scrutinizing results, trying to nudge it to correct it mistakes, waiting patiently as its slowly “thinking” and slowly altering files, causing compilation issues, and then trial-n-error fixing its own issues. The occasional lies about what it has done or not done, or going wildly off the rails rippling changes that it can’t figure its way out of, sapping trust and confidence a long the way.

Its early, and the vibe coders are vibing, but maybe the analogy is an allegory.

• We’re going be able to thread the needle between making applications that automate a lot of knowledge work and even eliminate entire jobs, but stop short of automating too much, so that we still have enough people employed to keep consuming.

• That public sector jobs can be replaced by A.I. but not private sector.

• That my job can’t be done with A.I., but yours can.

A.I. replacement ground zero

Let’s just take one example, and assume the hype around A.I. code assistants is founded. Assume that A.I. agents are or will soon be able to replace much of the work of software engineers.

It seems unlikely that an A.I. capable of replacing software engineers will only impact the opportunities and salary prospects for software engineers (akin to whale oilers), while leaving the rest of society happily more productive doing the same jobs they are now.

What would we have to assume for that to be true?

• That the reasoning capabilities of a software engineering A.I. agent is extremely narrow and can only think about software engineering problems. It can’t do anything else, not accounting, finance, legal, medical, marketing, advertising, etc.

  • Although somehow they would still be capable of creating applications for use by all of the other disciplines.

• That A.I. agents produce roughly the same quality software at the same pace as a typical engineer.

  • Otherwise, if it produces software substantially better and faster, then the pace of automating larger swaths of other disciplines goes up.

• That A.I. agents can’t produce other A.I. agents.

  • Otherwise a software engineering A.I. agent could produce accounting A.I. agents, etc.

Those don’t appear to be very safe assumptions.

• It is extremely unlikely that the reasoning capability of required to be a software engineer is narrowly applicable.

• Its extremely unlikely that we’d produce a one-for-one replacement of software engineer with A.I. agent. More likely we’d be replacing one engineer with hundreds or thousands A.I. agents, capable of working 24x7 at light speed.

  • The only limiting factor being compute resources and the cost of those resources.

• With an explosion of A.I. agents working around the clock we’d be looking at exponential growth of software automation. It seems highly unlikely that other jobs wouldn’t be automated out of existence too.

  • As we automate other disciplines, who’d be left to use products like MSOffice? A.I. agents certainly don’t need to communicate via word documents and spreadsheets. Business software used by people would cease to exist, because there’d be no one left to use it.

Knowledge workers can be replaced, but the trades will still be safe.

There’s another set of assumptions required to believe the common refrain, that working in trades like plumbing will be safer than knowledge work.

We’d have to assume:

• A.I. agents can’t be used to create robotics capable of replacing plumbers, electricians, etc.

• Plumber and electrician will still be good paying jobs when all knowledge workers are either unemployed (can’t afford to pay a plumber) or competing for the plumbing jobs.

Those assumptions don’t appear any safer.

The same could be said of executives and managers, who imagine themselves similarly to be immune.

• There’s not a strong reason to believe management can’t be done via chat bot, nor that if that’s the only job left, it won’t be super competitive.

Logical conclusions

Simply following the logical conclusions of A.I. hype and the implications quickly leads to some pretty radical impacts on society. Either we don’t really believe the hype or we haven’t really thought through the ramifications.

And that’s without even considering the more academic concerns:

• What happened to containment?

• What are the moral implications of a massive A.I. slave labor force, that doesn’t question, whistle blow, or otherwise resist questionable or unethical instructions?

• Monoliths are the future – Always a fan of contrarian opinions.  Like any good tech. fad, microservice  backlash is coming.

• Is Working Remotely Effective? Gallup Research Says Yes

• Individual Performance Appraisals, Just Say No!

• ConfigureAwait FAQ

• 2020 Tech Predictions

• Promiscuous Cookies and Their Impending Death via the SameSite Policy

• The Psychological Reasons of Software Project Failures

• The Fall of The Software Engineer, The Rise of The Programmer Technician