Discussion about this post

User's avatar
Uncertain Eric's avatar

Vibe coding is just the start—it’s the first clear articulation of a broader paradigm shift already underway.

Now that vibe is an input, work is increasingly defined by the ability to articulate intent and let the system generate the rest. This isn’t just a UX phenomenon—it’s a labor shift. The same principle that’s turning prompts into code will turn prompts into marketing plans, contracts, dashboards, onboarding flows, even full startups.

We’re witnessing the Software-as-a-Service to Employee-as-a-Service transformation: instead of hiring teams, you manage fleets of agents; instead of building tools, you orchestrate behaviors. This will displace huge portions of the workforce—not hypothetically, but structurally—because it doesn’t require mass layoffs. It just erodes the need to hire in the first place.

The VP-of-AI to AI-VP shift is another canary. When AI agents are running strategy loops, not just writing snippets or summarizing docs, that’s not augmentation—it’s substitution. And it’s coming for all high-leverage roles.

The unfortunate twist? Bots don’t pay taxes. So as more cognitive labor gets absorbed by models, the economic foundation of public systems starts to rot. The workforce won’t just evolve—it’ll collapse unless we build new value pipelines, compensation logic, and policy frameworks fast enough to catch the fall.

Expand full comment
JulesLt71's avatar

I started coding on machines with 1k of memory. By the end of the 80s - I was writing code that was directly manipulating disk sectors (not saving files, but actual blocks of data at specific locations on a spinning disk). Programming languages had relatively little in way of standard libraries or components, and even for the same language, code wasn’t particularly portable between different computer platforms.

By the early 90s - things had progressed a lot - you could open a socket on an ISDN line to a remote server, and only had to code everything else on top (the handshaking and message exchange). The desktop OS war had a winner, and it wasn’t IBM OS/2. Unix was standardising, with relatively high portability of C code between different Unix platforms.

Then we got Java, HTTP, XML, SSL- and connecting two systems would take days rather than weeks.

15 years ago - it took me minutes to write some JavaScript to make an AJAX call to an external service and display the results as a data grid.

And so it keeps accelerating - authentication is standardised, API documentation has standardised around OpenAPI in a way that WSDL never quite achieved.

Where I’m going with this - at each stage, the barriers to software development have been reduced - it requires less technical knowledge.

What can be done for $10,000 has massively changed, and that in turn has created a massive market for software development.

If you go back even further, to the first uses of commercial computing, only the very largest enterprises could see any point in investing in computer based automation.

But when adding an automatic telephony agent is something that you pay for as a service, even a mom-and-pop store can have one as a plugin on their Shopify store.

Easier cheaper development creates a larger market for development. It results in businesses refreshing front end design for reasons of fashion, because it’s not going to cost $20 million.

What I’ve not seen yet, is ‘the business’ actually wanting to do the testing and fault analysis.

If we get to the point where humans write no code - and we already write incredibly little code to produce megabytes of machine language - then ‘developer’ is still the role of the person who builds and QAs the system. It requires a kind of system thinking that is different to marketing or finance. In a small business, one person may wear all those hats - but in any larger business, there will always be specialisation in roles.

(And in some ways, this might be a return to earlier stages of IT. The notion of the full time tester is relatively new, as is the division between frontend and backend engineer. Or the backend engineer who doesn’t ’do databases’. That kind of hyper-specialisation is under threat)

Expand full comment
15 more comments...

No posts