My experience with Claude Code after two weeks of adventures
sankalp.bearblog.dev
sankalp.bearblog.dev
Every time I read comments saying Claude Code is far better than Cursor, I fire it up, pay for a subscription, and run it on a large, complex TypeScript codebase. First, the whole process takes a hell of a lot of time. Second, the learning curve is steep: you have to work through the terminal and type commands.
And the outcome is exactly the same as with the Claude that’s built into Cursor—only slower, less clear, and the generated code is harder to review afterward. I don’t know… At this point my only impression is that all those influencers in the comments are either sponsored, or they’ve already shelled out their $200 and are now defending their choice. Or they simply haven’t used Cursor enough to figure out how to get the most out of it.
I still can’t see any real advantage to Claude Code, other than supposedly higher limits. I don’t get it. I’ve already paid for Claude Code, and I’m also paying for Cursor Pro, which is another $200, but I’m more productive with Cursor so far.
I’ve been programming for 18 years, write a ton of code every single day, and I can say Cursor gives me more. I switch between Gemini 2.5 Pro—when I need to handle tasks with a big, long context—and Claude 4.0 for routine stuff.
So no one has convinced me yet, and I haven’t seen any other benefit. Maybe later… I don’t know.
In that context, CC is amazing.
It's less about writing code, more about building an engine that codes. It's hands off but unlike Cursor, it's not as eyes-off. You do observe and interrupt it. It is great for full on TDF - it figures out the feature, writes the test for the feature, fails the test, rewrites the code to pass. But at some point, you realize you got the instructions wrong and because you're outside the loop, you have to interrupt it.
I think it's a natural progression, but it's not for everyone. The people who hated not being able to write functions will hate claude code even more. But some people love writing their engines.
I'm not sure why. However, Claude does seem to know better where things are and knows not to make unnecessary changes. I still need to guide it and tell it to do things differently some times, but it feels like it's a lot more effective
Personally, I also like that usually it just presents to me only one change/file at a time, so it's easier for me to review. Cursor might open several files at once, each with a tons of changes, which makes it a lot harder for me to understand quickly
Btw, I use Claude Code in a terminal pane inside VSCode, with the extension. So Claude does open a file tab with proposed changes
Tell us what you do—how, under what conditions, and in which programming languages. What exactly makes it better? Does it just search for files? Well, that’s hardly objective.
So far the impression is… well, you say it only seems better. But you won’t get far with that kind of reasoning.
Objectively, it now seems to me that Claude the cat is better, because everyone around says it’s better. Yet no one has actually explained why. So the hype is inflated out of thin air, and there are no objective reasons for it.
...you're replying to an account that was created in 2007. A bio is listed on the profile page.
Maybe you feel you've seen this comment before because it's an opinion lots of people share? Even if you do not.
This is interesting. I haven't used Cursor, but one of my frustrations with Claude Code is that some of the individual changes it asks me to approve are too small for me to make a decision. There are cases where I almost denied a change initially, then realized Claude's approach made sense once I saw the full change set. Conversely, there are cases where I definitely should have stopped Claude earlier.
It doesn't help that Claude usually describes its changes after it has made the full series, instead of before.
...really, what I'd like is an easy way to go back in time, wherein going back to an earlier point in the conversation also reverted the state of the code. I can and do simulate this with git to some extent, but I'd prefer it as a layer on top of git. I want to use git to track other things.
Yes, I've adapted to just review quickly, then if it makes sense as part of the task, let it keep going until it's done with the whole thing. Most of the times, by the end it does the right thing
I love that it doesn't auto-commit everything, ala aider, so it's pretty painless to undo stuff
I also keep a TODO.md file with a plan of everything I want to do for the current ticket/PR. I tell CC to keep track of things there. CC takes stuff from there, breaks it down into its own subset of tasks and when finished I tell it to update the TODO.md with the progress. I also tell it to stage files and create commits
The way I use it, it feels like I'm still programming, but I don't need to write code or run commands by myself, nor get stuck googling stuff up. I can just tell CC to do almost anything for me. It takes away the tediousness of what I want to accomplish
Yeah, I'm definitely glad it doesn't commit for me. The main issue I have is that I'm never sure how granular to make my commits. Sometimes I make them very granular because I'm experimenting with Claude and I want to be able to revert to any point in the conversation—but now I have to write a message each time to keep track of which is which. Conversely, when I don't make the commits as granular I loose the ability to roll back, and sometimes regret it.
Also, sometimes Claude gets a bit too smart! Let's say I decide I want Claude to try again with a slightly different prompt. I save my current changes in a branch, roll back, to the previous state, and ask Claude to try again. Sometimes Claude will say "I see this is already implemented in the XX branch. Let me continue to build on that implementation."
Other times I’ll tell it about an issue that I want to solve and it will come up with a solution I don’t want. I’ll tell it to take a different approach and it will listen for a bit, then all of a sudden just try to go back to its first approach and I need to steer it again, multiple times even
> but now I have to write a message each time to keep track of which is which
I ask it to write my commits. Usually it’s also pretty smart about which files to include based on the most recently addressed tasks. I have it run git add and git commit under my supervision
A repo Im working on, has some rather annoying hooks that check linting when committing (and aggressively modify the files to fix formatting). If I forget to manually check before committing, then I end up with a “wrong” commit containing the incorrectly formatted files, and a bunch of uncommitted files with the formatting changes. CC most of the times will see the error messages, and automatically propose the proper commands to run for undoing or amending the commit to include the formatting changes
Still sometimes I forget to commit between tasks or it goes wild fixing compiler errors I didn’t want to address.
I have a monorepo, so different instructions and rules live in different corners of it, which I manually add as needed. Doing all this with Claude is hard: it kind of works, but it’s a kludge. It’s much easier to manage through the UI. As the saying goes, it’s better to see something once than to remember it ten times, type a command, and configure it.
I can say the same about Vim and Emacs users. No one has yet proven to me they can code and navigate faster than an ordinary programmer using a trackpad or a mouse and keyboard. It’s purely a matter of taste. I’ve noticed that people who love those tools are just bored at work and want to entertain their brains. That’s neither good nor bad, but it doesn’t give a real boost.
By the way, there’s a study (a bit old, admittedly) showing that working with an LLM still doesn’t provide a massive speed-up in programming. Yes, it spits out code quickly, but assembling a finished result takes much longer: you have to review, polish, start over, throw things out, start again. It’s not that simple.
Speaking of Claude, he’s a real master at shitting in the code. At the speed of sound he generates a ton of unnecessary code even when you ask him not to. You ask for something minimalist, nothing extra—he still slaps on a pile of code with useless tests that outsmart themselves and don’t work.
That’s the downside. Overall, it’s easier to program when you just say what to do instead of sitting there straining your own brain. But even then it’s not simple. If you yourself haven’t figured out very carefully what you’re doing, you’ll end up with crap. I almost always throw away what I wrote with an LLM when I was tired. I don’t think there’s ever been an exception.
The only way to write something decent is to dig in thoroughly: draw diagrams, write everything out, and only then tell the LLM exactly what to do. Then double-check, make sure it didn’t write anything extra, delete the excess. And only like that, in small chunks. The “make me a feature, I pressed a button and walked away” mode doesn’t work if the task is even slightly complex.
Yeah, I got carried away—had to let it out. I have a lot to say about LLMs and programming with them, and not just about Cursor and Claude. The tools completely upended the way we program...
I too notice this about Claude, I've written commands, massaged Claude.md, even hooks. Given it very precise feature guides. I see the same issues you do. Feels like Claude has a lazy lever built in to it.
I play GPT O3 off it constantly, it takes the spec, a repomix slice of the Claude work and gives a new gap.md for Claude to pursue. Rinse and repeat. It works but your cursor flow seems better.
My highest velocity was about 1.6 fib complexity points a day over thirty years, now it's 4.3 with Claude the last three weeks which is nuts. I'm a total hack, I think I could get it up to nine if I was a bit more organized. Probably won't have to, just wait for the next iteration of the Claude models.
Where do you work that you managed to track what I assume are Agile story points over 30 years, also, so accurately?
I don't even remember my median number for a sprint, let alone my daily average over long periods of time.
I think it can also be deceptive the same way it can be in basically any trade: it’s easy for the job to get “done” and work. It’s hard to do it properly in a way that it has a lasting durability. With A.I. we can spit out these programs that work and look done. And for prototypes or throwaways and such, that’s probably wonderful! But that’s not going to fly if you’re building a house to spec for people who are going to live in it for 30 years.
Let’s be honest, that’s what most companies pay good salaries for most software developers for.
When staring at a new job or project, do you more find yourself praising the architecture and quality? Or wondering how it got to this point?
Maybe AI will disrupt the rush to market phase. Maybe that makes complete sense, tbh. But there’s a whole realm of sober engineering that still needs to be done properly.
The key take away here is that save for the deep integration, there is a strategy for working with a best in class agent solution agnostic of tooling.
These learnings will eventually coalesce into "best practices" that people will apply using the editor or IDE of their choice and all these vscode forks will have died off.
Microsoft/GitHub has even signaled confidence that they can compete feature by feature with the forks by even open sourcing much of the Copilot integration in VS Code.
Aesthetically, I like VS Code Copilot/Copilot Chat UIs/UX for the most part, certainly better than I like Claude Code and more than I like Cursor, too.
Context is key, so it is also really helpful having a CLAUDE.md file; the /init command can create one for you.
If you are going to use it for generation (writing code); plan mode is a must. Hit shift-tab twice.
Finally; I'm mostly using the claude 4 sonnet model, but make sure to tell it to "ultrathink" (use those words); this means it can use more thinking tokens.
Having an agent completely design/write a feature still feels weird. I like everything being hand written, even if I actually just tab completed and edited it slightly
I ended up with 8k lines of rust and 12k lines of markdown. I think those markdown designs and explicit tasks were required the same way unit tests with a test harness are required to make the human-tool interaction work.
However, I’m not sure if the ‘magic’ is VC-subsidy or something else.
It did make rust (a language i do not know) feel like a scripting language. … the github repo is ‘knowseams’.
I’m curious what this means:
> run it on a large, complex TypeScript codebase
What do you mean by “run it?”
Are you putting the entire codebase all at once into the context window? Are you giving context and structure prompts or a system architecture first?
Most of the people I see fail to “get” GPT assistants is because they don’t give context and general step-by-step instructions to it.
If you treat it like a really advanced rubber duck it’s straight up magic but you still have to be the senior engineer guiding the project or task.
You can’t just dump a 10,000 LOC file into it ask some vague questions and expect to get anything of value out of it.
that's supposed to be part of CS101
I think people just need to try a bunch to be honest. I think that we will get to a point (or are already there) where some models just resonate better with you and your communication (prompt) style.
But after using a bunch...I have to say that Gemini 2.5 Pro is consistently the best one I've used yet. It's pricey, but it just works.
I'm still looking for a good local model, but it's just going to be a while until anything local can match Gemini. It will eventually I think, but it'll take some time.
I probably won't be using Claude Code, but I'm glad it works for some folks.
For new projects, I find Claude Code extremely helpful, as I start out with a business document, a top-level requirements document, and go from there. In the end (and with not a lot of work or time spent) I have a README, implementation plan, high-level architecture, milestones, and oftentimes a swagger spec, pipeline setup and a test harness.
IMHO pointing CC at a folder of a big typescript project is going to waste a ton of compute and tokens, for minimal value. That is not a good use of this tool. I also have a pretty strong opinion that a large, complex typescript codebase is a bad idea for humans too.
Point CC at a python or go repo and it is a whole 'nother experience. Also, starting out is where CC really shines as stated above.
For a big complex typescript repo I would want very specific, targeted help as opposed to agentic big-picture stuff. But that also minimizes the very reason I'd be reaching for help in the first place.
Cursor has an amazing tab completion model. It uses a bunch of heuristics to try to understand what you're doing and accelerate it. It's a bit like a very advanced macro engine, except I don't have to twist my brain into a pretzel trying to program my editor - it just works, and when it doesn't I press Esc, which takes about half a second. Or I reach for the agentic mode, where the iteration cycle is more like 30 seconds to a minute.
With the fully agentic editors, it takes more like 15 to 30 minutes, and now it's a full on interruption in my flow. Reviewing the agent's output is a chore. It takes so much more mental bandwidth than the quick accept/reject cycle in the editor. And I have to choose between giving it network access (huge security hazard) or keeping it offline (crippling it in most codebases).
I find that for throwaway codebases where I don't care about maintenance/security/reliability, I can put up with this. It's also incredibly useful when working with a language or framework that I don't fully understand (but the model understands better). But for most of my work it produces poor results and ends up being a net negative for productivity - for now.
I'm sure this will improve, but for now I consistently get better results in Cursor.
That does net out to meaning that Cursor gets used way more often, atm.
The whole thing looks like one large source of friction.
I've been using Cursor a lot and it speeds up everything for me. Not sure what kind of benefit Claude Code would give me.
Claude Code + Cursor is my setup. Claude Code is my workhorse that I use for most tasks.
For small tiny quick changes, I use Cursor in auto.
For architecture consulting I use Cursor chat with Grok 4.
Claude Code is much better at banging out features than Cursor’s Claude. And Claude itself is better than other models as a coding workhorse.
All that said: while we may all code, we are building wildly different things that have much different specific problems to solve so it doesn’t surprise me that there isn’t a universal setup that works best for everybody.
I also suspect a lot of this is paid for or just terminal die hards.
You are absolutely right. A large portion are influencers (I would estimate around 95% of those you see on YouTube and forums) that are full of hype. I think most are not affiliated with Anthropic or any vendor, they are just trying to sell a course, ebook or some "get rich with AI" scheme.
What I appreciate about Claude Code:
- Since it is a terminal/CLI tool it can be run headlessly from cron jobs or scripts. This makes it easy to automate.
- I appreciate the predictable pricing model. A flat monthly fee gives me access to Claude Sonnet and Opus 4 in five-hour sessions each with its own usage limit that resets at the start of a new session. There is a fair use policy of around 50 sessions per month, but I haven’t hit that yet. I deliberately run only one instance at a time as I prefer to use it responsibly unlike some of the "vibe" influencers who seem to push it to the limit.
That's it. Despite being a CLI based tool, Claude Code is remarkably out of the box for what it offers.
That said, no coding agent I have encountered can fully ingest a large inconsistent legacy codebase especially one with mixed architectures that accumulated over years. This limitation is mainly due to context size constraints, but I expect this to improve as context windows grow.
The reason why they like Claude Code specifically over Cursor isn't because they were fans of terminal windows; on the contrary, its because CC is simpler. Cursor is complicated, and its interface communicates to the user that eventually you might be grabbing the wheel. Of course, experienced engineers want to grab the wheel; working together with the AI toward some goal. But these CC-stans don't. All that extra stuff in the UI scares them, because they wouldn't know what to do with it if they had to do something with it.
Its this particular kind of person that's also all over /r/ClaudeAI or /r/Cursor complaining about rate limits. If you've ever used these products, you'd realize very quickly: The only way you're hitting rate limits so quickly on the paid plans is if the only code that's being outputted is from the AI, nonstop, for eight hours a day, using only the most expensive and intelligent models. The only people who do this are the people who have no brain of their own to contribute to the process. Most CC/Cursor users don't hit rate limits, because they're working with the AI, like a tool, not managing it like a direct report.
Having the AI just getting the wheels turning when I'm not in the mood myself has many times been a good way to make progress.
The biased behaviour towards just asking for a solution both devalues you and leads to any innovative outcomes disappearing before they had a chance to exist.
I've ended up being the company ideas man not because I'm good but everyone else stopped thinking.
They aren't the best solution for everything. Thinking is one of those things.
I do control systems that have to work first try and after running the plant through its paces I’m out the door never to return
But! There are some problems that are intrinsically interesting to me and others that are boring as hell but need to be solved.
In 20 years of work I’ve not come up with any way to make those boring tasks psychologically _not_ so disagreeable they are close to painfull.
But now the LLM can do whatever crap it does for those and I _finally_ can focus just on the interesting bits.
So, a boring task - off to the LLM you go - interesting - it’s mine, all mine!
Yes! And hell, checking out how the machine solved a boring thing can still be a source of interest in itself, so the dopamine squeezing novelty keeps on flowing all day long.
The best use cases for me have been when I know the solution and what it should look like but don't want to write it all by hand myself. The AI can make the code just appear and I can verify it is up to spec.
Does the answer change if the author is an LLM as opposed to another person?
Climb down from your high horse why don't you.
If your coworkers can get into the groove faster than you (for whatever reason), you’ll continue to do quality work, not look busy, and no longer be paid for it.
And good luck finding anyone these days who can do quality.
It's a nice niche.
I don't mean to attack this person specifically but it's a frankly pretty bad mindset that is far too prevalent in our profession - the way I do things in the Right Way, I write Good Code, very few other people write Good Code, and because I do things the way they were done 5, 10, 25 years ago means that my way is better than yours.
For example, the other day I needed to find which hook to use in a 2300 loc file of hooks. AI found me the hook in 5 seconds and showed me how to use it. This is a pure win - now that I have the name of the hook I can go read it in 30 seconds and verify it's what I wanted. If it's not, I can ask again. There's zero risk here.
Re: usage of LLMs, that is honestly the way I like to use LLMs. That and auto-complete.
It's great for creating a bird's-eye view of a project because that is very fuzzy and no granular details are needed yet. And it's great at being fancy autocomplete, with its stochastic bones. But the middle part where all the complexity and edge cases are is where LLMs still fail a lot. I shudder for the teams that have to PR review devs that jubilantly declare they have "5x'ed" their output with LLMs, senior or not.
What is even more worrisome is that the brain is a muscle. We have to exercise it with thinking, hence why puzzlers stay sharp at old age. The more you outsource your code (or creative writing) thinking, the worse you get at it, and the more your brain atrophies. You're already seeing it with Claude Code, where devs panic when they hit the limit because they just might have to code unassisted.
On small issues it's usually just a glance over the diff, on harder issues it's not challenging to scold it into a good path once something starts coming together, as long as it's a localized edit with a problem I understand. I'll often take over when it's 40-60% there, which is only possible b/c it does a good job of following todo lists.
I've moved into a good daily workflow that emphasizes my own crafting during the times I'm sharp like mornings, and lets AI do the overtime and grunt work while I prepare for tomorrow or do more thoughtful writing and design.
I spend probably 70% of my active coding time coding. The rest is using LLMs to keep making progress but give my brain a bit of a break while I recharge, being more supervisory with what's happening, and then taking over if necessary or after the 10-15 minutes it takes for me to start caring again.
It gave me a shit plan today. Basically I asked it to refactor a block of prototype code that consisted of 40 files or so. It went the wrong way and tried to demolish it from the bottom up instead of making it 100% backwards compatible. If it made a mistake we would have taken forever to debug it.
But yeah, it gave me something to attack. And the plan was fixed within an hour. If I tried to make one myself, I would have frozen from the complexity or gone in circles documenting it.
Lesson learned: being lazy with AI has a hidden cost.
If you haven’t tried it, I can’t recommend it enough. It’s the first time it really does feel like working with a junior engineer to me.
And I reach for Claude quite a bit because if it worked as well for me like everyone here says, that would be amazing.
But at best it’ll get a bunch of boilerplate done after some manual debugging, at worst I spend an hour and some amount of tokens on a total dead end
Clear instructions go a long way, asking it to review work, asking it to debug problems, etc. definitely helps.
Definitely - with ONE pretty big callout. This only works when a clear and quantifiable rubric for verification can be expressed. Case in point, I put Claude Code to work on a simple react website that needed a "Refresh button" and walked away. When I came back, the button was there, and it had used a combination of MCP playwright + screenshots to roughly verify it was working.
The problem was that it decided to "draw" a circular arrow refresh icon and the arrow at the end of the semicircle was facing towards the circle centroid. Anyone (even a layman) would take one look at it and realize it looked ridiculous, but Claude couldn't tell even when I took the time to manually paste a screenshot asking if it saw any issues.
While it would also be unreasonable to expect a junior engineer to hand-write the coordinates for a refresh icon in SVG - they would never even attempt to do that in the first place realizing it would be far simpler to find one from Lucide, Font Awesome, emojis, etc.
But for other tasks like generating reports, I ask it to write little tools to reformat data with a schema definition, perform calculations, or do other things that are fairly easy to then double-check with tests that produce errors that it can work with. Having it "do math in its head" is just begging for disaster. But, it can easily write a tool to do it correctly.
That's exactly what I learned. In the early 2000's, from three expensive failed development outsourcing projects.
When it drops in something hacky, I use that to verify the functionality is correct and then prompt a refactor to make it follow better conventions.
btw, I'm not throwing shade. I personally think upfront design through a large lumbering document is actually a good way to develop stuff. As you either do it upfront, or through endless iterations in sprints for years.
So, is Claude just something you use for fun? Would you use it for work?
I'd definitely watch Boris's intro video below [1]
[1] Boris introduction: https://www.youtube.com/watch?v=6eBSHbLKuN0 [2] summary of above video: https://www.nibzard.com/claude-code/
Yes, I would write a 4 line bash script by myself.
But if you're trading a 200 line comprehensive claude.md document for a module that might be 20k LoC? it's a different value proposition.
The spec and the test are your human contribution.
To have useful tests, you must write the APIs for the functions, and give examples of how to wire up the various constructs, and correct input/output pairs.
Implementations of those functions that pass the test now have significant constraints that mean you understand a lot about it.
First you write the tests, then you write code until tests pass.
As for coworkers, I would really try to get them to work in chunks smaller than 20k loc. But at some point you have an expectation that coworkers will be accountable for their area of responsibility. If there's a bug in their code, they're expected to fix it. If there's a bug in the AIs code, I'm expected to fix it....
Those are cool, but a production system is infinitely more complex.
I sympathize with both experiences and have had both. But I think we've reached the point where such posts (both positive and negative) are _completely useless_, unless they're accompanied with a careful summary of at least:
* what kind of codebase you were working on (language, tech stack, business domain, size, age, level of cleanliness, number of contributors)
* what exactly you were trying to do
* how much experience you have with the AI tool
* is your tool set up so it can get a feedback loop from changes, e.g. by running tests
* how much prompting did you give it; do you have CLAUDE.me files in your codebase
and so on.
As others pointed out, TFA also has the problem of not being specific about most of this.
We are still learning as an industry how to use these tools best. Yes, we know they work really well for some people and others have bad experiences. Let's try and move the discussion beyond that!
For context, I was using Claude Code on a Ruby + Typescript large open source codebase. 50M+ tokens. They had specs and e2e tests so yeah I did have feedback when I was done with a feature - I could run specs and Claude Code could form a loop. I would usually advise it to fix specs one by one. --fail-fast to find errors fast.
Prior to Claude Code, I have been using Cursor for an year or so.
Sonnet is particularly good at NextJS and Typescript stuff. I also ran this on a medium sized Python codebase and some ML related work too (ranging from langchain to Pytorch lol)
I don't do a lot of prompting, just enough to describe my problem clearly. I try my best to identify the relevant context or direct the model to find it fast.
I made new claude.md files.
I also do a fair amount of data shuffling with Golang. My LLM experience there is "mixed".
Then I deal with quite a few "fringe" code bases and problem spaces. There LLM's fall flat past the stuff that is boiler plate.
"I work in construction and use a hammer" could mean framer, roofer or smashing out concrete with a sledge. I suspect that "I am a developer, I write code" plays out in much the same way, and those details dictate experience.
Just based on the volume of ruby and typescript, and the overlap of the output of these platforms your experience is going to be pretty good. I would be curious if you went and did something less mainstream, and in a less common language (say Zig) if you would have the same feelings and feedback that you do now. Based on my own experience I suspect you would not.
Which is, obviously, sad. Especially since the big winner is Javascript, a language that's still subpar as far as programming languages go.
Your LLM (CC) doesn't have your whole codebase in context, so it can run off and make changes without considering that some remote area of the codebase are (subtly?) depending on the part that claude just changed. This can be mitigated to some degree depending on the language and tests in place.
The LLM (CC) might identify a bug in the codebase, fix it, and then figure, "Well, my work here is done." and just leave it as is without considering ramifications or that the same sort of bug might be found elsewhere.
I could go on, but my point is to simply validate the issues people will be having, while also acknowledging those seeing the value of an LLM like CC. It does provides useful work (e.g. large tedious refactors, prototyping, tracking down a variety of bugs, and so on...).
If your tests are good, Claude Code can run them and use them to check it hasn't broken any distant existing behavior.
If they DO do that, it's on us to tell them to undo that and fix things properly.
Then it doesn’t need to feel (or rg) through the whole codebase.
You also use plan mode to figure out the issue, write the implementation plan in a .md file. Clear context, enter act mode and tell it to follow the plan.
I actually think it's more productive to just accept how people describe their experience, without demanding some extensive list of evidence to back it up. We don't do this for any other opinion, so why does it matter in this case?
> Let's try and move the discussion beyond that!
Sharing experiences using anecdotal evidence covers most of the discussion on forums. Maybe don't try to police it, and either engage with it, or move on.
The thing is that I often read this kind of response only to comments with negative experiences, while positive ones are accepted as fact. You can see this reinforced in the comments here as well. A comment section is not the right place to expand on these details, but I agree that blog posts should have them, regardless of the experience type.
Sort of.
The people that are happy with it and praising the avenues offered by LLM/AI solutions are creating codebases that fulfill their requirements, whatever those might be.
The people that seem to be unhappy with it tend to have the universal complaints of either "it produces garbage" , or "I'm slower with it.".
Maybe i'm showing my age here, but I remember these same exact discussions between people that either praised or disparaged search engines. The alternative being an internet Yellowpages (which was a thing for many years.)
The ones that praised it tended to be people who were taught or otherwise figured out how to use metadata tags like date:/onsite: , whereas the ones that disparaged it tended to be the folks who would search for things like "who won the game" and then proceed to click every scam/porno link on this green Earth and then blame Google/gdg/lycos/whatever when they were exposed to whatever they clicked.
in other words : proof is kind of in the pudding.
I wouldn't care about the compiler logs from a user that ignored all syntax and grammar rules of a language after picking it up last week, either -- but it's useful for successful devs to share their experiences both good and bad.
I care more about the opinions of those that know the rules of the game -- let the actual teams behind these software deal with the user testing and feedback from people that don't want to learn conventions.
One big warning here: search engines only became really useful when you could search for "who won the game" and the search engine actually returned the correct thing as the top result.
We're more than a quarter of a century later and probably 99.99% of users don't know about Google's advanced search operators.
This should be a major warning for LLMs. People are people and will do people things.
Ah, but "whatever those might be" is the crucial bit.
I don't entirely disagree with what you're saying. There will always be a segment of power users who are able to leverage their knowledge about these tools to extract more value out of them than people who don't use them to their full potential. That is true for any tool, not just in software.
What you're ignoring are two other possibilities:
1. The expectation of users can be wildly different. Someone who has never programmed before, but can now create and ship a smartphone app, will see these tools as magical. Whatever issues they have will either go unnoticed, or won't matter considering the big picture. Surely their impression of AI tooling will be nothing short of positive. They might be experts at using LLMs, but not at programming.
OTOH, someone who has been programming for decades, and strives for a certain level of quality in their work, will find the experience much different. They will be able to see the flaws and limitations of these tools, and addressing them will take time and effort that they could've better spent elsewhere. As we've known since the introduction of LLMs, domain experts are the only ones who can experience these problems.
So the experience of both sides is valid, and should have equal weight in conversations. Unlike you, I do trust the opinion of domain experts over those of user experts, but that's a personal bias.
2. There are actual flaws and limitations in AI tooling. The assumption that all negative experiences are from users who are "holding it wrong", while all positive ones are from expert users, is wrong. It steers the conversation away from issues with the tech that should be discussed and addressed. And considering the industry is strongly propelled by hype and marketing right now, we need conversations grounded in reality to push back against it.
I’m not sure about that. I feel like someone experienced would realize when using the LLM is a better idea than doing it themselves, and when they just need to do it by hand.
You might work in a situation where you have to do everything by hand, but then your response would be to the extent that you can see how it’s useful to other people.
They did mention "(both positive and negative)", and I didn't take their comment to be one-sided towards the AI-negative comments only.
"I prefer typewriters over word processors because it's easier to correct mistakes."
"I don't own any forks because knives are just better at cutting bread."
"Bidets make my pants wet, so I'll keep to toilet paper."
I think there's an urge to fix misinformation. Whereas if someone loves Excel and thinks Excel is better than Java at making apps, I have no urge to correct that. Maybe they know something about Excel that I don't.
I use Claude many times a day, I ask it and Gemini to generate code most days. Yet I fall into the "I've never included a line of code generated by an LLM in committed code" category. I haven't got a precise answer for why that is so. All I can come up with is the code generated lacks the depth of insight needed to write a succinct, fast, clear solution to the problem someone can easily understand in in 2 years time.
Perhaps the best illustration of this is someone proudly proclaimed to be they committed 25k lines in a week, with the help of AI. In my world, this sounds like they are claiming they have a way of turning the sea into ginger beer. Gaining the depth of knowledge required to change 25k lines of well written code would take me more than a week of reading. Writing that much in a week is a fantasy. So I asked them to show me the diff.
To my surprise, a quick scan of the diff revealed what the change did. It took me about 15 minutes to understand most of it. That's the good news.
The bad news it that 25k lines added 6 fields to a database. 2/3's were unit tests, perhaps 2/3's of the remainder was comments (maybe more). The comments were glorious in their length and precision, littered with ASCII art tables showing many rows in the table.
Comments in particular are a delicate art. They are rarely maintained, so they can bit rot in downright misleading babble after a few changes. But the insight they provide into what author was thinking, and in particular the invariants he had in mind can save hours of divining it from the code. Ideally they concisely explain only the obscure bits you can't easily see from the code itself. Anything more becomes technical debt.
Quoting Woodrow Wilson on the amount of time he spent preparing speeches:
“That depends on the length of the speech,” answered the President. “If it is a ten-minute speech it takes me all of two weeks to prepare it; if it is a half-hour speech it takes me a week; if I can talk as long as I want to it requires no preparation at all. I am ready now.”
I used PayPal's KYC web interface the other day. It looked beautiful, completely inline with the rest of PayPal's styling. But sadly I could not complete it because of bugs. The server refused to accept one page, it just returned to the same page with no error messages. No biggie, I phoned support (several times, because they also could not get past the same bug), and after 4 hours on the phone the job was done. I'm sure the bug will be fixed a new contractor. He spend an few hours on it, getting an LLM to write a new version, throwing the old code away, just as his predecessor did. He will say the LLM provided a huge productivity boost, and PayPal will be happy because he cost them so little. It will be the ideal application for an LLM - got the job done quickly, and no one will read the code again.
I later discovered there was a link on the page that allowed me to skip past the problematic page, so I could at least enter the rest of the information. It was in a thing that looked confusingly like a "menu bar" on the left, although there was no visual hit any of the items in the menu were clickable. I clicked on most of them anyway, but they did nothing. While on hold for phone support, I started reading the HTML and found one was a link. It was a bit embarrassing to admit to the help person I hadn't clicked that one. It sped the process up somewhat. As I said, the page did look very nice to the eye, probably partially because of the lack of clutter created by visual hints on what was clickable.
[0] https://quoteinvestigator.com/2012/04/28/shorter-letter/
- Some believe LLMs will be a winner-take-all market and reinforce divergences in economic and political power.
- Some believe LLMs have no path of evolution and have therefore already plateaued and too low to be sustainable with these investments in compute, which would imply it's a flash in the pan that will collapse.
- Some believe LLMs will all be hosted forever, always living in remote services because the hardware requirements will always be massive.
- Some believe LLMs will create new, worse kinds of harm without enough offsetting creation of new kinds of defense.
- Some believe LLMs and AI will only ever give low-skilled people mid-skill results and therefore work against high-skill people by diluting mid-end value without creating new high-end value for them.
We need to be more aware of how we are framing this conversation because not everyone agrees on these big premises. It very strongly affects the views that depend on them. When we don't talk about these points and just judge and reply based on whether the conclusion reinforces our premises, the conversation becomes more political.
Confirmation bias is a thing. Individual interests are a thing. Some of the outcomes, like regulation and job disruption, depend on what we generally believe. People know this and so begin replying and voting according to their interests, to convince others to aid their cause without respect for the truth. This can be counter-productive to the individual if they are wrong about the premises and end up pushing an agenda that doesn't even actually benefit them.
We can't tell people not to advance their chosen horse at every turn of a conversation, but those of us who actually care about the truth of the conversation can take some time to consider the foundations of the argument and remind ourselves to explore that and bring it to the surface.
I just wish I could figure out what it tells. Their training data can't be that different. The problems I'm feeding them are the same. Many people think Claude is the more capable of the two.
It has to be how I'm presenting the problems, right? What other variable is there?
I'm on board with some limited AI autocompletion, but so far agents just seem like gimmicks to me.
Although I should be fair, this can help with one-off scripts that research folks usually do, when you just need to plot some data or do some back-of-the-terminal math. That said I don't think this would be a game changer, more of an efficiency boost and a limited one at that.
As to the shovelware, if it benefits people that's great, and I think the net benefit will likely be positive, but only slightly. The point in calling it shovelware is to suggest that it's low quality, and so it could have bugs and other performance issues that add costs to using which subtract from the benefit it provides (possibly in a net positive way, but probably not as fundamentally game changing as, say, Docker).
When it creates a bunch of useless junk I feel free to discard it and either try again with clearer guidelines (or switch to Opus).
It would have been a half-day worth of adventure at least should i have done it myself (from diagnosing to fixing)
This seems consistent with some of the more precocious junior engineers I've worked with (and have been, in the past.)
The quality of the generated code is inversely proportional to the time it take to generate it. If you let Claude Code work alone for more than 300 seconds you will receive garbage code. Take that as a hint, if it can't finish the task in this time it means you are asking too much. Break up your feature and try with a smaller feature.
People have such widely varying experiences and I’m wondering why.
I'd think Win32 development would be something AIs are very strong at because it's so old, so well documented, and there's a ton of code out there for it to read. Yet it still struggles with the differences between Windows messages, control notification messages, and command messages.
It's also another in my growing list of data points towards my opinion that if an author posts meme pictures in their article, it's probably not an article I'm interested in reading.
The tools really do shine where they're good though. They're amazing. But the moment you try to do the more "serious" work with them, it falls apart rapidly.
I say this as someone that uses the tools every day. The only explanation that makes sense to me is that the "you don't get it, they're amazing at everything" people just aren't working on anything even remotely complicated. Or it's confirmation bias that they're only remembering the good results - as we saw with last week's study on the impact of these tools on open source development (perceived productivity was up, real productivity was down). Until we start seeing examples to the contrary, IMO it's not worth thinking that much about. Use them at what they're good at, don't use them for other tasks.
LLMs don't have to be "all or nothing". They absolutely are not good at everything, but that doesn't mean they aren't good at anything.
But I think we should expect the scope of LLM work to improve rapidly in the next few years.
https://metr.org/blog/2025-03-19-measuring-ai-ability-to-com...
Sorry, but this is just not true.
I'm using agents with a totally idiosyncratic code base of Haskell + Bazel + Flutter. It's a stack that is so quirky and niche that even Google hasn't been able to make it work well despite all their developer talent and years of SWEs pushing for things like Haskell support internally.
With agents I'm easily 100x more productive than I would be otherwise.
I'm just starting on a C++ project, but I've already done at least 2 weeks worth of work in under a day.
If you honestly believe that "agents" are making you better than Goole SWEs then you severely need to take a step back and reevaluate, because you are wrong.
If you’re really that more productive, why don’t you quit your job and vibecode 10 ios apps (in your case that would be 50 to 100 proportionally)
This doesn't mean that it's not useful, or that you shouldn't be happy with what the LLM built. I also had Claude Code build me a web app for my own personal use in Rust this week. It's very useful to me. But it is 100% of POC/MVP quality, and always will be, because the code that it created is abjectly awful and I would never be able to scale it into a real world service without rewriting 50+% of it.
It’s nice because 3/4 of those are well-known but not “default” industry choices and it still handles them very well.
So there’s a Laravel CRM builder called Filament which is really fun to work in. Claude does a great job with that. It’s a tremendous amount of boilerplate with clear documentation, so it makes sense that Claude would do well.
The thing I appreciate though is that CC as an agent is able to do a lot in one go.
I’ve also hooked CC up to a read-only API for a client, and I need to consume all of the data on that API for the transition to a Filament app. Claude is currently determining the schema, replicating it in Laravel, and doing a full pull of API records into Laravel models, all on its own. It’s been running for 10 minutes with no interruption and I expect will perform flawlessly at that.
I invest a lot of energy in prompt preparation. My prompts are usually about 200 words for a feature, and I’ll go back and forth with an LLM to make sure it thinks it’s clear enough.
In my experience, LLMs are great at small tasks (bash or python scripts); good at simple CRUD stuff (js, ts, html, css, python); good at prototyping; good at documentation; okay at writing unit tests; okay at adding simple features in more complex databases;
Anything more complex and I find it pretty much unusable, even with Claude 4. More complex C++ codebases; more niche libraries; ML, CV, more mathsy domains that require reasoning.
Not to dog the author too hard, but a look at their Github profile says a lot about the projects they've worked on and what kind of dev they are. Not much there in terms of projects or code output, but they do have 15k followers on Twitter, where they post frequently about LLMs to their audience.
They aren't talking about the tasks and the domains they're using because that's incidental; what they really want to do is just talk about LLMs to their online audience, not ship code.
I have mixed feelings; because this means there’s really no business reason to ever hire a junior; but it also (I think) threatens the stability of senior level jobs long term, especially as seniors slowly lose their knowledge and let Claude take care of things. The result is basically: When did you get into this field, by year?
I’m actually almost afraid I need to start crunching Leetcode, learning other languages, and then apply to DoD-like jobs where Claude Code (or other code security concerns) mean they need actual honest programmers without assistance.
However, the future is never certain, and nothing is ever inevitable.
aren't these people your seniors in the coming years? Its healthy to model an inflow and outflow.
I keep being told that $(WHATEVER MODEL) is the greatest thing ever, but every time I actually try to use them they're of limited (but admittedly non-zero) usefulness. There's only so many breathless blogs or comments I can read that just don't mesh with the reality I personally see.
Maybe it's sector? I generally work on Systems/OS/Drivers, large code bases in languages like C, C++ and Rust. Most larger than context windows even before you look at things like API documentation. Even as a "search and summarizer" tool I've found it completely wrong in enough cases to be functionally worthless as the time required to correct and check the output isn't a saving. But they can be handy for "autocompletion+" - like "here's a similar existing block of code, now do the same but with (changes)".
They generally seem pretty good at being like a template engine on non-templated code, so thing like renaming/refactoring or similar structure recognition can be handy. Which I suspect might also explain some of those breathless blog posts - I've seen loads which say "Any non-coder can make a simple app in seconds!" - but you could already do that, there's a million "Simple App Tutorial" codebases that would match whatever license you want, copy one, change the name at the top and you're 99% of the way to the "Wow Magic End Result!" often described.
Then they'll just get a contract to spin up a DoD-secure variant: https://www.anthropic.com/news/anthropic-and-the-department-...
Much less context babysitting too. Claude code is really good at finding the things it needs and adding them to its context. I find Cursor’s agent mode ceases to be useful at a task time horizon of 3-5 minutes but Claude Code can chug away for 10+ minutes and make meaningful progress without getting stuck in loops.
Again, all very surprising given that I use sonnet 4 w/ cursor + sometimes Gemini 2.5 pro. Claude Code is just so good with tools and not getting stuck.
If Claude is so amazing, could Anthropic not make their own fully-featured yet super-performant IDE in like a week?
E.g. I asked it to swap all on change handlers in a component to modify a use State rather than directly fire a network request, and then add on blurs for the actual network request. It didn't add use states and just added on blurs that sent network requests to the wrong endpoint. Bizarre.
My own experiments only show that this technology is unreliable.
But the other day I asked it to help add boundary logging to another legacy codebase and it produced some horrible, duplicated and redundant code. I see these huge Claude instruction files people share on social media, and I have to wonder...
Not sure if they're rationing "the smarts" or performance is highly variable.
If you want to try something better than claude code, try Cline.
There are some things in there that really take this from an average tool to something great. For example, a lot of people have no idea that it recognizes different levels of reasoning and allocates a bigger number of “thinking tokens” depending on what you ask (including using “ultrathink” to max out the thinking budget).
I honestly think that people who STILL get mostly garbage outputs just aren’t using it correctly.
Not to mention the fact that people often don't use Opus 4 and stay with Sonnet to save money.
I feel like working with Claude is what it must feel like for my boss to work with me. “Look, I did this awesome thing!”
“But it’s not what I asked for…”
I agree. It reminds me of this one junior engineer I worked with who produced awful code, and it would take longer to explain stuff to him than to just do it myself, let alone all the extra time I had to spend reviewing his awful PRs. I had hoped he would improve over time, but he took my PR comments personally and refused to keep working with me. At least Claude doesn't have an attitude.
I'm really not seeing these massive gains in my workflow either and maybe it's the nature of my general work but it's baffling how every use case for programming I'm seeing on YouTube is so surface level. At this point I've given up and don't use it at all
Not a "100x" boost, but a pretty good take on what tasks agents can do for even very good programmers.
i feel like some kind of shill, but honestly i'm anywhere from 1.5x to 10x on certain tasks. the main benefit is that i can reduce a lot of cognitive load on tasks where they are either 1) exploratory 2) throwaway 3) boilerplate-ish/refactor type stuff. because of that i have a more consistent baseline.
i still code "by hand". i still have to babysit and review almost all the lines, i don't just let it run for hours and try to review it at the end (nightmare). production app that's been running for years. i don't post youtube videos bc i don't have the time to set it up and try to disprove the "naysayers" (nor does that even matter) and its code i can't share.
the caveat here is we are a super lean team so probably i have more context into the entire system and can identify problems early on and head them off. also i have a vested interest in increasing efficiency for myself wheras if you're part of a corpo ur probably doing more work for the same comp.
This may sound more mean than I intend, but your comment is exactly the kind of thing the GP post was describing as useless yet ubiquitous.
Without concrete details about the exact steps you're taking, these conversations are heat without light.
nobody can be bothered to show how these coding llms fall flat on their face apparently with their own real detailed examples and people can't be bothered to setup some detailed youtube video with all source code because in the end i'm not trying that hard to convince people to use tools they don't want to use.
i think with all the comments maybe the more people who stumble through this the better. the cloudflare example is a decent starting point and i've already given you the general approach. i'm fine with that being a copout lol.
Of course.
By your own reckoning. There was that recent study showing how senior devs using AI thought they were 20% faster, when they were objectively 20% slower.
and this is exactly what i'm talking about. in the end who gives a shit about some study that may or may not apply to me as long its actually working.
people literally frothing at the mouth to tell people who find it useful that they are utterly wrong or delusional. if you don't like it then just go about your day, thx.
If we are to believe the hype though, shouldn’t these tools be launching software into the stratosphere? Like the CEO of stripe said AI tools provide a x100 increase in productivity. That was 3-4months ago. Shouldn’t stripe be launching rockets in to space now since that’s technically 400months of dev time? Microsoft is reportedly all in on AI coding. Shouldn’t Teams be the best, most rock solid software in existence now? There is so much hype around these tools being a super charger for more than a year, but the actual software landscape looks kind of the same to me as it did 3-4 years ago.
I use it quite aggressively and I'd probably only estimate 1.5x on average.
Not world changing because we all mostly work on boring stuff and have endless backlogs.
Understanding the problem to solve is.
Or: buying a super car might make your commute feel faster. But if everyone did it, we'd have a lot more congestion and a lot more pollution.
And is this a good thing since you can (in theory) multitask and work longer hours, or bad because you're acquiring cognitive debt (see "Your Brain on ChatGPT")?
Or, as another commenter said, it's for investors, not developers, and certainly not the scum users.
80% (99%?) of what you hear about llms are from the first group, amplified by influencers.
I'm guessing people feel the productivity boost because documenting/talking to/guiding/prompting/correcting an LLM is less mentally taxing than actually doing the work yourself even though time taken or overall effort is the same. They underestimate the amount of work they've had to put in to get something acceptable out of it.
Ah, Stone Soup: https://en.wikipedia.org/wiki/Stone_Soup
Here are some projects Claude has helped create:
1. Apache Airflow "DAG" (cron jobs) to automate dumping data from an on-prem PGSQL server to a cloud bucket. I have limited Python skills, but CC helped me focus on what I wanted to get done instead of worrying about code. It was an iterative process over a couple of days, but the net result is we now have a working model to easily perform on-prem to cloud data migrations. The Python code is complex with lots of edge conditions, but it is very readable and makes perfect sense.
2. Custom dashboard to correlate HAProxy server stats with run-time container (LXC) hooks. In this case, we needed to make sure some system services were running properly even if HAProxy said the container was running. To my surprise, CC immediately knew how to parse the HAProxy status output and match that with internal container processes. The net for this project is a very nice dashboard that tells us exactly if the container is up/down or some services inside the container are up/down. And, it even gives us detailed metrics to tell us if PGSQL replication is lagging too far behind the production server.
3. Billing summary for cloud provider. For this use case, we wanted to get a complete billing summary from our cloud provider - each VM, storage bucket, network connection, etc. And, for each object, we needed a full breakdown (VM with storage, network, compute pricing). It took a few days to get it done, but the result is a very, very nice tool that gives us a complete breakdown of what each resource costs. The first time I got it working 100%, we were able to easily save a few thousand $$ from our bill due to unused resources allocated long ago. And, to be clear, I knew nothing about API calls to the cloud provider to get this data much less the complexities of creating a web page to display the data.
4. Custom "DB Rebuild" web app. We run a number of DBs in in our dev/test network that need to get refreshed for testing. The DB guys don't know much about servers, containers, or specific commands to rebuild the DBs, so this tool is perfect. It provides a simple "rebuild db" button with status messages, etc. I wrote this with CC in a day or so, and the DB guys really like the workflow (easy for them). No need to Github tickets to do DB rebuilds; they can easily do it themselves.
Again, the key is focusing my energy on solving problems, not becoming a python/go/javascript expert. And, CC really helps me here. The productivity our team has achieved over the past few weeks is nothing short of amazing. We are creating tools that would require hiring expert coders to write, and giving us the ability to quickly iterate on new business ideas.
Besides that, I think your best bet is to find someone on youtube creating something "live" using a LLM. Something like this: https://www.youtube.com/watch?v=NW6PhVdq9R8
One trick I have gotten some milage out of was this: have Claude Code research Slash commands, then make a slash command to turn the previous conversation into a slash command.
That was cool and great! But then, of course you inevitably will interrupt it and need to do stuff to correct it, or to make a change or "not like that!" or "use this tool" or "think harder before you try that" or "think about the big picture" ... So you do that. And then you ask it to make a command and it figures out you want a /improve-command command.
So now you have primitives to build on!
Here are my current iterations of these commands (not saying they are optimal!)
https://github.com/ctoth/slashcommands/blob/master/make-comm...
https://github.com/ctoth/slashcommands/blob/master/improve-c...
A few small markdown documents and putting in the time to understand something interesting hardly seems a steep price!
When I point that out, they profusely apologize and say that of course the walls must be white and wonder why they even got the idea of making them pink in the first place.
Odd, but nice fellows otherwise. It feels like they’re 10x more productive than other contractors.
This actually happened to me Monday.
But sure, humans are deterministic clockwork mechanisms!
Are you now going to tell me how I got a bad contractor? Because that sure would sound a lot like "you're using the model wrong"
People aren't excited about AI coding because it's so much better than human coders. They're excited because it's within spitting distance while rounding down to free.
For several decades we've developed and use computers because they can be very precise and deterministic.
I genuinely don't understand how often people compare AI to junior developers.
I generally get great 1-shot (one input and the final output after all tasks are done) comments. I have moved past claude code though I am using the CLI itself with another model although I was using claude code and my reason for switching isn't that claude was a bad model it's just that it was expensive and I have access to larger models for cheaper. The CLI is the real power not the model itself per-se. Opus does perform a little better than others.
It's totally made it so I can do the code that I like to do while it works on other things during that time. I have about 60-70 different agent streams going at a time atm. Codebases sizes vary, the largest one right now is about 200m tokens (react, typescript, golang) in total and it does a good job. I've only had to tell it twice to do something differently.
I've only tried Claude Code with an external model once (Kimi K2) but it performed poorly.
The recent Kimi-K2 supposedly works great.
My own experience is that it is below sonnet and opus 4.0 on capability - but better than gemini 2.5 pro on tool calling. It's really worth trying if you don't want to spend the $100 or $200 per month on Claude Max. I love how succinct the model is.
> you can use CC with any model via
Anthropic should just open source Claude Code - they're in a position to become the VS Code of cli coding agents.
Shout out to opencode:
https://github.com/sst/opencode
which supports all the models natively and attempts to do what CC does
Edit: I see a sibling comment mention the Max plan. I wanna be clear that I am not talking about rate limits here but actual models being inaccessible - so not a rate limit issue. I hope Anthropic figures this out fast, because it is souring me on Claude Code a bit.
Here is an example of chat gpt, followed by mostly Claude that finally solved a backlight issue with my laptop.
If you aren't sure whether to pull the trigger on a subscription, I would put $5-$10 into an API console account and use CC with an API key.
Then I found the free tier of claude so I fed in the "works so far" version with the changes that the local llm made, and it fixed and updated all the issues (with clear explanation) in one go. Success!
So my next level attempt was to get all the spec and prompts for a new project (a simple manic miner style 2d game using pygame). 8 used chat gpt to craft all this and it looked sensible to me with appropriate constraints for different parts of the projrct.
Which claude created. But it keeps referring to a method which it says is not present in the code and that I'm running the wrong version. (I'm definitely not). I've tried indicating it by reference to the line number and the surrounding code but it's just gas lighting me.
Any ideas how to progress from this? I'm not expecting perfection, but it seems it's just taken me to a higher level before it runs into essentially the same issue as the local llm.
All advice appreciated, I'm just dabbling with this four a bit of fun when I can (I'm pretty unwell so do things as and when I feel up to it)
Thanks in advance.
ie, take everything written by chatgpt and have the highest-quality model you have summarize what the game does, and break down all the features in depth.
Then, take that document and feed it into claude. It may take a few iterations but the code you get will be much better than your attempt on iterating on the existing code.
Claude will likely zero-shot a better application or, at least, one that it can improve on itself.
If claude still insists on making up new features then install the context7 MCP server and ask it to use context7 when working on your request.
I think I should have made it more clear in my post, the code is claude's and was done from scratch (the first app was a mandelbrot viewer which it added features to, this is a platfrom game).
It's a single file at the moment (I did give a suggested project structure with files for each area of responsibility) and it kind-of-works.
I think I could create the missing method in the class but wanted to see if it was possible by getting the tools to do it - it's as much of an experiment in the process and the end result.
Thanks for replying, I shall investigate what you've suggested and see what happens.
You can't. This is a limitation of LLM technology. They can output the most likely token sequence, but if "likely" doesn't match "correct" for your problem then there's nothing you can do.
Also, each LLM has its own definition of what "likely" is - it comes from the training and finetuning secret sauce of that particular LLM.
I use AI like a scalpel - I go in and figure out exactly what I want, use my prompting experience to get a few functions, or up to 1 script at a time, read it, put it in, and stress-test it immediately.
As a result, I am extremely happy with my AI-generated code about 95% of the time. However, this requires that I still understand my codebase, requirements, failure modes, etc.
My philosophy is that software dev creation speed is certainly important, but durability is even more critical. Currently, it seems like going too deep with these AI tools is sacrificing the former for the latter. If all you're doing is POCs all day I could see it (even then, don't let them get too big...) but it's just not for me, at least not yet.
What I'd really want is a way to easily hide it, which I did quite frequently with Copilot as its own pane.
Is there a bigger disconnect on how you are judged in an interview vs the job now?
How are the AI only developers handling this?
AI can't think or reason, LLMs are still mostly useless for gaming interviews.
That is, how are people organizing their context and codebase to help the tooling guide themselves to the right answer?
I have some half-baked thoughts here [1], but I know there are more (better) methodologies to be discovered.
I was recently watching Seinfeld, and apparently in the 90s, picking up a friend from the airport was an important social contract. Today we just uber.
For anything but the smallest things I use claude code...
And even then...
For the bigger things, I ask it to propose to me a solution (when adding new features).
It helps when you give proper guidance: do this, use that, avoid X, be concise, ask to refactor when needed.
All in all, it's like a slightly autistic junior dev, so you need to be really explicit, but once it knows what to do, it's incredible.
That being said, whenever you're stuck on an issue, or it keeps going in circles, I tend to rollback, ask for a proper analysis based on the requirements, and fill in the details of necessary.
For the non-standard things (f.e. detect windows on a photo and determine the measurement in centimetres), you still have to provide a lot of guidance. However, once I told it to use xyz and ABC it just goes. I've never written more then a few lines of PHP in my life, but have a full API server with an A100 running, thanks to Claude.
The accumulated hours saved are huge for me, especially front-end development, refactoring, or implementing new features to see if they make sense.
For me it's a big shift in my approach to work, and I'd be really sad if I have to go back to the pre-AI area.
Truth to be told, I was a happy user of cline & Gemini and spent hundreds of dollars on API calls per month. But it never gave me the feeling Claude code gave me, the reliability for this thing is saving me 80% of my time.
I’ve mentored and managed juniors. They’re usually a net negative in productivity until they are no longer juniors.
People who enjoy mentoring juniors are generally satisfied with the ROI of iterating through LLM code generation.
People who find juniors sort-of-frustrating-but-part-of-the-job-sometimes have a higher denominator on that ROI calc, and ask themselves why they would keep banging their head against the LLM wall.
The first group is probably wiser and more efficient at multiplying their energies, in the long term.
I find myself in the second group. I run tests every couple months, but I'm still waiting for the models to have a higher R or a lower I. Any day now.
Most people who "mentor" other people (like, make it a pride and distinction part of their identity) are usually the last people you want to take advice from.
Actual mentors are the latter group, who juniors seek out or look up to.
In other words, the former group is akin to those people on YouTube who try to sell shitty courses.
It would make sense for there to be subgroups within the first group. It sounds like you prioritize results (mentee growth, possibly toward long-term contribution), and it's also likely that some people just enjoy the process of mentoring.
I've had ups and downs in this situation, but on most cases it's about showing the light to a path forward.
In most cases, the software development was straightforward, and most of the coaching was about a how to behave in the organisation they were functioning in.
One can only have so many architecture/code quality reviews, typically we evacuated the seniority of the devs on their ability to cope with people (colleagues, bosses, clients, ...)
We did have a few very bright technical people as well, but those were about 10 on a 2000-person company.
The reason I explicitly mentioned the slightly autistic junior person, is because I've worked with one, who was about to be fired, because other people had issues dealing with him.
So I moved desks, sat next to him for over a month, and he ended up becoming the champion for one of the projects we were doing, because he was very bright, precise and had a huge memory, which mattered a lot in that context.
Other stories are similar, once they were about to throw out a colleague because he was taking days to do something that should have taken a few hours max. So I say next to him, to see what he was doing.
Turned out he was refactoring all the code his feature touched because he couldn't stand bad code. So we moved him to quality control, and last time I checked he was thriving...
I guess what I'm saying is that -just like with people -, you need to find a good modus operandi, and have matching expectations, but if you can figure it out, it will pay off dividends.
Solid write up. And chock full of useful tricks!
I was manually copy pasting PR change requests today to CC where some of this would have saved my wrists some pain.
Progress doesn't end here either, imo CC is more a mid-level engineer with a top-tier senior engineer's knowledge. I think we're getting to the point where we can begin to replace the majority of engineers (even seniors) for just a handful of seniors engineers to prompt and review AI produced code and PRs.
Not quite there yet, of course, but definitely feeling that shift starting now... There's going to be huge productivity boosts for tech companies towards the end this year if we can get there.
Exciting times.
Great for the owners of tech companies and non-tech companies using tech (many non-technical, capital based who now scale with less cost base); not so great for people with tech skills who invested for their future. Which is the goal of these AI companies. Your pain/unemployment/cost is their profit/economic surplus.
To the OP its "exciting times" for capital - probably for many people however it seems like an impending nightmare is coming especially if they are relying on intellectual work to survive/provide/etc. Most CC articles on HN trend I've seen trend to the top; which shows it is definitely instigating either greed or fear in people. I would argue that "code" seems to be the most successful AI product to date - most others are just writing assistants, meme generators, risky operators, etc at least for me. Its code that seems to instigate this persistent fear.
On a side note, at least for me, AI has personally dissuaded me from learning/investing more in this career as a senior engineer with almost 20 years experience. I hope I'm wrong.
It should be capable of rebuilding VS Code but better, no?
care to provide any proof for that? in my experience it's neither.
My workflow now boils down to 2 tools really - leap.new to go from 0 to 1 because it also generates the backend code w/ infra + deployment and then I pick it up in Zed/Claude Code and continue working on it.
2. When you are in a new area, but you don't want to dive deep and just want something quick and it is not core of the app/service.
But, if you are experienced, you can see how AI can mess things up pretty quickly, hence for me it has been best used to 'fill in clear and well defined functionality' at peacemeal. Basically it is best for small bites, then large chunks.
Bunch of comments online also reflect how there's a lot of "butthurt" developers shutting things down with a closed mind - focusing only on the negatives, and not letting the positives go through.
I sound a bit philosophical but I hope I'm getting my point across.
This conversation is useless without knowing the author's skillset and use-case.
I mean, do we really want our code base to not follow a coding standard? Or are network code not to consider failure or transactional issues? I feel like all of these traits are hallmarks of good senior engineers. Really good ones learn to let go a little but no senior is going to watch a dev automated or otherwise, circumvent six layers of architecture by blasting in a static accessor or smth.
Craftsmanship, control issues and perfectionism, tend to exist for readability, to limit entropy and scope, so one can be more certain of the consequences of a chunk of code. So to consider them a problem is a weird take to me.
sounds like you can't code for shit. guidelines, standards, and formatting have developed for a reason. the reason is: less bugs and maintainability. you sound like the average cocky junior to me.
You have to watch Claude Code like a hawk. Because it's inconsistent. It will cheat, give up, change directions, and not make it clear to you that is what it's doing.
So, while it's not "junior" in capabilities, it is definitely "junior" in terms of your need as a "senior" to thoroughly review everything it does.
Or you'll regret it later.