5 ms·

Could you explain your reasoning? You expect that these tools will create more work to get from point A to point B rather than less?

by _bohm 4y ago

BratishkaErik 4y ago
In short: because there will be "current junk pull requests" (see microchanges for readme) but increased x100, if you want to use AI at least write description by yourself, orelse there os no point in your pr as authors might make it themselves
- _bohm 4y ago
  I see. My impression based on this press release is that GitHub is planning on marketing this more to teams using their paid plan though. It seems like this would be a non-issue for organizations using private repositories?
  - BratishkaErik 4y ago
    > As we continue to design, test, and build features that fall into the GitHub Copilot X vision, we are also taking the time to determine the best way to provide them to our customers, which may include changes to Copilot for Business and Copilot for Individuals. so we'll see :)
marginalia_nu 4y ago
It wouldn't be unreasonable to expect just that. Overall, producing code quicker is probably not something we need. It's plenty quick to type code. What's slow is finding good designs. I think more often than not, we jump to the coding part too early and build things too soon. This creates problems that are hard to fix after the fact. The easier it is to produce code, the more code will be produced. The more code is produced, the more complex and short-sighted the architecture will be as a result. This is much older than AI. You can take a one-person task that takes two weeks to perform, assign it to a five person team, and they'll solve it by producing 25 times the code. We create abstractions to cope with the noise of a large code base, but in doing so, we also create a noisier and more complex code base that needs more abstractions.
- wnkrshm 4y ago
  Managing complexity was once the job description
- _bohm 4y ago
  Yeah I think there's a lot of sense in that. I think it's likely that the ability to use these tools in a disciplined fashion will grow to be a significant differentiator between more effective and less effective programmers. The former taking a considered approach to design and then using the tools where they're a real force multiplier e.g., writing unit tests, and the latter prompting them to spit out large swaths of code they would have previously written by hand: "write an endpoint that does X".

Could you explain your reasoning? You expect that these tools will create more work to get from point A to point B rather than less?

by _bohm 4y ago

Could you explain your reasoning? You expect that these tools will create more work to get from point A to point B rather than less?

BratishkaErik 4y ago

In short: because there will be "current junk pull requests" (see microchanges for readme) but increased x100, if you want to use AI at least write description by yourself, orelse there os no point in your pr as authors might make it themselves

_bohm 4y ago
I see. My impression based on this press release is that GitHub is planning on marketing this more to teams using their paid plan though. It seems like this would be a non-issue for organizations using private repositories?
- BratishkaErik 4y ago
  > As we continue to design, test, and build features that fall into the GitHub Copilot X vision, we are also taking the time to determine the best way to provide them to our customers, which may include changes to Copilot for Business and Copilot for Individuals. so we'll see :)

marginalia_nu 4y ago

It wouldn't be unreasonable to expect just that. Overall, producing code quicker is probably not something we need. It's plenty quick to type code. What's slow is finding good designs. I think more often than not, we jump to the coding part too early and build things too soon. This creates problems that are hard to fix after the fact. The easier it is to produce code, the more code will be produced. The more code is produced, the more complex and short-sighted the architecture will be as a result. This is much older than AI. You can take a one-person task that takes two weeks to perform, assign it to a five person team, and they'll solve it by producing 25 times the code. We create abstractions to cope with the noise of a large code base, but in doing so, we also create a noisier and more complex code base that needs more abstractions.

wnkrshm 4y ago
Managing complexity was once the job description
_bohm 4y ago
Yeah I think there's a lot of sense in that. I think it's likely that the ability to use these tools in a disciplined fashion will grow to be a significant differentiator between more effective and less effective programmers. The former taking a considered approach to design and then using the tools where they're a real force multiplier e.g., writing unit tests, and the latter prompting them to spit out large swaths of code they would have previously written by hand: "write an endpoint that does X".