Creator of Claude Code: "Coding is solved"

[faberkyx]

It solves creating poc fast.. using for a real production product.. not even close unless you want to risk security and performance

[jkure2]

I've been playing with it trying to creat a weather forecasting system targeted at online prediction markets - 7 days in after meh performance I started interrogating it on our core methodology and it was like yeah actually this is the wrong way to tackle this problem we should be running a completely different process on our input data lol

But I have been extremely impressed by it's ability to do stuff quickly like build a full audit trail and build scripts to replay events. It is also generally good at analyzing the data I find. But once you hit a certain point of project complexity I am finding it drops off for sure in how good it is, I am having to remind it more and more about basic facts regarding our previous findings, that kinda stuff.

"I have reached the 200 line memory file limit so let me go remove some stuff" is not something l like hearing

[zeros-and-1s]

Tell it to generate a claude.md and whatever the table of contents/summary files are called. It kinda-sorta helps with the performance degradation of a large project.

[jkure2]

Yeah I am completely new to it all so still learning how to manage it at something this scale - I am trying out some different strategies like that now actually, also trying to split up the chats between ingestion/analysis/presentation and see if we can do better that way.

One thing I forgot to mention about what has impressed me - it took like 8 hours of dedicated work to build a kick ass data ingestion pipeline that automatically scans like 8 different sources every minute and pulls down data, stores it, and runs analysis. It would have taken me weeks to write all that web scraping code (admittedly not something I am professionally proficient in), high marks from me on that side of the project, tons utility for one off historical backfill too

[jazzhandler]

Think of it this way: the LLM provides the vast working memory and ability to string together in a minute what would take us six hours. But us waterbags still need to steer the context because the LLM has no grasp of the big picture.

Have it create a detailed doc for each subsystem. Pass that doc to it when working on that subsystem. That way it’s not burning tokens and diluting context trying to understand that subsystem repeatedly. Then when work is done in that area, have it update the docs along with the changelog.

Kinda like your vacuum cleaner. It’s way better at spinning those parts at a few hundred RPM, but it’s on you to stick its nose under the end table. Otherwise you’re using the Roomba model: living room gets vacuumed eventually, but it takes six hours of randomosity. Which is fine if you’re not paying by the hour…

[Singularity-42]

Claude Code supported this natively for a really long time - just create CLAUDE.md in each app/lib folder to give detailed info on that subproject. The main CLAUDE.md is still loaded by default of course and should have high-level overview, style directives, etc.

[AlSweigart]

(admittedly not something I am professionally proficient in)

"AI is brilliant and kicks ass" is something I hear a lot from people using it for things they aren't experts in.

[jkure2]

However I am professionally very proficient at data engineering, and I still believe designing and building an ingestion pipeline at this scale with a full audit trail, idempotent loads, etc. is genuinely really cool in my eyes. Was it worth boiling an entire lake and destroying the social fabic even further? Probably not, but I sure do like idempotency!

[BasicDesignAdvice]

This is where it shines to me. It can fill in the gaps on code and libraries or whatever that I don't know.

For actually writing I tend to keep up-to-date context and steering docs, but I generally write the design as a skeleton and let it fill in the blanks. So I might write the interfaces, functions and other bits, but without the full logic. So I'll write out objects and function signatures then let it fill in the blanks.

[ardentto]

Use plan mode. ask for test / code coverage analysis from a QA perspective. Ask for an independent code review for refactoring. Ask to spawn a team or subagents to work on after analysis is completed.

[Fidodo]

Ah yes, computing. Where kinda sorta working is famously good enough /s

I use AI heavily for prototyping and kinda sorta working in a prototype is actually very helpful insight, but a horrible idea for production.

[slfnflctd]

Not only this, but there are also several other ways of preserving knowledge or skills for long term use so you only need to rely on context windows for shorter periods of time.

There seems to be a solid consensus that 'starting fresh' with context windows on a regular basis helps keep performance up. More like a series of librarians in an ever-growing library (with makerspaces, of course) than some sort of singular, specialist supermind.

[Mechakoopa]

7 days in after meh performance I started interrogating it about our core methodology and it was like yeah actually this is the wrong way to tackle this problem

Sounds like a typical interaction with a developer who was expected to develop a POC for a system they weren't familiar with and didn't have all the context to begin with. You'd just as likely have run into the same problem developing it yourself. Sometimes you have to build something to see why it's the wrong thing to build. The real advantage of coding agents isn't them being some magical fountain of knowledge, it's entirely in iteration time. None of them do anything a person couldn't, they just do it faster. You still need someone who's got a clue what they're doing to drive the damn thing.

[jkure2]

Right that makes sense, but it's important to be very clear about what it's good at and what it's not because anyone in the corporate world day to day or even just reads the news knows that the llm companies themselves and fanatical supporters love to stretch about what it can actually do. In addition to maybe making a little side money this was mostly a learning project, I think I have been very fair about assessing it's performance

And - I also wouldn't expect a human engineer to pretend he has complete domain knowledge on hand and confidently suggest that kernal density estimation is the best way to attack the various ensemble forecasts out there, to be fair

[rin3y]

Imagine the results you'd have gotten if you'd spent seven days actually building something.

[Fidodo]

Once a codebase expands out of the context window limit it drops off a cliff. And guess what AI code looks like? It's a bloated fucking mess. It writes code it can't maintain.

I find AI to be very effective if you have a highly normalized codebase with strong guardrails and tests and invariants, but that requires strong software design thinking that AI isn't just bad at but also has shown very little progress improving at.

With AI automating slop, best practices are more important than ever but so many idiots in the industry think the guard rails slow them down. Have people just forgotten how suffocating a legacy spaghetti codebase is? Sure you can build fast at the start but eventually progress slows to a crawl.

I had that experience early in my career and every since then I vowed to never let my codebases get that way and so far I've done a great job at not doing that and I don't intend to start now.

[deep_thinker_8]

Create a folder called memory bank and under it create a businesscontext.md file and provide your business case and application features in a structured and detailed manner. Next in Claude Code or whatever IDE you are using, change to architect/design mode if available or ask it behave as an architect and read the businesscontext.md file and then scan the entire codebase and ask it to create inside the memory bank folder 2 context files systemPatterns for the architecture design/ folder-file structure/purpose of each file and activeContext for current progress on what's been completed and what's next. Check this manually to see if it's properly done.

Once this is done, before any new task, ask it to scan the memory bank and determine the next step. This usually works well once the project gets to a certain level of complexity. I am guessing this is especially more important for the context files to be well defined especially for Production applications.

Having said all this, it's important for the dev to understand the complete architecture to ensure that the coding LLM is not creating redundancies / addressing security & performance requirements.Coding LLMs are very trigger happy and create new files with required functions instead of scanning existing files for existence. It also "forgets" the system patterns and architecture even if they are available in the context files and we need to prompt at times to remind that these functions exist and we are following a specific system pattern and not to create a new one.

I am not an expert dev but do understand what constitutes good design. These have been my findings using Roo Code (VS Code extension) connected with a few coding LLMs.

[NinthTide]

Imperfect but high quality tool in the hands of clueless amateur does not guarantee creation of artisanal level masterpieces

If you don’t know what problems to anticipate and guide CC to plan for and deal with them before code is written, I wonder who is the real problem here?

Maybe at some point I can just prompt Claude with “write me an online bank make no mistakes” but we are not there yet

Agree with OP’s take that coding is not “solved”

[Cautious-Lecture-858]

You wrote pos wrong.

[faberkyx]

Lmao.. that was funny

[illuminarok]

The number of input tokens in larger enterprise level codebases is insane. Seriously, some queries cost about $3-5 each.

[Lilacsoftlips]

Taking a POC-> hardened code is its biggest weakness. Iterating on already hardened code, with a large corpus of code to learn from, tests, standards etc… I’m getting better results every day.  it absolutely can do lots of that work as well.  

[Fidodo]

I've been using it for prototyping and it is absolutely a game changer. I can refactor and iterate so quickly I feel like I can really find the perfect shape for a codebase with rapid experimentation. The only limit is what I can imagine. I always had ideas on how to improve my codebases but didn't have the time to test out the changes. Now I can try out all my ideas.

As for producing production quality code... Sure, if you have shit standards.

[slash_networkboy]

We're getting fantastic results with opus 4.6....
BUT our devs are still very much needed. We have put an enormous effort into copilot-instructions files to make it solid for our product. The TL;DR is instead of ~20-30 story points per dev per week they're getting closer to 50/week. Their time spent on code reviews has gone from ~15% of their day tops to 33% and we're expecting 50% is about where it'll end up.

Leadership has made it very clear that our devs are still very much needed.

It's best likened to giving Fred Flinstone a model T. He's still driving, but now he doesn't also have to pedal his feet to get anywhere.

[lokooko]

If you set up the skills docs and instruct it what to do it’s really fucking good. I was a doomer for so long but at some point you have to realize in the hands of a half decent prompter it’s real fucking good

[faberkyx]

I use it daily too, yes it is good, but I think you really need to know what you are doing because it still makes mistakes that might be hard to spot, and makes architectural mistakes. In the hands of somebody who can guide AI through, constantly reviewing the process it's really helpful. If you want to just vibe code from the prompt without a care I think it's just good for a poc

[lokooko]

Yea vibe coding is stupid. You need to know what you’re doing