160
How are you fighting back against skill atrophy caused by AI at work? (lemmy.zip)
submitted 10 hours ago by to c/programming@programming.dev
61 comments fedilink hide all child comments
 

I currently work at an "AI First" ๐Ÿคข fintech company, and we're mandated to program agentically. I was fortunate enough to start working before the AI hype, but the environment right now is daunting.

There's too much unmaintainable code slop and throw away scripts committed that I can't keep track anymore. Each PR has so much diffs that it feels like someone had diarrhea and shat all over.

I try to manually review the code, but it feels like best effort at most. Like I may only understand 70% of the thing that I'm reviewing. What ends up happening usually is that I just ask the model and verify the output(which is horrifying I know)

I spend the whole day arguing with AI, reviewing, and pushing back against its output that sometimes I wonder if I am the one driving AI or is it driving me.

--

Recently, I noticed that I've becoming more reliant on the model and that my skills have been atrophying. What would've taken me an afternoon if I program it by hand, would take me a week now if I do it now. I also find my head hurting and myself glossing over the code in code reviews and prompting claude to do even the basic of commands.

I get that there's more to programming in software engineering (collaboration, dealing with people, etc etc), but I don't feel like I am in control of the systems I am building anymore with the engineering aspect being replaced with babysitting and self lobotomy.

--

Off work hours, I try to brush up by reading on system design and architecture books, typing by hand if I'm learning a new technology or stack, but I feel like it's not enough to prevent from skill atrophy.

How are y'all coping and how do you recover from this? I am afraid on what skills that I'll be able to bring at my next place of employment if I resign and that I'm becoming a jack of all trades master of none type of thing - having only shallow understanding.

you are viewing a single comment's thread
view the rest of the comments
[โ€“] 1 point 7 hours ago (2 children)

Enforce commit size and quality.

Label PRs:

  • xsmall for <25 LOC
  • small for 25-75
  • medium for 75-150
  • large for 150-250
  • xlarge for 250-500

Anything above and instantly reject. Do standard exclusions: docs, code comments, tooling (though I'd categorise this separately), etc.

Have very strict rules on creation of new scripts, new tooling, and so on.

  • permalink
  • fedilink
  • source
  • hideshow 2 child comments
    •
  • [โ€“] 2 points 4 hours ago (1 child)

    Instead of sizes, I recommend:

    • high quality for <25 LOC
    • quality for 25-75
    • decent for 75-150
    • questionable for 150-250
    • shit for 250-500
    • dogshit for 500+

    Public histograms per engineer. ๐Ÿ˜„

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [โ€“] 0 points 3 hours ago

    Not necessarily. Sometimes you keep features on separate branches and merge them at appropriate times, and those branches can grow BIG. But even if all individual PRs of the feature branch were reviewed, you still need to review the big blob.

    Similarly, some things just take a lot of LoC without compromising quality.

    e.g. in a project I work on, most API clients are generated (no, not genAI, but OpenAPI descriptors and Gradle tasks). When you add a new version, that can end up a big, chonky boi PR, but it's all auto mergeable because 1, it's generated via a known good template 2, CI already checked it.

  • permalink
  • fedilink
  • source
  • parent