3 ms·

> Finally, there is the delight of working in such a tractable medium. This is one important reason why many programmers aren’t very fond of AI coding. The rel

by layer8 1y ago

> Finally, there is the delight of working in such a tractable medium. This is one important reason why many programmers aren’t very fond of AI coding. The relationship between prompt and LLM output is not very tractable.

coldtea 1y ago
also, AI coding is not coding to begin with: the AI does the coding... you might get to chime in, but this already means you've squandered a part of the coding to the AI, and not just the boilerplate part
- specproc 1y ago
  I find it completely devoid of joy, the frustration without the satisfaction and growth.
closeparen 1y ago
I have to work in a very explicit, verbose language where we are expected to write mostly mock-driven unit tests to a 95% coverage standard. Although I would prefer to use a nicer language and adopt a more nuanced testing strategy, I find that for the situation I'm actually in, AI increases tractability by a lot.
- edem 1y ago
  Are you an enterprise Java dev by any chance?
  - closeparen 1y ago
    Java has exceptions and can mock at runtime using reflection. Go is much worse. If you have glue code that calls 5 methods in sequence, you need to set up build rules to generate 5 mocks for the corresponding interfaces. And then if you’re like me, re-sync the editor so it picks up the generated symbols. Then you need to write 1 + 2 + 3 + 4 + 5 mock expectations for the 5 test cases to reach each error return branch. Oh and the mock expectation arguments are immune to automated refactoring because they’re all interface{}. So if you want to change the arguments of a method that’s implicated in a lot of test cases, lol good luck. People get over this and even grow to appreciate it from the perspective of the production code, but from the unit testing side it’s been an unrelenting nightmare from the time I started using the language professionally ~10 years ago until we got Copilot. It’s total slop. Perfect for the slop generating machine.
    - edem 1y ago
      This is horrible, thanks.

by layer8 1y ago

coldtea 1y ago

also, AI coding is not coding to begin with: the AI does the coding... you might get to chime in, but this already means you've squandered a part of the coding to the AI, and not just the boilerplate part

specproc 1y ago
I find it completely devoid of joy, the frustration without the satisfaction and growth.

closeparen 1y ago

I have to work in a very explicit, verbose language where we are expected to write mostly mock-driven unit tests to a 95% coverage standard. Although I would prefer to use a nicer language and adopt a more nuanced testing strategy, I find that for the situation I'm actually in, AI increases tractability by a lot.

edem 1y ago
Are you an enterprise Java dev by any chance?
- closeparen 1y ago
  Java has exceptions and can mock at runtime using reflection. Go is much worse. If you have glue code that calls 5 methods in sequence, you need to set up build rules to generate 5 mocks for the corresponding interfaces. And then if you’re like me, re-sync the editor so it picks up the generated symbols. Then you need to write 1 + 2 + 3 + 4 + 5 mock expectations for the 5 test cases to reach each error return branch. Oh and the mock expectation arguments are immune to automated refactoring because they’re all interface{}. So if you want to change the arguments of a method that’s implicated in a lot of test cases, lol good luck. People get over this and even grow to appreciate it from the perspective of the production code, but from the unit testing side it’s been an unrelenting nightmare from the time I started using the language professionally ~10 years ago until we got Copilot. It’s total slop. Perfect for the slop generating machine.
  - edem 1y ago
    This is horrible, thanks.