Tell HN: I Lost Joy of Programming

I take a hybrid approach. I will describe a simplified problem to the LLM, have it generate a well commented and reasonable approach for the problem. I then use that as a cheat sheet for implementing my actual code. This still gives me hands on codi and more control, without needing to agonize over the details of each coding technique.

Not OP, but you nailed my feelings perfectly. I did not like managing for precisely this reason, and it never got better. The trenches are for me.

Re LLMs I love collaborative coding because I can sometimes pick up or teach new tricks. If I'm too tired to type the boilerplate I sometimes use an LLM. These are the only two redeeming values of LLM agents: they produce code or designs I can start from when I ask them too. I rarely do.

I hope OP can find a balance that works. It's sad to see the (claimed) state of the art be a soulless crank we have to turn.

I think you're on to something: It sounds like the developer needs to be more hands-on in making changes; as opposed to treating the AI like a subordinate with autonomy.

---

For example: About two years ago I worked with a contractor who was a lot more junior than our team needed. I'd give him instructions, and then the next day spend about 2-3 hours fixing his code. In total, I was spending half of my time handholding the contractor through their project.

The problem was that I had my own assignments; and the contractor was supposed to be able to do their job with minimal oversight. (IE, roughly 0.5-1.5 hours of my day.)

If the contractor was helping me with my assignment; IE, if the contractor was my assistant, I'd have loved the arrangement.

(In case you're wondering how it ended up for the contractor, we let him go and hired someone who worked out great.)

---

I suspect if the OP can figure out how to make the AI an assistant, instead of an employee with autonomy, then it will be a better arrangement. I personally haven't found an AI that does that for me, but I suspect I'm either using it incorrectly or using the wrong tools.

That is a hilarious and depressing perspective!

> I feel the opposite. I appreciate the ability to iterate and prototype in a way which lowers friction.

I feel the same way. Things I like: Thinking about architectures and algorithms. Things I don't like: Starting out with a blank slate, looking up the exact function names or parameters. I find it much easier to take something roughly implemented and improve upon it than to start from nothing and build it.

I think about what I want fairly specifically. I discuss it with the LLM. It implements something. Half of the time it's what I expect, I can move on. Sometimes it's done something I wasn't expecting in a better way, which is nice. Frequently it's done something I wasn't expecting in a worse way; I either tell it to fix it, or just fix it myself.

In my previous role, I did a huge amount of patch review, which I always found quite tedious. Even though this looks superficially similar, it doesn't have the same vibe at all. I think it's because the LLM will accept being told what to do in a way no self-respecting coder would. (One complaint I'd heard about another person's reviews was that the person whose code was reviewed felt like they were a marionette, just typing exactly what the reviewer told them to type.)

This way I can do the things I enjoy, while neither having to worry about some human being's feelings, nor having to do the low-level stuff that's a chore.

As the saying goes, mathematics is not a spectator sport. The same applies to programming. If you don't do the lower level work, you are a spectator that is rearranging other people's laundered code, or even their laundered architectures.

> This is a huge red flag that you have no idea what you're doing at the fundamental software architecture level imo. Or at least you have bad process (prior to LLMs).

Particularly in the present. If any of the current models can consistently make senior-level decisions I'd like to know which ones they are. They're probably going to cross that boundary soon, but they aren't there yet. They go haywire too often. Anyone who codes only using the current generation of LLM without reviewing the code is surely capping themselves in code quality in a way that will hurt maintainability.

in this world of LLM coding, we jumped to architect level

> it makes me wonder what I'm doing wrong

I'm in the same boat: I'm mostly doing C# in Visual Studio (classic) with co-pilot, and it very rarely gives useful code from prompts. Often times the auto-suggestions are hallucinations, and frequently they interfere with "normal" tab completion.

I'm wondering if I'm using the wrong tool, or if Visual Studio (classic) co-pilot is just far behind industry norms?

I think it depends on your niche and model. Gemini pro worked amazing for me in when doing (relatively simple) graph algorithms in python, but completely sucked when I switched to (relatively complicated) latex layouts.

I don’t think you’re doing anything wrong. Some shops just have very low quality bars where they can ship things that are to be frank, broken. I tend to use Sonnet 4 these days, and use it for tasks that aren’t too important or ones that require prototyping and iteration over perfection.

I find it’s really great for augmenting specific kinds of concentrated tasks. But just like you, I have to review everything it creates. Even Claude Opus 4 on MAX produces many bugs on a regular basis that I fix before merging in a change. I don’t mind it though, as I can choose to use it on the most annoying areas, and leave the ones I enjoy to work on myself.

[dead]

For me, vibe coding is becoming more of a niche. I still use it but not that often. I prefer the Codex style workflow in which you do spent a lot more time on specifying things, providing examples and reviewing PRs.

Essentially, vibe coding is synchronous as it is necessary to wait around for the LLM to respond. Codex is async and allows you to focus on other things while it is working. The primary issue with async workflows is you really don't want to have to iterate much. Therefore, investing more time upfront clearly defining the prompt / agents.md and prior examples becomes really important. Usually if it is > 90% correct I will just fix the rest myself. For hand coding, I use a fairly basic vim setup with no LLM plugins. I do not like LLMs jumping in and trying to auto complete stuff.