I thought the difference must be in how Claude Code does the agentic stuff - reasoning with itself, looping until it finds an answer, etc. - but I have spent a fair amount of time with Claude Code now and found that agentic experience to be about the same between Cascade and Claude Code.
What am i missing? (serious question, i do have Claude Code FOMO like the OP)
What AI have you been using for 5 years of coding?
side note, I’ve been trying to remember when it launched internally if anybody knows. I feel like it was pre-COVID, but that’s a long timeline from internal use to public preview
> a) never plan on learning and just care about outputs, or
> b) are an abstraction maximilist.
As a Claude Code user for about 6 months, I don't identify with either of these categories. Personally I switched to Claude Code because I don't particularly enjoy VScode (or forks thereof). I got used to a two window workflow - Claude Code for AI-driven development, and Goland for making manual edits to the codebase. As of a few months ago, Claude Code can show diffs in Goland, making my workflow even smoother.
Always curious to hear how individuals have their workflows, if you don’t mind sharing.
I think this is where things will ultimately head. You generate random code, purely random in raw machine readable binary, and simply evaluate a behavior. Most random generated code will not work. some, however, will work. and within that working code, some will be far faster and this is the code that is used.
No different than what a geneticist might do evaluating generated mutants for favorable traits. Knowledge of the exact genes or pathways involved is not even required, one can still select among desired traits and therefore select for that best fit mechanism without even knowing it exists.
I remember when people said Open Office was going to be the default because it was open source, etc etc etc. It never happened. Got forked. Still irrelevant.
And how is this different than the process of natural selection? More fit ideas win out relative to less fit and are iterated upon.
Second, there are other algorithms that constructively find a solution and don't work at all like genetic algorithms, such as mathematical solvers.
Third, sometimes, a design is also simply thought up by a human, based on their own professional skills and past experience.
Natural selectiom:
- is not an intentional process
- does not find "the strongest the fittest the fastest etc."
However your starting definition was more limited. it was specifically about "creating candidates at random, then just picking the one that performs best" - and that's definitely not how airplanes are designed.
(It's not even how LLMs work, in fact)
I think we need to think outside the box here and realize ideas can be generated, evaluated, and settled upon far faster than any human operates. The idea of doing what a trillion humans evaluating different functions can do is actually realistic with the path of our present technology. We are at the cusp of some very remarkable times, even more remarkable than the innovations of the past 200 years, should we make progress on this effort.
But I hope we have more efficient ways to do this in a century.
A trillion is 8 symbols. You still haven't reached the end of your first import statement.
I just took a random source file on my computer. It has about 8000 characters. The number of possible files with 8000 characters has 12500 digits.
At this point, restricting the search space to syntactically valid programs (how do you even randomly generate that?) won't make a difference.
Code derived from a training set is not at all "random."
This has been tried. It tends to overfit to unseen test environment conditions. You will not produce what you intend to produce.
> the massive compute capability we will have
Just burn carbon in the hopes something magical will happen. This is the mentality of a cargo cult.
This doesn't work when the software in question is written by competent humans, let alone the sort of random process you describe. A run of the software only tells you the behavior of the software for a given input, it doesn't tell you all possible behaviors of the software. "I ran the code and the output looked good" is no where near sufficient.
> We've actually done this before in our own technology. We studied birds and their flight characteristics, and took lessons from that for airplane development.
There is a vast chasm between "bioinspiration is sometimes a good technique" and "genetic algorithms are a viable replacement for writing code".
And with future compute, you will be able to evaluate behavior across an entire range of inputs for countless putative functions. There will be a time when none of this is compute bound. It is today, but in three centuries or more?
Yes, and our species is a fragile barely functioning machinery with an insane number of failing points, and hillariously bad and inefficiently placed components.
Humans are expensive but this approach seems incredibly inefficient and expensive. Even a junior can make steady progress against implementing a function, with your approach, just monkey coding like that could take you ages to write a single function. Estimates in software are already bad, they will get worse with your approach
But that's future music, forgive a young man for letting his imagination run wild! ;)
One big advantage of this future random walk paradigm is you would not be bound by the real world constraints of sample collection of biological data. datasets could be made arbitrarily large and cost to do so will follow an inverse relationship with compute gains.
In this situation, AI companies are incentivised to host the services their tooling generates. If we don't get source code, it is much easier for them to justify not sharing it. Plus, who is to say the machine code even works on consumer hardware anyway? It leads to a future where users specify inputs while companies generate programs and handle execution. Everything becomes a black box. No thank you.
Tell me you know nothing about modern agriculture without telling me that
Customers.
When you sell them a technological solution to their problem, they expect it to work. When it doesn't, someone needs to be responsible for it.
Now, maybe I'm wrong, but I don't see any of the current AI leaders being like, "Yeah, you're right, this solution didn't meet your customer's needs, and we'll eat the resulting costs." They didn't get to be "thought leaders" in the current iteration of Silicon Valley by taking responsibility for things that got broken, not at all.
So that means you will need to take responsibility for it, and how can you make that work as a business model? Well, you pay someone - a human - who knows what they're looking at to review at least some of the code that the AI generates.
Will some of that be AI-aided? Of course. Can you make a lot of the guesswork go away by saying "use commonly-accepted design patterns" in your CLAUDE.md? Sure. But you'll still need someone to enforce it and take responsibility at the end of the day if it screws up.
Today you send some money to your spouse but it's received by another person with the same name. Tomorrow you order food but your order gets mixed up with someone else's.
Tough luck, the system is probabilistic and you can only hope that the evolutionary pressures influence the behavior to change in desirable ways. This fantasy is a delusion.
Yes a function will always do "the exact same thing" at runtime, but that "thing" isn't guaranteed to be free from race conditions and other types of bugs.
Whatever gets generated, if it passes tests and is observably in compliance with the spec, is accepted and made permanent. It's the clay we're talking about Jackson Pollocking, not the sculpture.
> observably in compliance with the spec
That's so easy to say and so incredibly hard to implement! Most unintended behaviors will never end up being prohibited/defined in the specification written by non-programmers.
The act of translating requirements from human language into well-defined semantics is what programming is.
You also no longer need to work, earn money, have a life, read, study, know anything about the world. This is pure fantasy my brain farts hard when I read sentences like that
This will be reality in 10-20 years
Sure, the information is all there, but the style just puts me off reading it. I really don't like how few authors have a voice any more, even if that voice is full of typos and grammatical errors.
I have a BIRTHING_POOL.md that combines the best AGENTS.md and introduces random AI-generated mutations and deletions. The candidates are tested using take-home PRs which are reviewed by HR.md and TECH_MANAGER.md. TECH_MANAGER.md measures completion rate per tokens (effectiveness) and then sends the stack ranking of AGENT.mds to HR to manage the talent pool. If agent effectiveness drops low enough, we pull from the birthing pool and interview more candidates.
The end result is that it effectively manages a wider range of agent talents and you don't get into these agent hive mind spirals you get if every worker has the same system prompt.
> 1. my experience from 5 years of coding with AI
It is a testament to the power of this technology that the author has managed to fit five years of coding with AI in between 2023 and now
And produce nothing of substance besides more incestuous content about AI and AI-development.
wow
That being said, after seeing inside a couple YC backed SaaS companies I believe you can get by without reading the code. There are bugs _everywhere_, yet one of these companies made it years and sold. Currently going through the onerous process of fixing this as new company has a lot of interest in reducing the defect count. It is painful, difficult, and feeling like the company bought a lemon.
I think the reality is there’s a lot of money to be made with buggy software. But, there’s still plenty of money in making reliable software as well (I think?).
LLM denialists were always wrong and they should be embarrassed to share their bad model of reality and how the world works.
You mean people who don't like statistical models trained on random code, with no oversight or vetting of the training material?
No, we're still the majority.
Please stop sending PRs to open source projects that are just thousands and thousands of lines of random slop. We're tired of seeing them.
Claude Code was transformative and it made me realize that something very incredibly significant had occurred. Letting the LLM "drive" like this was inevitable. Now I see just exactly how this will transform our industry. I'm a little scared about how it will end for me/us, but excited for now.
Letting an LLM drive in an agentic flow removes you from the equation. Maybe that's what some want - but I've personally found I end up with something that doesn't feel like I wrote it.
Now... get off my lawn!
On a more serious note, I do think that the maintenance aspect is a differentiator, and that if it’s something that you end up committing to your codebase then ownership and accountability falls to you. Externally sourced libraries and frameworks ultimately have different owners.
I catch a lot of nonsensical and inefficient code when I have that "back and forth" described above - particularly when it comes to architectural decisions. An agent producing hundreds or thousands of lines of code, and making architectural decisions all in one-go will mean catching those problems will be vastly more challenging or impossible.
I've also found reviewing LLM generated code to be much more difficult and grueling than reviewing my own or another human's code. It's just a mental/brain drain. I've wasted so many hours wondering if I'm just dumb and missing something or not-understanding some code - only to later realize the LLM was on the fritz. Having little or no previous context to understand the code creates a "standing at the foot of Mt. Everest" feeling constantly, over and over.
It's only for a fraction of the price, but 3 times as much limits.
I currently use github subscription for hobby projects.
But I will probably check out claudecode next month when my github copilot subscription runs out.
Edit: I found this: https://www.reddit.com/r/ClaudeCode/comments/1q6f62t/tried_n... Seems like it might be worth to check it out. Found a 10% discount that works on the additional discount so now it would be 26 USD / year.
I needed a poc RAG pipeline to demo concepts to other teams. Built and tested this over the weekend, exclusively with Claude Code and a little OpenCode. Mix of mobile app and breaking out Android terminal to allow Sonnet 4.5 to run the dotnet build chain on tricky compilation issues.
Why would that be any harder than a React app? At least for me having an LMM produce a decent and consistent UI layout is not that straightforward
tuckwat•9h ago
Maybe for a personal project but this doesn't work in a multi-dev environment with paying customers. In my experience, paying attention to architecture and the code itself results in a much more pliable application that can be evolved.
madrox•9h ago
AIorNot•9h ago
the OP is a kid in his 20s describing the history of the last 3 years or so of small scale AI Development (https://www.linkedin.com/in/silen-naihin/details/experience/)
How does that compare to those of us with 15-50 years of software engineering experience working on giant codebases that have years of domain rules, customers and use cases etc.
When will AI be ready? Microsoft tried to push AI into big enterprise, Anthropic is doing a better job -but its all still in infancy
Personally for me I hope it won't be ready for another 10 years so I can retire before it takes over :)
I remember when folks on HN all called this AI stuff made up
madrox•9h ago
I do think you're missing how this will likely go down in practice, though. Those giant codebases with years of domain rules are all legacy now. The question is how quickly a new AI codebase could catch up to that code base and overtake it, with all the AI-compatibility best practices baked in. Once that happens, there is no value in that legacy code.
Any prognostication is a fool's errand, but I wouldn't go long on those giant codebases.
AIorNot•8h ago
“prediction is hard especially about the future” - yogi berra
As a hedge - I have personally dived deep into AI coding, actually have been for 3 years now - I’ve even launched 2 AI startups and working on a third - but its all so unpredictable and hardly lucrative yet
As an over 50 year old - I’m a clear target for replacement by AI
tacker2000•1h ago
No mention of the results when targeting bigger, more complex projects, that require maintainability, sound architectural decisions, etc… which is actually the bread and butter of SW engineering and where the big bucks get made.
KellyCriterion•1h ago
Caught you! You have been on HN very actively the last days, because these were exactly the projects in "Show HN: .." category and you would not be able to tell them if you wouldnt have spent your whole time here :-D
Ha! :-D
Ronsenshi•1h ago
Project was started in late 00s so it has substantial amount of business logic, rules and decisions. Maybe I'm being an old man shouting at the clouds, but I assume (or hope?) it would fail to deliver whatever they promised to the CEO.
So, I guess I'll see the result of this shift soon enough - hopefully at a different company by the time AI-people are done.
fhd2•48m ago
Maybe the deed is done here, and I'd agree it's not particularly fun, but you could still think about what you can bring to the table in situations like this. Can you work on shortening these pesky feedback cycles? Can you help the team (if they even accept it) with _some_ degree of engineering? It might not be the last time this happens.
I think right now we're seeing some weird stuff going on, but I think it hasn't even properly started yet. Remember when pretty much every company went "agile"? In most cases I've seen they didn't, just wasting time chasing miracles with principles and methodologies few people understand deeply enough to apply. Yet this went on for, what, 10 years?
onion2k•50m ago
At most of the companies I've worked at the development team is more like a cluster of individuals who all happen to be contributing to a shared codebase than anything resembling an actual team who collaborate on a shared goal. AI-assisted engineering would have helped massively because the AI would be looking outside of the myopic view any developer who is only focused on their tiny domain in the bigger whole cared about.
Admittedly though, on a genuinely good team it'll be less useful for a long time.
zdragnar•9h ago
Honestly, I can't wait for AI: development practices to mature, because I'm really tired of the fake hype and missteps getting in the way of things.
LtWorf•9h ago
nzoschke•9h ago
High velocity teams also observe production system telemetry and use error rates, tracing and more to maintain high SLAs for customers.
They set a "budget" and use feature flagging to release risky code and roll back or roll forward based on metrics.
So agentic coding can feed back on observed behaviors in production too.
SilenN•5h ago
ithkuil•1h ago
But we have to use this "innovation budget" in a careful way.
SilenN•5h ago
I'll caveat my statement, with AI ready repos. Meaning those with good documentation, good comments (ex. avoiding Chestertons fence), comprehensive interface tests, Sentry, CI/CD, etc.
Established repos are harder because a) the marginal cost of something going wrong is much higher b) there's more dependencies c) this makes it harder to 'comprehensively' ensure the AI didn't mess anything up
I say this in the article
> There's no "right answer." The only way to create your best system is to create it yourself by being in the loop. Best is biased by taste and experience. Experiment, iterate, and discover what works for you.
Try pushing the boundary. It's like figuring out the minimum amount of sleep you need. You undersleep and oversleep a couple times, but you end up with a good idea.
To be clear, I'm not advocating for canonical 'vibe coding'. Just that what it means to be a good engineer has changed again. 1) Being able to quickly create a mental map of code at the speed of changes, 2) debugging and refactoring 3) prompting, 4) and ensuring everything works (verifiability) are now the most valuable skills.
We should also focus more on the derivative than our point in time.