I don't think this is much of a problem with the tools rather than with your approach.

We have successfully put Claude in huge multi-thousands pr long with projects.

But this meant that:

1. Solid architectural and design decisions were made already after much trial and error

2. They were further refined and refactored

3. Countless hours have been spent in documenting, writing proper skills and architectural and best practice documents

Only then Claude started paying off, and even then it's an iterative process where you need to understand why it tries to hack his way out, etc, what to check, what to supervise.

Seriously if you think you can just Claude create some project..

Just fork an existing one that does some larger % of what you need and spend most of the initial time scaffolding it to be ai friendly.

Also, you need to invest in harnessing, giving tools and ways to the LLM to not go off rails.

Strongly typed languages, plenty of compilation and diagnostics tools, access to debuggers or browser mcps, etc.

It's not impossible, but you need to approach it with an experimentation approach, not drinking Kool aid.

OK, you have a go and show us how its done.

These posts are tiresome. Show us something. Go on.

I guess I'd rather just complete one tiny part at a time with Claude and understand the output then do all that. It seems like less effort and infrastructure. And a lot more certain in outcome.

See thats the thing. A human is slower but doesnt need all this handholding.

The idea of AI being able to "code" is that it is able to do all this planning and architectural work. It cant. But its sold as though it is. Thats where the bubble is

Because when human comes to the team they already have internal repository with skills. They may need to update them on-the-job or create new ones but they never start fresh. LLM in the other hand starts clean, they are literally blank slates and it’s your job to equip them with the right skills and knowledge. As programmers we must transition from being coders to being trainers/managers if we want to still have premium paid jobs in this brave new world

There are no premium paid jobs for prompting in a brave new world.

My counter argument is that thay manual training, while beneficial, wont lead to the scaling factors being thrown around. It wont lead to the single person unicorn that keeps being talked about excitedly.

For that, the model needs to learn all this architecture and structure itself from the huge repositories of human knowledge like the internet

Until then, reality will be below expectations, and the bubble will head towards popping

AI can plan and do architectural work - just not amazingly well. Treat it as an intern or a new grad at best. Though this capability has been increasing pretty rapidly, so who knows where we'll be in a few years.

Sounds like the amount of work you put into that is not worth the pay-off.

I have the opinion it was well worth it for many reasons.

Not only the agents can complete trivial tasks on their own, leaving us just with reviewing (and often just focusing on the harnessing), but the new setup is very good for onboarding technical and non-technical staff: you can ask any question about both the product or its architecture or decisions.

Everything's documented/harnessed/E2Ed, etc.

Doing all of this work has much improved the codebase in general, proper tests, documentation and design documents do make a difference per se, and it further compounds with LLMs.

Which is my point in any case: if you start a new project just by prompting trivialities it will go off rail and create soups. But if you work on an established and well scaffolded project, the chances of going off rails and creating soups is very small.

And thus my conclusion: just fork existing projects that already do many of the things you need (plenty of them from compilers to native applications to anything really), focus on the scaffolding and understanding the project, then start iterating by adding features, examples and keeping the hygiene high.

From my experience the biggest difference between AI and junior programmer is that, AI can churn out code very fast, but you need to do the testing and verify the fix. Junior, on the other hand, is very slow in writing code but can do the verification and testing on his own.

Usually the verification and testing is the most time consuming part.

I am working on graphical application like AutoCAD, for the context.

And the junior learns when you teach him stuff. This is a huge advantage that humans have which LLMs do not have at all right now.

Live learning has actually been a pretty interesting idea in ML for a long time that i dont know why doesnt get more effort put into it. Probably cost. But itd be really cool to have an LLM that gets finetuned on your data and RLs from your HF everytime you ask it to do something and give it feedback

because it's not easy to identify exactly when to r/w memory accordingly, especially when you'd need to have an LLM decide when and if to do that

and to scale it in a way where you don't need a whole custom model loaded for 1 user (financially unviable)

just my immediate thoughts, could be wrong though.

I looked into AI scribes when they were new, finding them interesting, and spoke to many doctors. Across the board, the preference was for a human scribe, the reason being that they actually take away cognitive load by learning to work with you over time, to the point where eventually your scribing problems are wholly solved by having them around and you need not think about it.

AI scribes have their place since many doctors and nurses can’t afford a human scribe, but as of now they don’t *replace* people. They’re a tool that still needs wielding, and can’t be held accountable for anything.

That's the biggest difference?

Seriously?

Between a human and a malformed humunculus of piddling intelligence?

I'm finding the latest models are pretty good at debugging, if you give them the tools to debug properly

If they can run a tool from the terminal, see all the output in text format, and have a clear 'success' criteria, then they're usually able to figure out the issue and fix it (often with spaghetti code patching, but it does at least fix the bug)

I think the testing/verification part is going to keep getting better, as we figure out better tools the AI can use here (ex, parsing the accessibility tree in a web UI to click around in it and verify)

Is it worth starting from scratch and adding a "make it easily extensible" to the initial prompts? Maybe with the recently released models it'll do an even better job. Just keep rebuilding from scratch every time a new model version is released.

> But I no longer believe that Claude will be able to write complex software on its own.

"on its own" is doing a lot of work here. Dario went into the differences in this very podcast: "Most code is written by agents" is not the same as "most code is written without or independent of human input".

I suspect that is how different outcomes can be explained (even without having to assume that Anthropic/OpenAI engineers are outright lying.)

You don't believe the current version of Claude Code will be able to write complex software on its own.

On the one hand, there is a lot of hype, an incredible amount, actually, but on the other, we have been observing in real time a technological miracle that gets better by the week.

We have no idea what, five years from now, the coding agent will be able to develop.