[–] 8 points 5 days ago

Been using this one for quite a while now. Sometimes you need to share AI conversations for context. My rule of thumb is that I human summarize and contextualize like I would normally, then in a thread below it, fork off an ai;dr quoted reply. Makes it like optional reading.

  • source
  • [–] 6 points 1 week ago

    The handiman who works for my family quite often is not super technical. He was troubleshooting a mini split for me and I walked out to see him vocally chatting with chat gpt going through error codes, handless.

    He found a use, and you'd be wrong to assume "trades" are safe from the chatbot. That doesn't mean his job is going away, but maybe he can do more solo jobs and doesn't need a helper all the time. Or maybe he does his jobs faster. Who knows!

    People don't need to know model names to find a use.

  • source
  • parent
  • context
  • [–] 2 points 3 weeks ago* (last edited 3 weeks ago)

    Legally it isn't, actually. Morally, yes.

    Check out "AI has a labor issue, not a copyright issue" chapter of "The Reverse Centaur's Guide to Life After AI" by Cory Doctorow

    It's a hard chapter to read, but it's important to understand.

    EDIT: I love the downvotes for speaking the truth, seriously people, please understand. It's important.

  • source
  • parent
  • context
  • [–] 0 points 3 weeks ago

    I've run this experiment on myself a great number of times.

    Your story is correct, sometimes. It's not correct all of the time. Sometimes AI is slower and the output is better (think: pair programming). Sometimes AI gets me the first draft and the cognitive understanding takes time (overall, for me, usually faster, but sometimes slower I will readily admit). I'm really good at reading code, I guess? And still other times it will one shot near perfection (in true slot machine fashion). It'll also produce absolute shit, as well, frequently.

    My firm point to you is it's not a blanket truth.

  • source
  • parent
  • context
  • [–] -1 points 3 weeks ago (1 child)

    Listen, I'm a VERY healthy skeptic of AI on a number of fronts, but saying it can't speed things up is just not true.

    I feel like I understand where you're trying to come from with the argument about skill degradation, but the flat statement you say here is undeniably false.

  • source
  • parent
  • context
  • [–] 5 points 1 month ago* (last edited 1 month ago)

    You world be very surprised. It's not what I directly work on, but there are entire programs dedicated to tracking and lowering the cost of password and account resets (and doing it securely). That last part is the hard thing. Large organizations can save millions of dollars if they can get people to not lose/forget their credentials -or- self service those resets (but even then, having that person do it is now losing their time and energy).

    It's not just indirect opportunity costs either, it's direct costs to the IT organization. Smaller teams can absorb this stuff as a rounding error on their time, but the second you're counting in the thousands, you need to deal with this type of thing. (And I'll repeat: securely)

    Now imagine doing it as a B2C+B2B organization like Google or Microsoft. The costs are staggering.

  • source
  • parent
  • context
  • [–] 2 points 1 month ago

    This is a really great point. AI tokens are expensive for quality today, and that will continue. We're already seeing a bit of a plateau, and this whole "let's slow down so we don't kill ourselves" is propaganda, I think. AI companies that leverage "price to value" are going to succeed. I see Google Gemini fitting this mold long term, GLM, Kimi did fit this mold but their later models seem to jump in price pretty fast chasing Opus capability. If you take "capable models" as the standard for price to value and then charge what it actually costs (not VC subsidized), then you're going to see a world where Software Engineers are probably back in high demand. I think the article points out the hard part: how do you grow new Sr. Engineers if you're replacing Jr's with Claude. (I think the obvious answer is that we shouldn't be replacing Jr's with Claude)

  • source
  • parent
  • context
  • [–] 3 points 1 month ago*

    I think saying "we are all product engineers" is not accurate, but this aligns with stuff I've been telling my teams for a while. Everyone needs to start becoming closer to product and moving away from programming as the thing they're valued for. (e.g. I'm not valued because I know Java inheritance rules) To be honest, it always should have been this way (it's how I've lived my career), but some organizations have created this weird "product does the thinking, engineering does the programming" dichotomy and it's in those situations where this argument makes sense. At a small startup where every new hire understands the business problem and works to achieve that goal is not where this argument makes sense.

    My first job was "Analyst/Programmer I" - somewhere along the line it turned into "Programmer" and then "Software Engineer" -- pushing the role farther into a technical silo and farther away from the product "because the product managers know best and the nerds need to make it happen by next quarter /s". The success of individuals on the product side are going to be with folks who can shift to leverage AI for technical chops, and vice versa for Engineers shifting to put on their "Product Hat" more often. With any career, there's going to be a spectrum of what skills fit into the role (e.g. some positions may be more or less technical or more or less business analyst), but I see the shift happening as a way to preserve ones career in an ever changing world. Those that do not adapt will find themselves on the outside looking in and wondering why (or as an alpaca farmer in northern Idaho because they noped out).

  • source
  • view more: next ›