We’ve long since proven that machines are better for back-breaking labor.

I also disagree that AI will offset the majority of big brain jobs. What’s actually happening is AI is offsetting the majority of narrowly defined queries. The more open ended problems require an actual understanding of problem solving rather than a really clever text prediction engine.

Some examples to illustrate my point:

If you wanted to build a mobile app, you’d need to first:

- understand the problem you’re trying to solve (is it a game? A medical app? A productivity app? Etc)

- choose a frontend stack

- create a design language

- create wireframes

- decide where to host the backend stack (eg self hosted? Or public cloud? If so, which?)

- decide which cloud services to use (if public cloud)

- decide on how to approach IaC

- decide on the backend stack

- decide on how to implement your CI/CD pipelines (or even if you want continuous delivery)

- understand what privacy and security concerns you have and identify what risks you’re willing to accept

- define testing strategy’s

- define release cadences

And so on and so forth.

Writing the code is often actually the easiest part of software development because we already understand the problem by that point. The rest of the work is figuring out all questions that need to be answered — and I don’t even mean answering the questions, I mean understanding what questions to ask.

AI can’t do that. GenAI requires human input and much of software development is actually figuring out what those inputs should be rather than generating that output.

So that’s what I mean by “big brain jobs”. It’s not writing code, because that’s easy. It’s understanding and defining those requirements to begin with.

> We’ve long since proven that machines are better for back-breaking labor.

This is contrary to my perception of current trends (and to a perhaps generous reading of Moravec's Paradox). Dexterous manipulation is still quite hard which is why a task like laundry folding is so impressive despite being relatively simple for many humans: https://www.physicalintelligence.company/blog/pi0

Perhaps we disagree on what "back breaking" entails but I'd much rather spend all day coding than folding laundry!

Yeah I definitely wouldn’t class laundry folding as “back breaking”. But I agree it is manual labor that’s difficult for current robotics.

There have been some advancements in this specific field though. So we might see a mass-produced robot that can do this in our life time. If not for homes then certainly for industrial workflows (dry cleaning services, new workflows for clothes manufacturing, etc)

There's no reason AI couldn't do that too. It will continue moving up the cognitive ladder: there's nothing special about our ability to ask those questions.

For example, try asking Claude "what decisions do I have to make when building a mobile app?" It gave me a list that looked quite a lot like yours, which I then asked it to compact into a single paragraph:

> When building a mobile app, you'll need to decide between native or cross-platform development (React Native, Flutter); which platforms to prioritize; backend infrastructure; offline capabilities; data storage approach; UI/UX design system; monetization strategy (free, freemium, subscription); launch approach; ASO strategy; budget allocation across development, design, and marketing; timeline with clear milestones; team composition requirements; and legal compliance needs including privacy policy and relevant regulations like GDPR.

and of course, I can ask it to answer those questions for a given app. People have written about this, but the ratio of "input amplification" is only getting larger: in the future, you will be able to ask for a multiplayer 3D chess game with native Android and iOS clients with branching timelines, and it'll write every bit of code for you, while asking you about important decisions.

(See also Claude Code and similar agents.)

Sure people have written about it but the LLM is only returning text that’s already been written with zero reasoning.

What solution architects, devops engineers, etc get paid for is their experience.

There is a saying that goes “the devil is in the detail” and that applies here. Everytime someone says “I created x using AI” it’s because they’ve been able to feed the LLM pointed questions and have been able to understand when the LLM was rattling off nonsense.

And your counter argument there still falls back to the “writing every bit of code” which I’ve already said is the easy part of software development.

I’m sure at some point AI will be able to reason about problems but that’s when they shift from being specialised AI to AGI. And I don’t for one second believe we are as nearly as close to AGI as Sam Altman wants his investors to believe.

I would encourage you to try out a recent reasoning model like Claude 3.7 Sonnet / o3-mini / R1. No, it's not perfect, but it can very much architect and design things at a higher level than you might think. This is already taken advantage of by Aider, which has a mode that splits the tasks: https://aider.chat/2024/09/26/architect.html

My point isn't that it's perfect today, but it's already further along the trajectory than one might think.

I use LLMs for brainstorming all the time. It’s probably my favourite use of them. But I always fallback to the same problem: with an open ended question there’s a higher probability of hallucinations. So I still have to spend the time separating out the good responses from that rubbish.

You could liken it to a good solutions architecture vs a bad one.

A bad one will cost your business time, effort and money. A good one will not.

If I were to trust the LLMs output verbatim then I’d have made so many bad decisions. But I have the experience to identify what’s correct and what is not.

> No, it's not perfect, but it can very much architect and design things at a higher level

Exactly. I keep making the point that the real test of a competent engineer is understanding the details. And there are a lot of details which are highly context specific in any given software project.

Where LLMs will thrive in software projects is solving easy problems or problems that have already been solved a thousand times over (eg how to architect a blog) and solving highly specific and narrowly defined problems (eg write code that does X).

Maybe I’ve been blessed in my career, but most software projects I’ve worked on have brought something innovative and new to the table (and I don’t mean the “we are changing the world” meme that’s often cited by SV startups — I do literally mean something new to the industry). So LLMs would have a pretty poor success rate under those conditions.