I stopped writing as much code because of RSI and carpal tunnel but Claude has given me a way to program without pain (perhaps an order of magnitude less pain). As much as I was wanting to reject it, I literally am going to need it to continue my career.
I find it very effective to use a good STT/dictation app since giving sufficient detailed context to CC is very important, and it becomes tedious to type all of that.
I’ve experimented with several dictation apps, including super whisper, etc., and I’ve settled on Wispr Flow. I’m very picky about having good keyboard shortcuts for hands-free dictation mode (meaning having a good keyboard shortcut to toggle recording on and off), and of course, accuracy and speed. Wispr Flow seems to fit all my needs for now but I’d love to switch to a local-only app and ditch the $15/mo sub :)
Irrespective of how good Claude code actually is (I haven’t used it, but I think this article makes a really cogent case), here’s something that bothers me: I’m very junior, I have a big slow ugly codebase of gdscript (basically python) that I’m going to convert to C# to both clean it up and speed it up.
This is for a personal project, I haven’t written a ton of C# or done this amount of refactoring before, so this could be educational in multiple ways.
If I were to use Claude for this Id feel like I was robbing myself of something that could teach me a lot (and maybe motivate me to start out with structuring my code better in the future). If I don’t use Claude I feel like Im wasting my (very sparse) free time on a pretty uninspiring task that may very well be automated away in most future jobs, mostly out of some (misplaced? Masochistic?) belief about programming craft.
This sort of back and forth happens a lot in my head now with projects.
Have it generate the code. Then have another instance criticize the code and say how it could be improved and why. Then ask questions to this instance about things you don't know or understand. Ask for links. Read the links. Take notes. Internalize.
One day I was fighting Claude on some core Ruby method and it was not agreeing with me about it, so I went to check the actual docs. It was right. I have been using Ruby since 2009.
Yup, I absolutely agree with you. I've been coding professionally for around 25 years now, 10-ish before that as a hobby as a child and teenager. There's lots of stuff I know, but still lots of stuff I don't know. If my goal is to learn a new language, I'm going to build the entire thing without using a coding assistant. At most I might use Claude (not Code) to ask pointed questions, and then use those answers to write my own code (and not copy/paste anything from Claude).
Often I'll use Claude Code to write something that I know how to write, but don't feel like writing, either because it's tedious, or because it's a little bit fiddly (which I know from past experience), and I don't feel like dealing with the details until CC gives me some output that I can test and review and modify.
But sometimes, I'll admit, I just don't really care to learn that deeply. I started a project that is using Rust for the backend, but I need a frontend too. I did some React around 10 years ago, but my knowledge there (what I remember, anyway) is out of date. So sometimes I'll just ask Claude to build an entire section of a page. I'll have Claude do it incrementally, and read the code after each step so I understand what's going on. And sometimes I do tell Claude I'm not happy with the approach, and to do something differently. But in a way I kinda do not care so much about this code, aside from it being functional and maintainable-looking.
And I think that's fine! We don't have to learn everything, even if it's something we need to accomplish whatever it is we've set out to accomplish. I think the problem that you'll run into is that you might be too junior to recognize what are the things you really need to learn, and what are the things you can let something else "learn" for you.
One of the things I really worry about this current time we're in is that companies will start firing their junior engineers, with a belief (however misguided) that their senior engineers, armed with coding assistants, can be just as productive. So junior engineers will lose their normal path to gaining experience, and young adults entering college will shy away from programming, since it's hard to get a job as a junior engineer. Then when those senior engineers start to retire, there will be no one to take their places. Of course, the current crop of company management won't care; they'll have made their millions already and be retired. So... push to get as much experience as you can, and get over the hump into senior engineer territory.
It does definitely seem to be, and stands to reason, that better developers get better results out of Claude et al.
You're on the right track in noticing you'll be missing valuable lessons, and this might rob you of better outcomes even with AI in the future. As it is a side project though keeping motivation is important too.
As well, you'll eventually learn those lessons through future work if you keep coding yourself. But if instead you lean more toward assistance it is hard to say if you would become as skilled in the raw skill of coding, and that might affect yoir abilityto wield AI to full effecf.
Having done a lot of work across many languages, including gdscript and C# for various games, I do think you'll learn a huge amount from doing the work yourself and such an opportunity is a bit more rare to come by in paid work.
A lot of things that the author achieved with Claude Code is migrating or refactoring of code. To me, who started using Claude Code just two weeks ago, this seems to be one of the real strengths at the moment. We have a large business app that uses an abandoned component library and contains a lot of cruft. Migrating to another component library seemed next to impossible, but with Claude Code the whole process took me just about one week. It is making mistakes (non-matching tags for example), but with some human oversight we reached the first goal. Next goal is removing as much cruft as possible, so working on the app becomes possible or even fun again.
I remember when JetBrains made programming so much easier with their refactoring tools in IntelliJ IDEA. To me (with very limited AI experience) this seems to be a similar step, but bigger.
Really agree with the author's thoughts on maintenance here. I've run into a ton of cases where I would have written a TODO or made a ticket to capture some refactoring and instead just knocked it out right then with Claude. I've also used Claude to quickly try out a refactoring idea and then abandoned it because I didn't like how it came out. It really lowers the activation energy for these kinds of maintenance things.
Letting Claude rest was a great point in the article, too. I easily get manifold value compared to what I pay, so I haven't got it grinding on its own on a bunch of things in parallel and offline. I think it could quickly be an accelerator for burnout and cruft if you aren't careful, so I keep to a supervised-by-human mode.
I think Claude Code is great, but I really grew accustomed to the "Cursor-tab tab tab" autocomplete style. A little perplexed why the Claude Code integration into VS Code doesn't add something like this? It would make it the perfect product to me. Surprised more people do not talk about this/it isn't a more commonly requested feature.
I just use Claude Code in Cursor's terminal (both a hotkey away, very convenient). For 2 months I don't use cursor chat, but tab autocomplete is to good, definitely worth 20$.
"Cursor tab tab tab" is just nuts. I'm also getting accustomed to type carelessly, making syntax mistakes who cares if a tab can fix that. I fly with it. As per why more people dont talk about this, I have a the strong opinion that tools find success in the median of the market, not in the excellence. I think coders with a great autocomplete are a real deal. I find so boring and courtproductive chatting about a problem
Claude Code is ahead of anything else, in a very noticeable way. (I've been writing my own cli tooling for AI codegen from 2023 - and in that journey I've tried most of the options out there. It has been a big part of my work - so that's how I know.)
I agree with many things that the author is doing:
1. Monorepos can save time
2. Start with a good spec. Spend enough time on the spec. You can get AI to write most of the spec for you, if you provide a good outline.
3. Make sure you have tests from the beginning. This is the most important part. Tests (along with good specs) are how an AI agent can recurse into a good solution. TDD is back.
4. Types help (a lot!). Linters help as well. These are guard rails.
5. Put external documentation inside project docs, for example in docs/external-deps.
6. And finally, like every tool it takes time to figure out a technique that works best for you. It's arguably easier than it was (especially with Claude Code), but there's still stuff to learn. Everyone I know has a slightly different workflow - so it's a bit like coding.
I vibe coded quite a lot this week. Among them, Permiso [1] - a super simple GraphQL RBAC server. It's nowhere close to best tested and reviewed, but can be quite useful already if you want something simple (and can wait until it's reviewed.)
Another really nice use case building very sophisticated test tooling. Normally a company might not allocate enough resources to a task like that but with Claude Code it's a no brainer. Also can create very sophisticated mocks like say db mock that can parse all queries in the codebase and apply them to in memory fake tables. Would be total pain to build and maintain by hand but with claude code takes literally minutes.
I try to use claude code a lot, I keep getting very frustrated with how slow it is and how it always does things wrong. It does not feel like its saving my any mental energy on most tasks. I do gravitate towards it for some things. But then I am sometimes burned on doing that and its not pleasent.
For example, last week i decided to play with nushell, i have a somewhat simple .zshrc so i just gave it to claude and asked it to convert it to nushell. The nu it generated for the most part was not even valid, i spent 30 mins with it, it never worked. took me about 10 minutes in the docs to convert it.
So it's miserable experiences like that that make me want to never touch it, because I might get burned again. There are certainly things that I have found value in, but its so hit or miss that i just find my self not wanting to bother.
I appreciate that Orta linked to my "Full-breadth Developers" post here, for two reasons:
1. I am vain and having people link to my stuff fills the void in my broken soul
2. He REALLY put in the legwork to document in a concrete way what it looks like for these tools to enable someone to move up a level of abstraction. The iron triangle has always been Quality, Scope, Time. This innovation is such an accelerant that that ambitious programmers can now imagine game-changing increases in scope without sacrificing quality and in the same amount of time.
For this particular moment we're in, I think this post will serve as a great artifact of what it felt like.
Coding agents are empowering, but it is not well appreciated that they are setting a new baseline. It will soon not be considered impressive to do all the things that the author did, but expected. And you will not work less but the same hours -- or more, if you don't use agents.
Despite this, I think agents are a very welcome new weapon.
I have about two weeks of using Claude Code and to be honest, as a vibe coding skeptic, I was amazed. It has a learning curve. You need to learn how to give it proper context, how to chunk up the work, etc. And you need to know how to program, obviously. Asking it to do something you don't know how to do, that's just asking for a disaster. I have more than 25 years of experience, so I'm confident with anything Claude Code will try to do and can review it, or stop and redirect it. About 10-15 years ago, I was dreaming about some kind of neural interface, where I could program without writing any code. And I realized that with Claude Code, it's kind of here.
A couple of times I hit the daily limits and decided to try Gemini CLI with the 2.5 pro model as a replacement. That's not even comparable to Claude Code. The frustration with Gemini is just not worth it.
I couldn't imagine paying >100$/month for a dev tool in the past, but I'm seriously considering upgrading to the Max plans.
I have not tried it, for a variety of reasons, but my (quite limited, anecdotal, and gratis) experience with other such tools is, that I can get them to write something I could perhaps get as an answer on StackOverflow: Limited scope, limited length, address at most one significant issue; and perhaps that has to do with what they are trained on. But that once things get complicated, it's hopeless.
You said Claude Code was significantly better than some alternatives, so better than what I describe, but - we need to know _on what_.
Just a few months ago I couldn't imagine paying more than $20/mo for any kind of subscription, but here I am paying $200/mo for the Max 20 plan!
Similarly amazed as an experienced dev with 20 YoE (and a fellow Slovak, although US based). The other tools, while helpful, were just not "there" and they were often simply more trouble than they were worth producing a lot of useless garbage. Claude Code is clearly on another level, yes it needs A LOT of handholding; my MO is do Plan Mode until I'm 100% sure it understands the reqs and the planned code changes are reasonable, then let it work, and finally code review what it did (after it auto-fixes things like compiler errors, unit test failures and linting issues). It's kind of like a junior engineer that is a little bit daft but very knowledgeable but works super, super fast and doesn't talk back :)
It is definitely the future, what can I say? This is a clear direction where software development is heading.
If you are a Senior Developer, who is comfortable giving a Junior tips, and then guiding them to fixing them (or just stepping in for a brief moment and writing where they missed something) this is for you. I'm hearing from Senior devs all over thought, that Junior developers are just garbage at it. They product slow, insecure, or just outright awful code with it, and then they PR the code they don't even understand.
For me the sweet spot is for boilerplate (give me a blueprint of a class based on a description), translate a JSON for me into a class, or into some other format. Also "what's wrong with this code? How would a Staff Level Engineer white it?" those questions are also useful. I've found bugs before hitting debug by asking what's wrong with the code I just pounded on my keyboard by hand.
Completely agree. You really have to learn how to use it.
For example, heard many say that doing big refactorings is causing problems. Found a way that is working for SwiftUI projects. I did a refactoring, moving files, restructuring large files into smaller components, and standardizing component setup of different views.
The pattern that works for me: 1) ask it to document the architecture and coding standards, 2) ask it to create a plan for refactoring, 3) ask it to do a low-risk refactoring first, 4) ask it to update the refacting plan, and then 5) go through all the remaining refactorings.
The refactoring plan comes with timeline estimates in days, but that is completely rubbish with claude code. Instead i asked it to estimate in 1) number of chat messages, 2) number of tokens, 3) cost based on number of tokens, 4) number of files impacted.
Another approach that works well is to first generate a throw away application. Then ask it to create documentation how to do it right, incorporate all the learning and where it got stuck. Finally, redo the application with these guidelines and rules.
Another tip, sometimes when it gets stuck, i open the project in windsurf, and ask another LLM (e.g., Gemini 2.5 pro, or qwen coder) to review the project and problem and then I will ask windsurf to provide me with a prompt to instruct claude code to fix it. Works well in some cases.
Also, biggest insight so far: don't expect it to be perfect first time. It needs a feedback loop: generate code, test the code, inspect the results and then improve the code.
Works well for SQL, especially if it can access real data: inspect the database, try some queries, try to understand the schema from your data and then work towards a SQL query that works. And then often as a final step it will simplify the working query.
I use an MCP tool with full access to a test database, so you can tell it to run explain plan and look at the statistics (pg_stat_statements). It will draw a mermaid diagram of your query, with performance numbers included (nr records retrieved, cache hit, etc), and will come back with optimized query and index suggestions.
Tried it also on csv and parquet files with duckdb, it will run the explain plan, compare both query, explain why parquet is better, will see that the query is doing predicate push down, etc.
Also when it gets things wrong, instead of inspecting the code, i ask it to create a design document with mermaid diagrams describing what it has built. Quite often that quickly shows some design mistake that you can ask it to fix.
Also with multiple tools on the same project, you have the problem of each using it's own way of keeping track of the plan. I asked claude code to come up with rules for itself and windsurf to collaborate on a project. It came back with a set of rules for CLAUDE.md and .windsurfrules on which files to have, and how to use them (PLAN.md, TODO.md, ARCHITECTURE.md, DECISION.md, COLLABORATION.md)
Feels like the most valuable skill to have as a programmer in times of Claude Code is that of carefully reading spec documentation and having an acute sense of critical thinking when reviewing code.
I haven't used Claude Code - but have been using Amp a lot recently. Amp always hits on target. They created something really special.
Has anyone here used both Claude Code and Amp and can compare the two's effectiveness? I know one is CLI and the other an editor extensions. I'm looking for comparisons beyond that. Thanks!
Technically you’re not vibe coding. You’re using AI to do software engineering. Vibe coding is specifically the process of having AI produce code and plowing ahead without understanding it.
I know I’m being pedantic, but people mean very different things when they talk about this stuff, and I don’t think any credence should be given to vibe coding.
> I couldn't imagine paying >100$/month for a dev tool in the past, but I'm seriously considering upgrading to the Max plans.
Sadly, my experience with the Max plan has been extremely poor. It’s not even comparable, I’ve been vastly experimenting with claude code in the last weeks, spending more than 80$ per day, it’s amazing. The problem is that in the Max plan you’re not the one managing the context length, and this ruins the model ability to keep things memory. Of course this is expected, the longer the context the more expensive to run, but it’s so frustrating to fail in a coding task because it’s so obvious the model lost a crucial part of the context.
One thing I’ve started doing is using Gemini cli as a sidecar for Claude Code to load in a huge amount of context around a set of changes to get a second opinion - it’s been pretty handy for that particular use case due to its context size advantage
I found Gemini CLI to be totally useless too. Last week I tried Claude Code with GLM4.5 (via z.ai API), though, and it was genuinely on par with Sonnet.
My experience has been similar, over perhaps 4-6 weeks of Claude Code. My first few days were a bit rough, and I was tempted to give up and proclaim that all my skeptic's opinions were correct and that it was useless. But there is indeed a learning curve to using it. After a month I'm still learning, but I can get it to give me useful output that I'm happy committing to my projects, after reviewing it line by line.
Agreed that context and chunking are the key to making it productive. The times when I've tried to tell it (in a single prompt) everything I want it to do, were not successful. The code was garbage, and a lot of it just didn't do what I wanted it to do. And when there are a lot of things that need to be fixed, CC has trouble making targeted changes to fix issues one by one. Much better is to build each small chunk, and verify that it fully works, before moving on to the next.
You also have to call its bullshit: sometimes it will try to solve a problem in a way you know is wrong, so you have to stop it and tell it to do it in another way. I suppose I shouldn't call it "bullshit"; if we're going to use the analogy of CC being like an inexperienced junior engineer, then that's just the kind of thing that happens when you pair with a junior.
I still often do find that I give it a task, and when it's done, realize that I could have finished it much faster. But sometimes the task is tedious, and I'm fine with it taking a little longer if I don't have to do it myself. And sometimes it truly does take care of it faster than I would have been able to. In the case of tech that I'm learning myself (React, Tailwindcss, the former of which I dabbled with 10 years ago, but my knowledge is completely out of date), CC has been incredibly useful when I don't really know how to do something. I'm fine letting CC do it, and then I read the code and learn something myself, instead of having to pore over various tutorials of varying quality in order to figure it out on my own.
So I think I'm convinced, and I'll continue to make CC more and more a part of my workflow. I'm currently on the Pro plan, and have hit the usage limits a couple times. I'm still a little shy about upgrading to Max and spending $100/mo on a dev tool... not sure if I'll get over that or not.
> I have about two weeks of using Claude Code and to be honest, as a vibe coding skeptic, I was amazed.
And, yet, when I asked it to correct a CMake error in a fully open source codebase (broken dependency declaration), it couldn't work it out. It even started hallucinating version numbers and dependencies that were so obviously broken that at least it was obvious to me that it wasn't helping.
This has been, and continues to be, my experience with AI coding. Every time I hit something that I really, really want the AI to do and get right (like correcting my build system errors), it fails and fails miserably.
It seems like everybody who sings the praises of AI coding all have one thing in common--Javascript. Make of that what you will.
I have a similar amount of engineering experience, was highly skeptical, and I've come to similar conclusions with Claude Code after spending two weeks on a greenfield project (TS api, react-native client, TS/React admin panel).
As I've improved planning and context management, the results have been fairly consistent. As long as I can keep a task within the context window, it does a decent job almost every time. And occasionally I have to have it brute-force its way to green lint/typecheck/tests. That's been one of the biggest speed bumps.
I've found that gemini is great at the occasional detailed code-review to help find glaring issues or things that were missed, but having it implement anything has been severely lacking. I have to literally tell it not to do anything because it will gladly just start writing files on a whim. I generally use the opus model to write detailed plans, sonnet to implement, and then opus and gemini to review and plan refactors.
I'm impressed. The progress is SLOW. I'd have gotten to the stage I'm at in 1/3 to 1/2 the time, likely with fewer tests and significantly less process documentation. But the results are otherwise fairly great. And the learning process has kept me motivated to keep this old side-project moving.
I was switching between two accounts for a week while testing, but in the end upgraded to the $100/month plan and I think I've been rate-limited once since. I don't know if I'll be using this for every-day professional work, but I think it's a great tool for a few categories of work.
check out openrouter.ai you can pay for credits that get used per prompt instead of forking out a fixed lump sum and it rotates keys so you can avoid being throttled, you can even use the same credits on any model in their index
I completed my degree over 20 years ago and due to dot com bust and the path I took never coded as a full time role, some smallbits of dev and scripting but nothing where I would call myself a developer. I've had loads of ideas down through the years but never had the time work to complete them or learn the language/stack to complete them. Over the last 3 weeks I've been working on something small that should be ready for a beta release by the end of August. The ability to sit down and work on a feature or bug when I only have a spare 30 mins and be immediately productive without having to get in the zone is a game changer for me. Also while I can read and understand the code writing it would be at least 10 times slower for me. This is a small codebase that will have less than 5k lines and is not complicated so github copilot is working well for me in this case.
I could see me paying for higher tiers given the productivity gains.
The only issue I can see is that we might end up with a society where those that can afford the best subscriptions have more free time, get more done, make more money and are more successful in general. Even current base level subscriptions are too expensive for huge percentage of the global population.
The more I use it the more I realise my first two weeks and the amazement I felt were an illusion.
I’m not going to tell you it’s not useful, it is. But then shine wears off pretty fast and when it does, you’re basically left with a faster way to type. At least in my experience.
Gemini is not that good right now. GLM-4.5, which just came out, is pretty decent and very cheap. I use these with the RooCode plugin for VSCode that connects to it via OpenRouter. $10 of credits lasts a day of coding for me where as Claude would run that out in an hour.
>I was dreaming about some kind of neural interface, where I could program without writing any code. And I realized that with Claude Code, it's kind of here.
I had a similar thought about the Turing Test…
It as science fiction for decades… then it passed silently in the night and we barely noticed.
I have been coding with claude code for about 3 weeks and I love it. I have bout 10yoe and mostly do Python ML / Data Eng. Here are a few reasons:
1. It takes away the pain of starting. I have no barrier to writing text but there is a barrier to writing the first line of code, to a large extend coming form just remembering the context, where to import what from, setting up boilerplate etc.
2. While it works I can use my brain capacity to think about what I'm doing.
3. I can now do multiple things in parallel.
4. It makes it so much easier to "go the extra mile" (I don't add "TODOs" anymore in the code I just spin up a new Claude for it)
5. I can do much more analysis, (like spinnig up detailed plotting / analysis scripts)
6. It fixes most simple linting/typing/simple test bugs for me automatically.
Overall I feel like this kind of coding allows me to focus about the essence: What should I be doing? Is the output correct? What can we do to make it better?
I've been using Claude code 12-16 hours a day since I first got it running two weeks ago.
Here's the tips I've discovered:
1. Immediately change to sonnet (the cli defaults to opus for max users). I tested coding with opus extensively and it never matches the quality of sonnet.
2. Compacting often ends progress - it's difficult to get back to the same quality of code after compacting.
3. First prompt is very important and sets the vibe. If your instance of Claude seems hesitant, doubtful, sometimes even rude, it's always better to end the session and start again.
4. There are phrases that make it more effective. Try, "I'm so sorry if this is a bad suggestion, but I want to implement x and y." For whatever reason it makes Claude more eager to help.
5. Monolithic with docker orchestration: I essentially 10x'd when I started letting Claude itself manage docker containers, check their logs for errors, rm them, rebuild them, etc. Now I can get an entirely new service online in a docker container, from zero to operational, in one Claude prompt.
5. it's not just docker, give it playwright MCP server so it can see what it is implementing in UI and requests
6. start in plan mode and iterate on the plan until you're happy
7. use slash commands, they are mini prompts you can keep refining over time, including providing starting context and reminding it that it can use tools like gh to interact with Github
not sure I agree on 1.
2. compact when you are at a good stop, not when you are forced to because you are at 0%
Where are you hosting those containers? Our serverless/linux cli/browser IDE at https://brilliant.mplode.dev runs on containers in our nascent cloud platform and we’re almost ready to start serving arbitrary containers on it deployed directly from the IDE. I’m curious if there are any latency/data/auth/etc pain points you’ve been running into
Sometimes it's a bit too eager to mess around inside the containers, like when I ask it to understand some code sometimes it won't stop trying to run it inside the container in a myriad of ways that won't work.
It once did a container exec that piped the target file into the projects cli command runner, which did nothing, but gives you an example of the string of wacky ways it will insist on running code instead of just reading it.
The real power of Claude Code comes when you realise it can do far more than just write code.
It can, in fact, control your entire computer. If there's a CLI tool, Claude can run it. If there's not a CLI tool... ask Claude anyway, you might be
surprised.
E.g. I've used Claude to crop and resize images, rip MP3s from YouTube videos, trim silence from audio files, the list goes on. It saves me incredible amounts of time.
I don't remember life before it. Never going back.
Completely agree. Another use case is a static site generator. I just write posts with whatever syntax I want and tell Claude Code to make it into a blog post in the same format. For example, I can just write in the post “add image image.jpeg here” and it will add it - much easier than messing around with Markdown or Hugo.
I got it to diagnose why my Linux PC was crashing. It did a lot of journalctl grepping on my behalf and was glad for its help. Think it may have helped fix it but will see.
You probably want to give Claude a computer. I'm not sure you always want to give it your computer unless you're in the loop.
We have Linux instances running an IDE running in cloud vms that we can access through the browser at https://brilliant.mplode.dev. Personally I think this is closer to the ideal UX for operating an agent (our environment doesn't install agents by default yet, but you should be able to just install them manually). You don't have to do anything to set up terminal access or ssh except sign in and wait for your initial instance to start, and once you have any instance provisioned it automatically pauses and resumes based on whether your browser has it open. It's literally Claude + A personal Linux instance + an IDE that you can just open from a link
Pretty soon I should be able run as many of these at a time as I can afford, and control all of their permissions/filesystems/whatever with JWTs and containers. If it gets messed up or needs my attention I open it with the IDE as my UI and can just dive in and fix it. I don't need a regular Linux desktop environment or UI or anything. Just render things in panes of the IDE or launch a container serving a webapp doing what I want and open it instead of the IDE. Haven't ever felt this excited about tech progress
Beyond just running CLI commands, you can have CC interact with those, e.g I built this little tool that gives CC a Tmux-cli command (a convenience wrapper around Tmux) that lets it interact with CLI applications and monitor them etc:
For example this lets CC spawn another CC instance and give it a task (way better than the built-in spawn-and-let-go black box), or interact with CLI scripts that expect user input, or use debuggers like Pdb for token-efficient debugging and code-understanding, etc.
Over the holidays I built a plan for an app that would be worthwhile to my children, oldest son first. That plan developed to several thousand words of planning documents (MVP, technical stack, layout). That was just me lying in the sun with Claude on mobile.
Today I (not a programmer, although programming for 20+ years, but mostly statistics) started building with Claude Code via Pro. Burned through my credits in about 3 hours. Got to MVP (happy tear in my eye). Actually one of the best looks I've ever gotten from my son. A look like, wow, dad, that's more than I'd ever think you could manage.
Tips:
- Plan ahead! I've had Claude tell me that a request would fit better way back on the roadmap. My roadmap manages me.
- Force Claude to build a test suite and give debugging info everywhere (backend, frontend).
- Claude and me work together on a clear TODO. He needs guidance as well as I do. It forgot a very central feature of my MVP. Do not yet know why. Asked kindly and it was built.
Questions (not specifically to you kind HN-folks, although tips are welcome):
- Why did I burn through my credits in 3 hours?
- How can I force Claude to keep committed to my plans, my CLAUDE.md, etc.
- Is there a way to ask Claude to check the entire project for consistency? And/Or should I accept that vibing will leave crusts spread around?
I'm on a pro plan, also run into limits within 2 hours, then have to wait until the limits of the 5 hour window reset (next reset is in 1 hour 40 minutes at 2am)...
You can just ask claude to review your code, write down standard, verify that code is produced according to standards and guidelines. And if it finds that project is not consistent, ask it to make a plan and execute on the plan.
Anybody had similarly good experience with Gemini CLI? I'm only a hobbyist coder, so paying for Claude feels silly when Gemini is free (at least for now), but so far I've only used it inside Cline-like extensions
I’ve used both. Claude more extensively. I’ve had good results with Gemini too, however it seems easier to get stuck in a loop. Happens with Claude too but not quite as frequent.
By loop I mean you tell it no don’t implement this service, look at this file instead and mimic that and instead it does what it did before.
I think it's possible Claude Code might be the most transformative piece of software since ChatGPT. It's a step towards an AI agent that can actually _act_ at a fundamental level - with any command that can be found on a computer - in a way that's beyond the sandboxed ChatGPT or even just driving a browser.
I recently tried a 7-day trial version of Claude Code. I had 3 distinct experiences with it: one obviously positive, one bad, and one neutral-but-trending-positive.
The bad experience was asking it to produce a relatively non-trivial feature in an existing Python module.
I have a bunch of classes for writing PDF files. Each class corresponds to a page template in a document (TitlePage, StatisticsPage, etc). Under the hood these classes use functions like `draw_title(x, y, title)` or `draw_table(x, y, data)`. One of these tables needed to be split across multiple pages if the number of rows exceeded the page space. So I needed Claude Code to do some sort of recursive top-level driver that would add new pages to a document until it exhausted the input data.
I spent about an hour coaching Claude through the feature, and in the end it produced something that looked superficially correct, but didn't compile. After spending some time debugging, I moved on and wrote the thing by hand. This feature was not trivial even for me to implement, and it took about 2 days. It broke the existing pattern in the module. The module was designed with the idea that `one data container = one page`, so splitting data across multiple pages was a new pattern the rest of the module needed to be adapted to. I think that's why Claud did not do well.
+++
The obviously good experience with Claude was getting it to add new tests to a well-structured suite of integration tests. Adding tests to this module is a boring chore, because most of the effort goes into setting up the input data. The pattern in the test suite is something like this: IntegrationTestParent class that contains all the test logic, and a bunch of IntegrationTestA/B/C/D that do data set up, and then call the parent's test method.
Claude knocked this one out of the park. There was a clear pattern to follow, and it produced code that was perfect. It saved me 1 or 2 hours, but the cool part was that it was doing this in its own terminal window, while I worked on something else. This is a type of simple task I'd give to new engineers to expose them to existing patterns.
+++
The last experience was asking it to write a small CLI tool from scratch in a language I don't know. The tool worked like this: you point it at a directory, and it then checks that there are 5 or 6 files in that directory, and that the files are named a certain way, and are formatted a certain way. If the files are missing or not formatted correctly, throw an error.
The tool was for another team to use, so they could check these files, before they tried forwarding these files to me. So I needed an executable binary that I could throw up onto Dropbox or something, that the other team could just download and use. I primarily code in Python/JavaScript, and making a shareable tool like that with an interpreted language is a pain.
So I had Claude whip something up in Golang. It took about 2 hours, and the tool worked as advertised. Claude was very helpful.
On the one hand, this was a clear win for Claude. On the other hand, I didn't learn anything. I want to learn Go, and I can't say that I learned any Go from the experience. Next time I have to code a tool like that, I think I'll just write it from scratch myself, so I learn something.
+++
Eh. I've been using "AI" tools since they came out. I was the first at my company to get the pre-LLM Copilot autocomplete, and when ChatGPT became available I became a heavy user overnight. I have tried out Cursor (hate the VSCode nature of it), and I tried out the re-branded Copilot. Now I have tried Claude Code.
I am not an "AI" skeptic, but I still don't get the foaming hype. I feel like these tools at best make me 1.5X -- which is a lot, so I will always stay on top of new tooling -- but I don't feel like I am about to be replaced.
I don't know if it's something only I "perceive," but as a 50-year-old who started learning to use computers from the command line, using Claude Code's CLI mode gives me a unique sense of satisfaction.
113 comments
[ 5.0 ms ] story [ 83.5 ms ] threadI’ve experimented with several dictation apps, including super whisper, etc., and I’ve settled on Wispr Flow. I’m very picky about having good keyboard shortcuts for hands-free dictation mode (meaning having a good keyboard shortcut to toggle recording on and off), and of course, accuracy and speed. Wispr Flow seems to fit all my needs for now but I’d love to switch to a local-only app and ditch the $15/mo sub :)
This is for a personal project, I haven’t written a ton of C# or done this amount of refactoring before, so this could be educational in multiple ways.
If I were to use Claude for this Id feel like I was robbing myself of something that could teach me a lot (and maybe motivate me to start out with structuring my code better in the future). If I don’t use Claude I feel like Im wasting my (very sparse) free time on a pretty uninspiring task that may very well be automated away in most future jobs, mostly out of some (misplaced? Masochistic?) belief about programming craft.
This sort of back and forth happens a lot in my head now with projects.
One day I was fighting Claude on some core Ruby method and it was not agreeing with me about it, so I went to check the actual docs. It was right. I have been using Ruby since 2009.
What bottlenecks are you experiencing?
I'm a developer experienced with Python (GDScript-like) and C#, but am new to Godot and started with GDScript.
Then i'd ask it to create a plan to recreate it in c#.
Next i'd ask claude code to generate a new project in c#, following the small steps it defined in the planning document.
Then i'd ask claude code to review its experience building the app and update the original plan document with these insights.
Then throw away the first c# project, and have another go at it. Make sure the plan includes starting with tests.
Often I'll use Claude Code to write something that I know how to write, but don't feel like writing, either because it's tedious, or because it's a little bit fiddly (which I know from past experience), and I don't feel like dealing with the details until CC gives me some output that I can test and review and modify.
But sometimes, I'll admit, I just don't really care to learn that deeply. I started a project that is using Rust for the backend, but I need a frontend too. I did some React around 10 years ago, but my knowledge there (what I remember, anyway) is out of date. So sometimes I'll just ask Claude to build an entire section of a page. I'll have Claude do it incrementally, and read the code after each step so I understand what's going on. And sometimes I do tell Claude I'm not happy with the approach, and to do something differently. But in a way I kinda do not care so much about this code, aside from it being functional and maintainable-looking.
And I think that's fine! We don't have to learn everything, even if it's something we need to accomplish whatever it is we've set out to accomplish. I think the problem that you'll run into is that you might be too junior to recognize what are the things you really need to learn, and what are the things you can let something else "learn" for you.
One of the things I really worry about this current time we're in is that companies will start firing their junior engineers, with a belief (however misguided) that their senior engineers, armed with coding assistants, can be just as productive. So junior engineers will lose their normal path to gaining experience, and young adults entering college will shy away from programming, since it's hard to get a job as a junior engineer. Then when those senior engineers start to retire, there will be no one to take their places. Of course, the current crop of company management won't care; they'll have made their millions already and be retired. So... push to get as much experience as you can, and get over the hump into senior engineer territory.
You're on the right track in noticing you'll be missing valuable lessons, and this might rob you of better outcomes even with AI in the future. As it is a side project though keeping motivation is important too.
As well, you'll eventually learn those lessons through future work if you keep coding yourself. But if instead you lean more toward assistance it is hard to say if you would become as skilled in the raw skill of coding, and that might affect yoir abilityto wield AI to full effecf.
Having done a lot of work across many languages, including gdscript and C# for various games, I do think you'll learn a huge amount from doing the work yourself and such an opportunity is a bit more rare to come by in paid work.
I remember when JetBrains made programming so much easier with their refactoring tools in IntelliJ IDEA. To me (with very limited AI experience) this seems to be a similar step, but bigger.
Letting Claude rest was a great point in the article, too. I easily get manifold value compared to what I pay, so I haven't got it grinding on its own on a bunch of things in parallel and offline. I think it could quickly be an accelerator for burnout and cruft if you aren't careful, so I keep to a supervised-by-human mode.
Wrote up some more thoughts a few weeks ago at https://www.modulecollective.com/posts/agent-assisted-coding....
It feels like ChatGPT on cocaine, I mean, I asked for a small change and it came with 5 solutions changing all my codebase.
I agree with many things that the author is doing:
1. Monorepos can save time
2. Start with a good spec. Spend enough time on the spec. You can get AI to write most of the spec for you, if you provide a good outline.
3. Make sure you have tests from the beginning. This is the most important part. Tests (along with good specs) are how an AI agent can recurse into a good solution. TDD is back.
4. Types help (a lot!). Linters help as well. These are guard rails.
5. Put external documentation inside project docs, for example in docs/external-deps.
6. And finally, like every tool it takes time to figure out a technique that works best for you. It's arguably easier than it was (especially with Claude Code), but there's still stuff to learn. Everyone I know has a slightly different workflow - so it's a bit like coding.
I vibe coded quite a lot this week. Among them, Permiso [1] - a super simple GraphQL RBAC server. It's nowhere close to best tested and reviewed, but can be quite useful already if you want something simple (and can wait until it's reviewed.)
[1]: https://github.com/codespin-ai/permiso
Most projects have their documentation on their website. Do you spend time formatting it into a clean Markdown file?
For example, last week i decided to play with nushell, i have a somewhat simple .zshrc so i just gave it to claude and asked it to convert it to nushell. The nu it generated for the most part was not even valid, i spent 30 mins with it, it never worked. took me about 10 minutes in the docs to convert it.
So it's miserable experiences like that that make me want to never touch it, because I might get burned again. There are certainly things that I have found value in, but its so hit or miss that i just find my self not wanting to bother.
1. I am vain and having people link to my stuff fills the void in my broken soul
2. He REALLY put in the legwork to document in a concrete way what it looks like for these tools to enable someone to move up a level of abstraction. The iron triangle has always been Quality, Scope, Time. This innovation is such an accelerant that that ambitious programmers can now imagine game-changing increases in scope without sacrificing quality and in the same amount of time.
For this particular moment we're in, I think this post will serve as a great artifact of what it felt like.
Despite this, I think agents are a very welcome new weapon.
A couple of times I hit the daily limits and decided to try Gemini CLI with the 2.5 pro model as a replacement. That's not even comparable to Claude Code. The frustration with Gemini is just not worth it.
I couldn't imagine paying >100$/month for a dev tool in the past, but I'm seriously considering upgrading to the Max plans.
I have not tried it, for a variety of reasons, but my (quite limited, anecdotal, and gratis) experience with other such tools is, that I can get them to write something I could perhaps get as an answer on StackOverflow: Limited scope, limited length, address at most one significant issue; and perhaps that has to do with what they are trained on. But that once things get complicated, it's hopeless.
You said Claude Code was significantly better than some alternatives, so better than what I describe, but - we need to know _on what_.
Similarly amazed as an experienced dev with 20 YoE (and a fellow Slovak, although US based). The other tools, while helpful, were just not "there" and they were often simply more trouble than they were worth producing a lot of useless garbage. Claude Code is clearly on another level, yes it needs A LOT of handholding; my MO is do Plan Mode until I'm 100% sure it understands the reqs and the planned code changes are reasonable, then let it work, and finally code review what it did (after it auto-fixes things like compiler errors, unit test failures and linting issues). It's kind of like a junior engineer that is a little bit daft but very knowledgeable but works super, super fast and doesn't talk back :)
It is definitely the future, what can I say? This is a clear direction where software development is heading.
For me the sweet spot is for boilerplate (give me a blueprint of a class based on a description), translate a JSON for me into a class, or into some other format. Also "what's wrong with this code? How would a Staff Level Engineer white it?" those questions are also useful. I've found bugs before hitting debug by asking what's wrong with the code I just pounded on my keyboard by hand.
For example, heard many say that doing big refactorings is causing problems. Found a way that is working for SwiftUI projects. I did a refactoring, moving files, restructuring large files into smaller components, and standardizing component setup of different views.
The pattern that works for me: 1) ask it to document the architecture and coding standards, 2) ask it to create a plan for refactoring, 3) ask it to do a low-risk refactoring first, 4) ask it to update the refacting plan, and then 5) go through all the remaining refactorings.
The refactoring plan comes with timeline estimates in days, but that is completely rubbish with claude code. Instead i asked it to estimate in 1) number of chat messages, 2) number of tokens, 3) cost based on number of tokens, 4) number of files impacted.
Another approach that works well is to first generate a throw away application. Then ask it to create documentation how to do it right, incorporate all the learning and where it got stuck. Finally, redo the application with these guidelines and rules.
Another tip, sometimes when it gets stuck, i open the project in windsurf, and ask another LLM (e.g., Gemini 2.5 pro, or qwen coder) to review the project and problem and then I will ask windsurf to provide me with a prompt to instruct claude code to fix it. Works well in some cases.
Also, biggest insight so far: don't expect it to be perfect first time. It needs a feedback loop: generate code, test the code, inspect the results and then improve the code.
Works well for SQL, especially if it can access real data: inspect the database, try some queries, try to understand the schema from your data and then work towards a SQL query that works. And then often as a final step it will simplify the working query.
I use an MCP tool with full access to a test database, so you can tell it to run explain plan and look at the statistics (pg_stat_statements). It will draw a mermaid diagram of your query, with performance numbers included (nr records retrieved, cache hit, etc), and will come back with optimized query and index suggestions.
Tried it also on csv and parquet files with duckdb, it will run the explain plan, compare both query, explain why parquet is better, will see that the query is doing predicate push down, etc.
Also when it gets things wrong, instead of inspecting the code, i ask it to create a design document with mermaid diagrams describing what it has built. Quite often that quickly shows some design mistake that you can ask it to fix.
Also with multiple tools on the same project, you have the problem of each using it's own way of keeping track of the plan. I asked claude code to come up with rules for itself and windsurf to collaborate on a project. It came back with a set of rules for CLAUDE.md and .windsurfrules on which files to have, and how to use them (PLAN.md, TODO.md, ARCHITECTURE.md, DECISION.md, COLLABORATION.md)
Has anyone here used both Claude Code and Amp and can compare the two's effectiveness? I know one is CLI and the other an editor extensions. I'm looking for comparisons beyond that. Thanks!
I know I’m being pedantic, but people mean very different things when they talk about this stuff, and I don’t think any credence should be given to vibe coding.
Sadly, my experience with the Max plan has been extremely poor. It’s not even comparable, I’ve been vastly experimenting with claude code in the last weeks, spending more than 80$ per day, it’s amazing. The problem is that in the Max plan you’re not the one managing the context length, and this ruins the model ability to keep things memory. Of course this is expected, the longer the context the more expensive to run, but it’s so frustrating to fail in a coding task because it’s so obvious the model lost a crucial part of the context.
Agreed that context and chunking are the key to making it productive. The times when I've tried to tell it (in a single prompt) everything I want it to do, were not successful. The code was garbage, and a lot of it just didn't do what I wanted it to do. And when there are a lot of things that need to be fixed, CC has trouble making targeted changes to fix issues one by one. Much better is to build each small chunk, and verify that it fully works, before moving on to the next.
You also have to call its bullshit: sometimes it will try to solve a problem in a way you know is wrong, so you have to stop it and tell it to do it in another way. I suppose I shouldn't call it "bullshit"; if we're going to use the analogy of CC being like an inexperienced junior engineer, then that's just the kind of thing that happens when you pair with a junior.
I still often do find that I give it a task, and when it's done, realize that I could have finished it much faster. But sometimes the task is tedious, and I'm fine with it taking a little longer if I don't have to do it myself. And sometimes it truly does take care of it faster than I would have been able to. In the case of tech that I'm learning myself (React, Tailwindcss, the former of which I dabbled with 10 years ago, but my knowledge is completely out of date), CC has been incredibly useful when I don't really know how to do something. I'm fine letting CC do it, and then I read the code and learn something myself, instead of having to pore over various tutorials of varying quality in order to figure it out on my own.
So I think I'm convinced, and I'll continue to make CC more and more a part of my workflow. I'm currently on the Pro plan, and have hit the usage limits a couple times. I'm still a little shy about upgrading to Max and spending $100/mo on a dev tool... not sure if I'll get over that or not.
And, yet, when I asked it to correct a CMake error in a fully open source codebase (broken dependency declaration), it couldn't work it out. It even started hallucinating version numbers and dependencies that were so obviously broken that at least it was obvious to me that it wasn't helping.
This has been, and continues to be, my experience with AI coding. Every time I hit something that I really, really want the AI to do and get right (like correcting my build system errors), it fails and fails miserably.
It seems like everybody who sings the praises of AI coding all have one thing in common--Javascript. Make of that what you will.
As I've improved planning and context management, the results have been fairly consistent. As long as I can keep a task within the context window, it does a decent job almost every time. And occasionally I have to have it brute-force its way to green lint/typecheck/tests. That's been one of the biggest speed bumps.
I've found that gemini is great at the occasional detailed code-review to help find glaring issues or things that were missed, but having it implement anything has been severely lacking. I have to literally tell it not to do anything because it will gladly just start writing files on a whim. I generally use the opus model to write detailed plans, sonnet to implement, and then opus and gemini to review and plan refactors.
I'm impressed. The progress is SLOW. I'd have gotten to the stage I'm at in 1/3 to 1/2 the time, likely with fewer tests and significantly less process documentation. But the results are otherwise fairly great. And the learning process has kept me motivated to keep this old side-project moving.
I was switching between two accounts for a week while testing, but in the end upgraded to the $100/month plan and I think I've been rate-limited once since. I don't know if I'll be using this for every-day professional work, but I think it's a great tool for a few categories of work.
I could see me paying for higher tiers given the productivity gains.
The only issue I can see is that we might end up with a society where those that can afford the best subscriptions have more free time, get more done, make more money and are more successful in general. Even current base level subscriptions are too expensive for huge percentage of the global population.
I’m not going to tell you it’s not useful, it is. But then shine wears off pretty fast and when it does, you’re basically left with a faster way to type. At least in my experience.
It’s amazing , but it’s dumb.
I had a similar thought about the Turing Test…
It as science fiction for decades… then it passed silently in the night and we barely noticed.
1. It takes away the pain of starting. I have no barrier to writing text but there is a barrier to writing the first line of code, to a large extend coming form just remembering the context, where to import what from, setting up boilerplate etc.
2. While it works I can use my brain capacity to think about what I'm doing.
3. I can now do multiple things in parallel.
4. It makes it so much easier to "go the extra mile" (I don't add "TODOs" anymore in the code I just spin up a new Claude for it)
5. I can do much more analysis, (like spinnig up detailed plotting / analysis scripts)
6. It fixes most simple linting/typing/simple test bugs for me automatically.
Overall I feel like this kind of coding allows me to focus about the essence: What should I be doing? Is the output correct? What can we do to make it better?
AI, but refactor
1. Immediately change to sonnet (the cli defaults to opus for max users). I tested coding with opus extensively and it never matches the quality of sonnet.
2. Compacting often ends progress - it's difficult to get back to the same quality of code after compacting.
3. First prompt is very important and sets the vibe. If your instance of Claude seems hesitant, doubtful, sometimes even rude, it's always better to end the session and start again.
4. There are phrases that make it more effective. Try, "I'm so sorry if this is a bad suggestion, but I want to implement x and y." For whatever reason it makes Claude more eager to help.
5. Monolithic with docker orchestration: I essentially 10x'd when I started letting Claude itself manage docker containers, check their logs for errors, rm them, rebuild them, etc. Now I can get an entirely new service online in a docker container, from zero to operational, in one Claude prompt.
6. start in plan mode and iterate on the plan until you're happy
7. use slash commands, they are mini prompts you can keep refining over time, including providing starting context and reminding it that it can use tools like gh to interact with Github
not sure I agree on 1.
2. compact when you are at a good stop, not when you are forced to because you are at 0%
I turn off compacting to be manual, makes it easy to find a stopping point and write all context out to an md file before compacting.
First prompt isn't very important to me.
I haven't found i need special phrases. What matters is how context heavy I can make my subagents.
It once did a container exec that piped the target file into the projects cli command runner, which did nothing, but gives you an example of the string of wacky ways it will insist on running code instead of just reading it.
It can, in fact, control your entire computer. If there's a CLI tool, Claude can run it. If there's not a CLI tool... ask Claude anyway, you might be surprised.
E.g. I've used Claude to crop and resize images, rip MP3s from YouTube videos, trim silence from audio files, the list goes on. It saves me incredible amounts of time.
I don't remember life before it. Never going back.
Honestly, that sounds like malware.
We have Linux instances running an IDE running in cloud vms that we can access through the browser at https://brilliant.mplode.dev. Personally I think this is closer to the ideal UX for operating an agent (our environment doesn't install agents by default yet, but you should be able to just install them manually). You don't have to do anything to set up terminal access or ssh except sign in and wait for your initial instance to start, and once you have any instance provisioned it automatically pauses and resumes based on whether your browser has it open. It's literally Claude + A personal Linux instance + an IDE that you can just open from a link
Pretty soon I should be able run as many of these at a time as I can afford, and control all of their permissions/filesystems/whatever with JWTs and containers. If it gets messed up or needs my attention I open it with the IDE as my UI and can just dive in and fix it. I don't need a regular Linux desktop environment or UI or anything. Just render things in panes of the IDE or launch a container serving a webapp doing what I want and open it instead of the IDE. Haven't ever felt this excited about tech progress
https://github.com/pchalasani/claude-code-tools
For example this lets CC spawn another CC instance and give it a task (way better than the built-in spawn-and-let-go black box), or interact with CLI scripts that expect user input, or use debuggers like Pdb for token-efficient debugging and code-understanding, etc.
Today I (not a programmer, although programming for 20+ years, but mostly statistics) started building with Claude Code via Pro. Burned through my credits in about 3 hours. Got to MVP (happy tear in my eye). Actually one of the best looks I've ever gotten from my son. A look like, wow, dad, that's more than I'd ever think you could manage.
Tips:
- Plan ahead! I've had Claude tell me that a request would fit better way back on the roadmap. My roadmap manages me.
- Force Claude to build a test suite and give debugging info everywhere (backend, frontend).
- Claude and me work together on a clear TODO. He needs guidance as well as I do. It forgot a very central feature of my MVP. Do not yet know why. Asked kindly and it was built.
Questions (not specifically to you kind HN-folks, although tips are welcome):
- Why did I burn through my credits in 3 hours?
- How can I force Claude to keep committed to my plans, my CLAUDE.md, etc.
- Is there a way to ask Claude to check the entire project for consistency? And/Or should I accept that vibing will leave crusts spread around?
You can just ask claude to review your code, write down standard, verify that code is produced according to standards and guidelines. And if it finds that project is not consistent, ask it to make a plan and execute on the plan.
Ask, ask, ask.
By loop I mean you tell it no don’t implement this service, look at this file instead and mimic that and instead it does what it did before.
The bad experience was asking it to produce a relatively non-trivial feature in an existing Python module.
I have a bunch of classes for writing PDF files. Each class corresponds to a page template in a document (TitlePage, StatisticsPage, etc). Under the hood these classes use functions like `draw_title(x, y, title)` or `draw_table(x, y, data)`. One of these tables needed to be split across multiple pages if the number of rows exceeded the page space. So I needed Claude Code to do some sort of recursive top-level driver that would add new pages to a document until it exhausted the input data.
I spent about an hour coaching Claude through the feature, and in the end it produced something that looked superficially correct, but didn't compile. After spending some time debugging, I moved on and wrote the thing by hand. This feature was not trivial even for me to implement, and it took about 2 days. It broke the existing pattern in the module. The module was designed with the idea that `one data container = one page`, so splitting data across multiple pages was a new pattern the rest of the module needed to be adapted to. I think that's why Claud did not do well.
+++
The obviously good experience with Claude was getting it to add new tests to a well-structured suite of integration tests. Adding tests to this module is a boring chore, because most of the effort goes into setting up the input data. The pattern in the test suite is something like this: IntegrationTestParent class that contains all the test logic, and a bunch of IntegrationTestA/B/C/D that do data set up, and then call the parent's test method.
Claude knocked this one out of the park. There was a clear pattern to follow, and it produced code that was perfect. It saved me 1 or 2 hours, but the cool part was that it was doing this in its own terminal window, while I worked on something else. This is a type of simple task I'd give to new engineers to expose them to existing patterns.
+++
The last experience was asking it to write a small CLI tool from scratch in a language I don't know. The tool worked like this: you point it at a directory, and it then checks that there are 5 or 6 files in that directory, and that the files are named a certain way, and are formatted a certain way. If the files are missing or not formatted correctly, throw an error.
The tool was for another team to use, so they could check these files, before they tried forwarding these files to me. So I needed an executable binary that I could throw up onto Dropbox or something, that the other team could just download and use. I primarily code in Python/JavaScript, and making a shareable tool like that with an interpreted language is a pain.
So I had Claude whip something up in Golang. It took about 2 hours, and the tool worked as advertised. Claude was very helpful.
On the one hand, this was a clear win for Claude. On the other hand, I didn't learn anything. I want to learn Go, and I can't say that I learned any Go from the experience. Next time I have to code a tool like that, I think I'll just write it from scratch myself, so I learn something.
+++
Eh. I've been using "AI" tools since they came out. I was the first at my company to get the pre-LLM Copilot autocomplete, and when ChatGPT became available I became a heavy user overnight. I have tried out Cursor (hate the VSCode nature of it), and I tried out the re-branded Copilot. Now I have tried Claude Code.
I am not an "AI" skeptic, but I still don't get the foaming hype. I feel like these tools at best make me 1.5X -- which is a lot, so I will always stay on top of new tooling -- but I don't feel like I am about to be replaced.