zlacker

> Still saves a lot of time vs typing everything from scratch

No it doesn't. Typing speed is never the bottleneck for an expert.

As an offline database of Google-tier knowledge, LLM's are useful. Though current LLM tech is half-baked, we need:

a) Cheap commodity hardware for running your own models locally. (And by "locally" I mean separate dedicated devices, not something that fights over your desktop's or laptop's resources.)

b) Standard bulletproof ways to fine-tune models on your own data. (Inference is already there mostly with things like llama.cpp, finetuning isn't.)

>>otabde+(OP)
I realize I procrastinate less when using LLM to write code which I know I could write.

>>otabde+(OP)
> No it doesn't. Typing speed is never the bottleneck for an expert

How could that possibly be true!? Seems like it'd be the same as suggesting being constrained to analog writing utensils wouldn't bottleneck the process of publishing a book or research paper. At the very least such a statement implies that people with ADHD can't be experts.

>>brails+Pb
> How could that possibly be true!?

(I'll assume you're not joking, because your post is ridiculous enough to look like sarcasm.)

The answer is because programmers read code 10 times more (and think about code 100 times more) than they write it.

>>brails+Pb
Completely agree with you. I was working on the front-end of an application and I prompted Claude the following: "The endpoint /foo/bar is returning the json below ##json goes here##, show this as cards inside the component FooBaz following the existing design system".

In less than 5 minutes Claude created code that: - encapsulated the api call - modeled the api response using Typescript - created a re-usable and responsive ui component for the card (including a load state) - included it in the right part of the page

Even if I typed at 200wpm I couldn't produce that much code from such a simple prompt.

I also had similar experiences/gains refactoring back-end code.

This being said, there are cases in which writing the code yourself is faster than writing a detailed enough prompt, BUT those cases are becoming exception with new LLM iteration. I noticed that after the jump from Claude 3.7 to Claude 4 my prompts can be way less technical.

>>otabde+sk
Yeah, but how fast can you write compared to how fast you think?

How many times have you read a story card and by the time you finished reading it you thought "It's an easy task, should take me 1 hour of work to write the code and tests"?

In my experience, in most of those cases the AI can do the same amount of code writing in under 10 minutes, leaving me the other 50 minutes to review the code, make/ask for any necessary adjustments, and move on to another task.

>>thisis+xl
I don't know anyone who can think faster than they can type (on average), they would have to have an IQ over 150 or something. For mere mortals like myself, reasoning through edge cases and failure conditions and error handling and state invariants takes time. Time that I spend looking at a blinking cursor while the gears spin, or reading code. I've never finished a day where I thought to myself "gosh darn, if only I could type faster this would be done already".

>>brails+Pb
It seems fair to say that it is ~never the overall bottleneck? Maybe once you figure out what you want, typing speed briefly becomes the bottleneck, but does any expert finish a day thinking "If only I could type twice as fast, I'd have gotten twice as much work done?" That said, I don't think "faster typing" is the only benefit that AI assistance provides.

>>boruto+64
I've noticed this too.

I remember hearing somewhere that humans have a limited capacity in terms of number of decisions made in a day, and it seems to fit here: If I'm writing the code myself, I have to make several decisions on every line of code, and that's mentally tiring, so I tend to stop and procrastinate frequently.

If an LLM is handling a lot of the details, then I'm just making higher-level decisions, allowing me to make more progress.

Of course this is totally speculation and theories like this tend to be wrong, but it is at least consistent with how I feel.

>>thisis+Kk
The thing is... does your code end there? Would you put that code in production without a deep analysis of what Claude did?

>>dns_sn+5n
You could be fast if you were coding only the happy path, like a lot of juniors do. Instead of thinking about trivial things like malformed input, library semantics, framework gotchas and what not.

>>otabde+(OP)
Maybe you type faster than me then :) I for sure type slower than Claude code. :)

>>kenton+aw
I have a feeling that it's something that might help today but also something you might pay for later. When you have to maintain or bug fix that same code down the line the fact that you were the one making all those higher-level decisions and thinking through the details gives you an advantage. Just having everything structured and named in ways that make the most sense to you seems like it'd be helpful the next time you have to deal with the code.

While it's often a luxury, I'd much rather work on code I wrote than code somebody else wrote.

>>oblio+uM
(GP) I wouldn't, but it would get me close enough that I can do the work that's more intellectually stimulating. Sometimes you need the people to do the concrete for a driveway, and sometimes you need to be signing off on the way the concrete was done, perhaps making some tweaks during the early stages.

>>otabde+sk
I wasn't joking, it's a bottleneck sometimes, that's it. It's a bottleneck like comfort and any good tool is a bottleneck, like a slow computer is a bottleneck. It's silly to suggest that your ability to rapidly use a fundamental tool is never a bottleneck, no matter what other bits need to come into play during the course of your day.

My ability to review and understand intent behind code isn't a primarily bottleneck to me actually efficiently reviewing code when it's requested of me, the primary bottleneck is being notified at the right time that I have a waiting request to review code.

If compilers were never a bottleneck, why would we ever try to make them faster? If build tools were never a bottleneck, why would we ever optimize those? These are all just some of the things that can stand between the identification of a problem and producing a solution for it.

>>oblio+uM
I’m not who you replied to but I keep functions small and testable paired with unit tests with a healthy mix of happy/sad path.

Afterwards I make sure the LLM passes all the tests before I spend my time to review the code.

I find this process keeps the iterations count low for review -> prompt -> review.

I personally love writing code with an LLM. I’m a sloppy typist but love programming. I find it’s a great burnout prevention.

For context: node.js development/React (a very LLM friendly stack.)

>>boruto+64
Amazing, because I realized I procrastinate MORE when using LLM to write code which I know I could write. And not only that, I feel I'm losing the ability to do the coding myself and solve the problems myself when delegating this to the AI. Which is why no one should base their own decisions for life, like using or not using an LLM, on some random story from the internet.

>>brails+Pb
Now you are just being silly with your comparisons. There is no analogy between those things: * the difference between handwritting a book and typing is the extreme pain you would feel in your hands versus being able to write more in the same time without it * the difference between typing and using your voice could be of a similar magnitude for someone with problems in their hands * the difference between any of those writing methods and using an AI to do it for you, is that you are abstracting YOURSELF from the equation, not the method of writing. It's not analogous, not even from a mountain of distance far. You are not less "bottlenecked" because you don't need to write the thing yourself, you are just not producing it at all, it's more analogous to you guiding the hands of another person with vague instructions, using of their own expressivity to make your book for you, then claiming it was you who wrote it. It's not a bottleneck question, it was never a bottleneck question, and this is the case because code IS the writing, it IS the problem solving area where you need to put your mind to work, not writing a prompt, but coding in a specific and well defined formal syntax.