Anthropic's CEO says in 3-6 months, AI will write 90% of the code (March 2025)

The question is if (too much) upfront planning is actually better.

IME it's more useful to treat a source file (or new project) like a sketchbook, you start with an empty sheet of paper but already have a rough idea what you want, then you quickly sketch out the outlines, try out different ideas, explore different solutions (all without going into too much detail yet), you step through the code, explore some different paths to get an idea what "feels right", delete things, shuffle them around, rewrite them and slowly filling out the details and that way incrementally get towards the first working version.

Which such an approach of incremental "micro-feedback-loops" you already eliminated a lot of dead ends that will appear anyway despite the best plans - but identifying such dead ends early is much better than late.

This incremental approach also forces you to keep the code small, tidy and malleable. The planning stage basically already happens in source code, and it's not one long planning stage, but many micro-planning-stages.

...this is also my problem with the current state of LLMs, they're pretty good at creating a first initial sketch from a very general problem statement (but only for things that have been done thousands of times by other people - but that's a different issue...) - but the more you'll need to go into the details and discover and fix problems in your initial 'mental design' (e.g. discovering what you actually wanted in the first place), the more the differences to traditional programming disappear, and at some tipping point it gets even more complex because you need to steer the LLM with a language (the human language) that simply isn't useful enough for detailed problem descriptions - that's why lawyers, mathematicians, engineers and scientists all invented their own precise 'DSLs'.

After a few iterations your prompts need to be just as detailed as writing source code in the first place - so what's the point of writing prompts in human language again?

I feel like productivity could be improved much more by improving programming tools (yeah - boring old-school incremental maintenance work) instead of betting on some weird AI future which will just move the focus from writing source code to writing human-language prompts (which IMHO is a definitive step backwards because human language lacks precision - and adding that precision is how you end up with programming languages).

Why are editing, compilation and debugging/testing still separate steps, why do debuggers still have those 60s style bare variable panels instead of realtime visualizations of the internal program state? Why do I still need to wait for a build to finish? Why is version control still such a PITA to work with? Instead everybody is jumping on the AI hype train while everything around them is crumbling into a post-apocalyptic wasteland.

2020. "Based on the above analyses, it is reasonable to expect the hardware that can emulate human-brain functionality to be available for approximately one thousand dollars by around 2020."

https://en.wikipedia.org/wiki/List_of_Tesla_Autopilot_crashe...

Yeah, to be honest I agree. I've worked with senior people who couldn't give a crap, "it works" is the only barrier to shipping it.

I've also worked with juniors who are technically much better than most of the senior people around them.

All senior devs are now junior devs, that’s why we stopped hiring juniors.

Give me them downvotes all you want but I’m not the “senior” turning in slop Llm code.

AI is software, so in a sense everything that can go wrong with AI must be a subset of things that can go wrong with software.

Lots of software has a test environment. Even in live, e.g. bank account losing your money the transactions can be un-wound.

And that's the difference when it comes to replacing software devs with LLMs vs replacing CEOs with LLMs: it's possible to write the tests and then lock them. And to perform code review before changes are merged into the main branch. And to test against something other than production.

I know the Board can in principle remove a CEO, but is there even a standardised way for a CEO to have a vice-CEO that always checks everything they do, that always tests their commands against a simulation of the company and only lets them proceed if they agree with the outcome?

The point is that "AI as CEO" would be in the category of "business-critical" software, and also that current approaches to AI also lack sufficient guarantees of obligation compliance or sufficient defence against failures, which in the banking example would be things like the AI deciding to save money by deleting the system capable of unwinding incorrect banking transactions.

To the extent this kind of failure mode happens with vibe coding (in the original coining of the term: always accept without reading), it's like letting the LLM modify the unit tests to always succeed regardless of the code.

The two contexts where that applies is "interacts with the outside world and you deployed without tests", and "even though it only affects your own data, you don't have backups and you deployed without tests".

I've tried this approach but at some point you're just coding in a less precise language (English), and with more duplication.

My current approach is to stub out the architecture I want, write the type definitions I want in full, and ask Claude to fill in the blanks. It's good at implementing an interface but bad at devising the interface on its own.

Yes, but claude forgets things