4 ms·

All true, but the argument for AI is that it makes you far more productive as an individual, which if true should be an easy sell. In fact, some developers are

All true, but the argument for AI is that it makes you far more productive as an individual, which if true should be an easy sell. In fact, some developers are quite committed to it, with a fervor I've not seen since the "I'm never going back to the office" fervor a few years ago. Version control is more of a "short term pain for long term gain" kind of concept; it is not surprising some people were hard to convince. But "AI" promises increased productivity as an individual, in the here and now. It should not be a hard sell if people found it to work as advertised.

krinchan 1y ago
As someone who started out a GenAI skeptic, I’ve found the truth is in the middle. I write a TON of one off scripts now at work. For instance, if I fight with a Splunk query for more than five minutes, I’ll just export the entire time frame in question and have GHCP (work mandates we use only GHCP) spit out a Python script that gets me what I want. I use it with our internal MCP tools to review pull requests. It surfaces questions I didn’t think to ask about half the time. I don’t know that it makes me more productive, but it definitely makes me more attentive. It works great for brainstorming design ideas. The code generation isn’t entirely slop either. For the vast majority of corporate devs below Principal, it’s better than what they write and its basic CRUD code. So that’s where all the hyper productive magical claims come from. I spend most of my days lately bailing these folks out of a dead end fox hole GHCP led them into. Unfortunately, it’s very much a huge time sink in another way. I’ve seen a pretty linear growth in M365 Copilot surfacing 5 year old word documents to managers resulting in big emails of outdated GenAI slop that would be best summarized as “I have no clue what I’m talking about and I’m going to make a terrible technical decision that we already decided against.”
- clickety_clack 1y ago
  What is GHCP?
  - hydhyd 1y ago
    It appears to be GitHub Copilot
    - clickety_clack 1y ago
      Ah! I was trying to fit 4 words into the acronym, like “GitHub Hosting Cloud Platform” or something.
crazygringo 1y ago
> it makes you far more productive as an individual, which if true should be an easy sell Writing unit tests where needed makes you more productive in the long run. Writing in modern languages makes you more productive. Remember how people writing assembly thought compiled languages would rot your brain! But people just resist change and new ways of doing things. They don't care about actual productivity, they care about feeling productive with the tools they already know. It's a hard sell when an application moves a button! People don't like change. Change is always a hard sell to a lot of people, even when it benefits them.
- haskellshill 1y ago
  > Remember how people writing assembly thought compiled languages would rot your brain! Well, how'd you describe web apps of today if not precisely brainrot? > They don't care about actual productivity, they care about feeling productive Funny you'd say that, because that describes a large portion of "AI coders". Sure they pump out a lot of lines of code, and it might even work initially, but in the long run it's hardly more productive. > It's a hard sell when an application moves a button! Because usually that is just change for the sake of change. How many updates are there every day that add nothing at all? More than updates that actually add something useful, at least.
- jacobolus 1y ago
  To the contrary, people resist change for good reasons: changes to tools rob attention and focus from the work, often for completely arbitrary or decorative reasons. Sometimes changes remove or break important aspects of the tool and force someone to waste time developing a new workflow which is, on average, no better than the previous one. It is vanishingly rare that the software team making the changes in question did sufficiently rigorous testing to show that the new version is a net "benefit" for most users of the software; they don't have time for that. All too often, no significant group of users was even consulted about the changes, which were made for reasons like advancing someone's career ("shipped X feature changes") or looking different for the sake of marketing something merely re-arranged as new ("the old style was so 2018"). The teams making changes to software are, on average, moderately worse than the teams who originally developed the software, if only because they missed out on the early development experience, and often don't fully understand the context and reasons for the original design and don't reason from first principles when making updates, but copy the aspects they notice superficially while undermining the principles they were originally established on. Even when the changes are independently advantageous, it is common for changes to one part of a system to gratuitously break a variety of other parts that are dependent on it. Trying to manage and fix a complex web of inter-dependent software which is constantly changing and breaking is an overwhelming challenge for individual humans, and unfortunately often not a sufficient priority for groups and organizations.

krinchan 1y ago

As someone who started out a GenAI skeptic, I’ve found the truth is in the middle. I write a TON of one off scripts now at work. For instance, if I fight with a Splunk query for more than five minutes, I’ll just export the entire time frame in question and have GHCP (work mandates we use only GHCP) spit out a Python script that gets me what I want. I use it with our internal MCP tools to review pull requests. It surfaces questions I didn’t think to ask about half the time. I don’t know that it makes me more productive, but it definitely makes me more attentive. It works great for brainstorming design ideas. The code generation isn’t entirely slop either. For the vast majority of corporate devs below Principal, it’s better than what they write and its basic CRUD code. So that’s where all the hyper productive magical claims come from. I spend most of my days lately bailing these folks out of a dead end fox hole GHCP led them into. Unfortunately, it’s very much a huge time sink in another way. I’ve seen a pretty linear growth in M365 Copilot surfacing 5 year old word documents to managers resulting in big emails of outdated GenAI slop that would be best summarized as “I have no clue what I’m talking about and I’m going to make a terrible technical decision that we already decided against.”

clickety_clack 1y ago
What is GHCP?
- hydhyd 1y ago
  It appears to be GitHub Copilot
  - clickety_clack 1y ago
    Ah! I was trying to fit 4 words into the acronym, like “GitHub Hosting Cloud Platform” or something.

crazygringo 1y ago

> it makes you far more productive as an individual, which if true should be an easy sell Writing unit tests where needed makes you more productive in the long run. Writing in modern languages makes you more productive. Remember how people writing assembly thought compiled languages would rot your brain! But people just resist change and new ways of doing things. They don't care about actual productivity, they care about feeling productive with the tools they already know. It's a hard sell when an application moves a button! People don't like change. Change is always a hard sell to a lot of people, even when it benefits them.

haskellshill 1y ago
> Remember how people writing assembly thought compiled languages would rot your brain! Well, how'd you describe web apps of today if not precisely brainrot? > They don't care about actual productivity, they care about feeling productive Funny you'd say that, because that describes a large portion of "AI coders". Sure they pump out a lot of lines of code, and it might even work initially, but in the long run it's hardly more productive. > It's a hard sell when an application moves a button! Because usually that is just change for the sake of change. How many updates are there every day that add nothing at all? More than updates that actually add something useful, at least.
jacobolus 1y ago
To the contrary, people resist change for good reasons: changes to tools rob attention and focus from the work, often for completely arbitrary or decorative reasons. Sometimes changes remove or break important aspects of the tool and force someone to waste time developing a new workflow which is, on average, no better than the previous one. It is vanishingly rare that the software team making the changes in question did sufficiently rigorous testing to show that the new version is a net "benefit" for most users of the software; they don't have time for that. All too often, no significant group of users was even consulted about the changes, which were made for reasons like advancing someone's career ("shipped X feature changes") or looking different for the sake of marketing something merely re-arranged as new ("the old style was so 2018"). The teams making changes to software are, on average, moderately worse than the teams who originally developed the software, if only because they missed out on the early development experience, and often don't fully understand the context and reasons for the original design and don't reason from first principles when making updates, but copy the aspects they notice superficially while undermining the principles they were originally established on. Even when the changes are independently advantageous, it is common for changes to one part of a system to gratuitously break a variety of other parts that are dependent on it. Trying to manage and fix a complex web of inter-dependent software which is constantly changing and breaking is an overwhelming challenge for individual humans, and unfortunately often not a sufficient priority for groups and organizations.