Comment by jonator | Hacker News Reader

Comment by jonator | Hacker News Reader

For me the fun part of coding is having visions of products or systems I'd like to exist, and writing code only as a means to an end.

Claude Code (AI coding agents/assistants) are perhaps the best thing to happen to my programming career. Up until this point, the constraint going from vision to reality has always been the tedious process of typing out code and unit tests or spending time tweaking the structure/algorithm of some unimportant subset of the system. At a high level, it's the mental labor of making thousands of small (but necessary) decisions.

Now, I work alongside Claude to fast track the manifestation of my vision. It completely automates away the small exhaustive decision making (what should I name this variable, where should I put this function, I can refactor this function in a better way, etc). Further, sometimes it comes up with ideas that are even better than what I had in my head initially, resulting in a higher quality output than I could have achieved on my own. It has an amazing breadth of knowledge about programming, it is always available, and it never gives up.

With AI in general, I have questions around the social implications of such a system. But, without a doubt, it's delivering extreme value to the world of software, and will only continue the acceleration of demand for new software.

The cost of software will also go down, even though net more opportunities will be uncovered. I'm excited to see software revolutionize the under represented fields, such as schools, trades, government, finance, etc. We don't need another delivery app, despite how lucrative they can be.

I see AI-accelerated codegen as doing all of the boring shit I hated:

do while error == true;

Write code

Run code

Read error

Attempt to fix error

Run code

Read error

Search Google for error

Attempt to fix error

Run code

Read error

done

---

Claude does all of this for me now, allowing me to concentrate on the end goal, not the minutiae. It hasn't at all changed my workflow; it just does all of the horribly mundane parts of it for me.

I like it and I recommend it to those who are willing to admit that their jobs aren't all sunshine and roses until the product is shipped and we can sit back and get to work on the next nightmare.

If you enjoy being a custodian no one is going to chastise you for that. As you have stated there are many nightmares to clean up and all teams need a person who wants to do the clean up.

This will keep you out of the bleeding edge feature/product space because you lack a honed skill in actually developing the app. Your skill is now to talk to an LLM and fix nightmare code, not work on new stuff that needs expertise.

Just food for thought.

I think writing code was never slow. Or atleast never the slowest part of the overall process.

Vibe coding might be fast, but thats only if you wish to pretend that coders deploy to production directly within minutes of writing code without product discussions, automated builds, CI/CD, code review, production testing, UAT, regression testing, security testing etc.

In reality when you factor in all these things, which are absolutely necessary if you don't want you product to break every new release and lose users permanently. You have to do the same drills as you always did.

To that end, unless you are building something very large, coding velocity is largely irrelevant.

I would also argue that the OPs comment describes “hacking” not “writing code”.

They could escape that loop by employing software development skillsets, for example TDD or perhaps using the debugger instead of pounding away at a compiler.

Usually when people pound at a compiler it’s because they don’t know what they’re doing or how software even works.

And by handing over all the small decisions and things like writing unit tests, you are opting in to mediocre code quality (or worse) and you no longer get the full experience of using your code, for example when writing unit tests yourself. Or when in other cases where you call your own procedures from your own code. When writing a test becomes difficult it is often (not always) an indication of bad code quality. It will also lead to you being less familiar with the code in general.

It may be, that all of those are OK in your scenario or use case.

For me the problem with the vision is that stuff I’d like to exist is so far above the capabilities of AI (rather complex games) that I don’t even want to try it. And for stuff that I build and use they are pointless because they don’t accelerate me much.

I found it great to write bash scripts, automation, ffmpeg command lines, OCR, refactoring… it’s a great autocomplete.

Working in a large team I realized that even relying too much of other people’s work is making me understand the technology less and I need to catch up.

Even if you're working on a large complex system like that, I believe coding agents are still useful at at least taking highly specific prompts/instructions you write and doing the writing for you. Then doing other tedious tangential work like generating unit tests over a pure function, adding comments, generating documentation, etc that all increase the quality of the codebase without requiring toil on your part.

With especially novel or complex projects, you'd probably not expect to use the agent to do much of the scaffolding or architecting, and more of the tedium.

It's like the Blank Page Problem for writers. It's really hard to start.

But if you have a shitty page of text, you can edit it to make it better.

With LLM tools I can get from idea to (shitty) proof-of-concept solution really fast. Then I can start dogfooding it and improve and rewrite.

But sometimes the shitty solution is enough for my purposes. It works and doesn't actively break shit. My problem was solved and I don't need to optimise the silly TUI yt-dlp wrapper it just made me.

> the fun part of coding is having visions of products or systems I'd like to exist, and writing code only as a means to an end.

Perhaps you mean "the fun part of building computer systems", because it sounds like you don't enjoy writing code.

It’s still cans of snakes all the way down though when it comes debugging time.

> and it never gives up.

Not to impede your overall point, but have you not encountered a situation where Claude gives up? I definitely have, it'll say something like "Given X, Y and Z, your options are [a bunch of things that do not literally but might as well amount to 'go outside and touch grass']."

I agree and do experience that. Perhaps to clarify, I mean that it (unlike humans), is always down to code alongside you. It will never complain, get sick, have a life event. etc.

It can (and does) "get sick" in the sense that anthropic services go down, anthropic rate limits, gets overloaded, etc.

I've been experimenting lately with just interfacing with Claude Code through the GitHub action and issues.

I sit on the beach and talk to it through the GitHub iOS app. I set the timeout to 4 hours and let it just work. It comes back to me later with something and I take a look. By the time I get home, I might tweak a few things here or there manually (particularly if it's about aesthetics), and merge.

Reply on news.ycombinator.com