Maybe I'm weird but I don't actually enjoy the act of _writing_ code. I enjoy problem solving and creating something. I enjoy decomposing systems and putting them back together in a better state, but actually manually typing out code isn't something I enjoy.

When I use an LLM to code I feel like I can go from idea to something I can work with in much less time than I would have normally.

Our codebase is more type-safe, better documented, and it's much easier to refactor messy code into the intended architecture.

Maybe I just have lower expectations of what these things can do but I don't expect it to problem solve. I expect it to be decent at gathering relevant context for me, at taking existing patterns and re-applying them to a different situation, and at letting me talk shit to it while I figure out what actually needs to be done.

I especially expect it to allow me to be lazy and not have to manually type out all of that code across different files when it can just generate them it in a few seconds and I can review each change as it happens.

▲

legacynl 2 days ago | parent | next [-]

If natural language was an efficient way to write software we would have done it already. Fact is that it's faster to write class X { etc }; Than it is to write "create a class named X with behavior etc". If you want to think and solve problems yourself, it doesn't make sense to then increase your workload by putting your thoughts in natural language, which will be more verbose.

I therefore think it makes the most sense to just feed it requirements and issues, and telling it to provide a solution.

Also unless you're starting a new project or big feature with a lot of boiler plate, in my experience it's almost never necessary to make a lot of files with a lot of text in it at once.

▲

kiitos 4 days ago | parent | prev | next [-]

the time spent literally typing code into an editor is never the bottleneck in any competently-run project

if the act of writing code is something you consider a burden rather than a joy then my friend you are in the wrong profession

▲

jmcodes 4 days ago | parent | next [-]

Been doing it for ten years still love the profession as much if not more than when I started, but the joy of software development for me was always in seeing my idea come to life, in exploring all the clever ways people had solved so many problems, in trying to become as good at the craft as they were, and in sharing those solutions and ideas with like-minded peers.

I care deeply about the code quality that goes into the projects I work on because I end up having to maintain it, review it, or fix it when it goes south, and honestly it just feels wrong to me to see bad code.

But literally typing out the characters that make up the code? I could care less. I've done that already. I can do it in my sleep, there's no challenge.

At this stage in my career I'm looking for ways to take the experience I have and upskill my teams using it.

I'd be crazy not to try and leverage LLMs as much as possible. That includes spending the time to write good CLAUDE.md files, set up custom agents that work with our codebase and patterns, it also includes taking the time to explain the why behind those choices to the team so they understand them, calling out bad PRs that "work" but are AI slop and teaching them how to get better results out of these things.

Idk man the profession is pretty big and creating software is still just as fun as when I was doing it character by character in notepad. I just don't care to type more than I need to when I can focus on problem solving and building.

▲

its-kostya 3 days ago | parent [-]

While reading your comment it occured to me that people code at different abstraction levels. I do systems programming in golang and rust and I - like you - enjoy seeing my ideas come to life not so much the typing. The final result (how performant, how correct, how elegant and not complex) is in my control instead of an agent's; I enjoy having the creativity in the implementation. I can imagine other flavors of the profession working at higher abstraction layers and using more frameworks, where their result is dependant on how the framework executes. At that point, you might just want to connect all the frameworks/systems and get the feature out the door. And it is definitely a spectrum of languages, tools, frameworks that are more or less involved.

The creativity in implementing (e.g an indexed array that, when it grows to large, gets reformated to a less performance hashmap) is what I imagine being lost and bring people satisfaction. Pulling that off in a clean and not in a complex way... well there is a certain reward in that. I don't have any long term proof but I also hypothesize it helps with maintainability.

But I also see your point, sometimes I need a tool that does a function and I don't care to write it and giving the agent requirements and having it implemented is enough. But typically these tools are used and discarded.

	▲	jmcodes 3 days ago \| parent [-]
		Agreed 100% and I enjoy that part too, I just don't really see how that is being taken away. The way I see it these tools allow me to use my actual brainpower mostly on those problems. Because all the rote work can now be workably augmented away, I can choose which problems to actually focus on "by hand" as it were. I'd never give those problems to an LLM to solve. I might however ask it to search the web for papers or articles or what have you that have solved similar problems and go from there. If someone is giving that up then I'd question why they're doing that.. No one is forcing them to. It's the problem solving itself that is fun, the "layer" that it's in doesn't really make a difference to me.

▲

theshrike79 3 days ago | parent | prev [-]

But it's not exactly rewarding to add one more CRUD endpoint. It's a shit-ton of typing in multiple layers.

An LLM can do it in two minutes while I fetch coffee, then I can proceed to add the complex bits (if there are any)

	▲	kiitos a day ago \| parent [-]
		> But it's not exactly rewarding to add one more CRUD endpoint. It's a shit-ton of typing in multiple layers. i don't disagree with you but if "adding one more CRUD endpoint" and similar rote tasks represent any significant amount of your engineering hours, especially in the context of business impact, then something is fundamentally broken in your team, engineering org, or company overall time spent typing code into an editor is usually, hopefully!, approximately statistically 0% of overall engineering time

▲

skydhash 5 days ago | parent | prev [-]

Code is the ultimate fact checker, where what you write is what gets done. Specs are well written wishes.

	▲	jmcodes 5 days ago \| parent [-]
		Yes, hence tests, linters, and actually verifying the changes it is making. You can't trust anything the LLM writes. It will hallucinate or misunderstand something at some point if your task gets long. But that's not the point, I'm not asking it to solve things for me. I'm using it to get faster at building my own understanding of the problem, what needs to get done, and then just executing the rote steps I've already figured out. Sometimes I get lucky and the feature is well defined enough just from the context gathering step that the implementation is literally just be hitting the enter key as I read the edits it wants to make. Sometimes I have to interrupt it and guide it a bit more as it works. Sometimes I realize I misunderstood something as it's thinking about what it needs to do. One-shotting or asking the LLM to think for you is the worst way to use them.