6 ms·

Probably a lot of people here disagree with this feeling. But my take is that if setting up all the AI infrastructure and onboarding to my code is going to take

Probably a lot of people here disagree with this feeling. But my take is that if setting up all the AI infrastructure and onboarding to my code is going to take this amount of effort, then I might as well code the damn thing myself which is what I'm getting paid to (and enjoy doing anyway)

vanviegen 11mo ago
Perhaps. But keep in mind that the setup work is typically mostly delegated to LLMs as well.
fragmede 11mo ago
Whether it's setting up AI infrastructure or configuring Emacs/vim/VSCode, the important distinction to make is if the cost has to be paid continually, or if it's a one time/intermittent cost. If I had to configure my shell/git aliases every time I booted my computer, I wouldn't use them, but seeing as how they're saved in config files, they're pretty heavily customized by this point. Don't use AI if you don't want to, but "it takes too much effort to set up" is an excuse printf debuggers use to avoid setting up a debugger. Which is a whole other debate though.
- bird0861 11mo ago
  I fully agree with this POV but for one detail; there is a problem with sunsetting frontier models. As we begin to adopt these tools and build workflows with them, they become pieces of our toolkit. We depend on them. We take them for granted even. And then the model either changes (new checkpoints, maybe alignment gets fiddled with) and all of the sudden prompts no longer yield the same results we expected from them after working on them for quite some time. I think the term for this is "prompt instability". I felt this with Gemini 3 (and some people had less pronounced but similar experience with Sonnet releases after 3.7) which for certain tasks that 2.5Pro excelled at..it's just unusable now. I was already a local model advocate before this but now I'm a local model zealot. I've stopped using Gemini 3 over this. Last night I used Qwen3 VL on my 4090 and although it was not perfect (sycophancy, overuse of certain cliches...nothing I can't get rid of later with some custom promptsets and a few hours in Heretic) it did a decent enough job of helping me work through my blindspots in the UI/UX for a project that I got what I needed. If we have to perform tuning on our prompts ("skills", agents.md/claude.md, all of the stuff a coding assistant packs context with) every model release then I see new model releases becoming a liability more than a boon.
kissgyorgy 11mo ago
I strongly disagree with the author not using /init. It takes a minute to run and Claude provides surprisingly good results.
- alwillis 11mo ago
  /init has evolved since the early day; it's more concise than it used to be.
- 0xblacklight 11mo ago
  If you find it works for you, then that’s great! This post is mostly from our learnings from getting it to solve hard problems in complex brownfield codebases where auto generation is almost never sufficient.
nvarsj 11mo ago
It really doesn't take that much effort. Like any tool, people can over-optimise on the setup rather than just use it.
nichochar 11mo ago
The effort described in the article is maybe a couple hours of work. I understand the "enjoy doing anyway" part and it resonates, but not using AI is simply less productive.
- TheRoque 11mo ago
  > but not using AI is simply less productive Some studies shows the opposite for experienced devs. And it also shows that developers are delusional about said productivity gains: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ https://metr.org/blog/2025-07-10-early-2025-ai-experienced-o... If you have a counter-study (for experienced devs, not juniors), I'd be curious to see. My experience also has been that using AI as part of your main way to produce code, is not faster when you factor in everything.
  - ares623 11mo ago
    Curious why there hasn't been a rebuttal study to that one yet (or if there is I haven't seen it come up). There must be near infinite funding available to debunk that study right?
  - bird0861 11mo ago
    That study is garbo and I suspect you didn't even read the abstract. Am I right?
    - gravypod 11mo ago
      I've heard this mentioned a few times. Here is a summarized version of the abstract: > ... We conduct a randomized controlled trial (RCT) > ... AI tools ... affect the productivity of experienced > open-source developers. 16 developers with moderate AI > experience complete 246 tasks in mature projects on which they > have an average of 5 years of prior experience. Each task is > randomly assigned to allow or disallow usage of early-2025 AI > tools. ... developers primarily use Cursor Pro ... and > Claude 3.5/3.7 Sonnet. Before starting tasks, developers forecast that allowing > AI will reduce completion time by 24%. After completing the > study, developers estimate that allowing AI reduced completion time by 20%. > Surprisingly, we find that allowing AI actually increases > completion time by 19%—AI tooling slowed developers down. This > slowdown also contradicts predictions from experts in economics > (39% shorter) and ML (38% shorter). To understand this result, > we collect and evaluate evidence for 21 properties of our setting > that a priori could contribute to the observed slowdown effect—for > example, the size and quality standards of projects, or prior > developer experience with AI tooling. Although the influence of > experimental artifacts cannot be entirely ruled out, the robustness > of the slowdown effect across our analyses suggests it is unlikely > to primarily be a function of our experimental design. So what we can gather: 1. 16 people were randomly given tasks to do 2. They knew the codebase they worked on pretty well 3. They said AI would help them work 24% faster (before starting tasks) 4. They said AI made them ~20% faster (after completion of tasks) 5. ML Experts claim that they think programmers will be ~38% faster 6. Economists say ~39% faster. 7. We measured that people were actually 19% slower This seems to be done on Cursor, with big models, on codebases people know. There are definitely problems with industry-wide statements like this but I feel like the biggest area AI tools help me is if I'm working on something I know nothing about. For example: I am really bad at web development so CSS / HTML is easier to edit through prompts. I don't have trouble believing that I would be slower trying to make an edit to code that I already know how to make. Maybe they would see the speedups by allowing the engineer to select when to use the AI assistance and when not to.
Havoc 11mo ago
A lot of the style stuff you can write once and reuse. I started splitting mine into overall and project specific files for this reason Universal has stuff I always want (use uv instead of pip etc) while the other describes what tech choice for this project

vanviegen 11mo ago

Perhaps. But keep in mind that the setup work is typically mostly delegated to LLMs as well.

fragmede 11mo ago

Whether it's setting up AI infrastructure or configuring Emacs/vim/VSCode, the important distinction to make is if the cost has to be paid continually, or if it's a one time/intermittent cost. If I had to configure my shell/git aliases every time I booted my computer, I wouldn't use them, but seeing as how they're saved in config files, they're pretty heavily customized by this point. Don't use AI if you don't want to, but "it takes too much effort to set up" is an excuse printf debuggers use to avoid setting up a debugger. Which is a whole other debate though.

bird0861 11mo ago
I fully agree with this POV but for one detail; there is a problem with sunsetting frontier models. As we begin to adopt these tools and build workflows with them, they become pieces of our toolkit. We depend on them. We take them for granted even. And then the model either changes (new checkpoints, maybe alignment gets fiddled with) and all of the sudden prompts no longer yield the same results we expected from them after working on them for quite some time. I think the term for this is "prompt instability". I felt this with Gemini 3 (and some people had less pronounced but similar experience with Sonnet releases after 3.7) which for certain tasks that 2.5Pro excelled at..it's just unusable now. I was already a local model advocate before this but now I'm a local model zealot. I've stopped using Gemini 3 over this. Last night I used Qwen3 VL on my 4090 and although it was not perfect (sycophancy, overuse of certain cliches...nothing I can't get rid of later with some custom promptsets and a few hours in Heretic) it did a decent enough job of helping me work through my blindspots in the UI/UX for a project that I got what I needed. If we have to perform tuning on our prompts ("skills", agents.md/claude.md, all of the stuff a coding assistant packs context with) every model release then I see new model releases becoming a liability more than a boon.

kissgyorgy 11mo ago

I strongly disagree with the author not using /init. It takes a minute to run and Claude provides surprisingly good results.

alwillis 11mo ago
/init has evolved since the early day; it's more concise than it used to be.
0xblacklight 11mo ago
If you find it works for you, then that’s great! This post is mostly from our learnings from getting it to solve hard problems in complex brownfield codebases where auto generation is almost never sufficient.

nvarsj 11mo ago

It really doesn't take that much effort. Like any tool, people can over-optimise on the setup rather than just use it.

nichochar 11mo ago

The effort described in the article is maybe a couple hours of work. I understand the "enjoy doing anyway" part and it resonates, but not using AI is simply less productive.

TheRoque 11mo ago
> but not using AI is simply less productive Some studies shows the opposite for experienced devs. And it also shows that developers are delusional about said productivity gains: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ https://metr.org/blog/2025-07-10-early-2025-ai-experienced-o... If you have a counter-study (for experienced devs, not juniors), I'd be curious to see. My experience also has been that using AI as part of your main way to produce code, is not faster when you factor in everything.
- ares623 11mo ago
  Curious why there hasn't been a rebuttal study to that one yet (or if there is I haven't seen it come up). There must be near infinite funding available to debunk that study right?
- bird0861 11mo ago
  That study is garbo and I suspect you didn't even read the abstract. Am I right?
  - gravypod 11mo ago
    I've heard this mentioned a few times. Here is a summarized version of the abstract: > ... We conduct a randomized controlled trial (RCT) > ... AI tools ... affect the productivity of experienced > open-source developers. 16 developers with moderate AI > experience complete 246 tasks in mature projects on which they > have an average of 5 years of prior experience. Each task is > randomly assigned to allow or disallow usage of early-2025 AI > tools. ... developers primarily use Cursor Pro ... and > Claude 3.5/3.7 Sonnet. Before starting tasks, developers forecast that allowing > AI will reduce completion time by 24%. After completing the > study, developers estimate that allowing AI reduced completion time by 20%. > Surprisingly, we find that allowing AI actually increases > completion time by 19%—AI tooling slowed developers down. This > slowdown also contradicts predictions from experts in economics > (39% shorter) and ML (38% shorter). To understand this result, > we collect and evaluate evidence for 21 properties of our setting > that a priori could contribute to the observed slowdown effect—for > example, the size and quality standards of projects, or prior > developer experience with AI tooling. Although the influence of > experimental artifacts cannot be entirely ruled out, the robustness > of the slowdown effect across our analyses suggests it is unlikely > to primarily be a function of our experimental design. So what we can gather: 1. 16 people were randomly given tasks to do 2. They knew the codebase they worked on pretty well 3. They said AI would help them work 24% faster (before starting tasks) 4. They said AI made them ~20% faster (after completion of tasks) 5. ML Experts claim that they think programmers will be ~38% faster 6. Economists say ~39% faster. 7. We measured that people were actually 19% slower This seems to be done on Cursor, with big models, on codebases people know. There are definitely problems with industry-wide statements like this but I feel like the biggest area AI tools help me is if I'm working on something I know nothing about. For example: I am really bad at web development so CSS / HTML is easier to edit through prompts. I don't have trouble believing that I would be slower trying to make an edit to code that I already know how to make. Maybe they would see the speedups by allowing the engineer to select when to use the AI assistance and when not to.

Havoc 11mo ago

A lot of the style stuff you can write once and reuse. I started splitting mine into overall and project specific files for this reason Universal has stuff I always want (use uv instead of pip etc) while the other describes what tech choice for this project