Half of All Engineers

  • Comments posted to this topic are about the item Half of All Engineers

  • Thanks for posting your issue and hopefully someone will answer soon.

    This is an automated bump to increase visibility of your question.

  • WOW!

    WOW!

    Steve, you've given me a lot to think about in this post. I've got to think about this for a while.

    Rod

  • I wonder why people think that "moving slower" is a bad thing.

    The good part about that is, they're going to need people to fix the stuff that the companies that moved fast produced.

    Ah... what of AI?  I've been testing certain aspects of that for more than two years and I'm writing an article about one of the "Silent Failures" that it writes, which is actually a catastrophic failure that could get a company sued or worse.

    I also use AI to help me "speculate" on code and sometimes it comes up with some pretty good answers.  But... here's the catch there... you need to know enough to ask the right questions.  Otherwise, it simply resorts to the "Most common answer that can be returned the quickest".  In other words, it's works like a "consensus engine" near the beginning of most sessions for a whole lot of people that don't know what to ask next.  And so, what I call "Corpus Infectious" (my name for the "band wagon" that frequently has chicken poop in the hay) prevails and becomes even more self-perpetuatingly infectious.

    And, because a whole lot of people just don't care to learn and just want a "good enough for now" answer, AI will prevail.

     

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • I think moving faster is good, but, as Jeff noted, you have to know what you want to move faster and evaluate the outputs. For repeatable stuff, where I know what I Want, it can be amazing. For speculative stuff, or things I'm investigating, not as much.

    I like the slowness of some things. I've tried audio AI prompts and it's too fast. My brain doesn't interact will or smoothly enough. Writing slows me down a bit and I do better.

    Like most things, it depends. Fit the tool to the job.

  • I am reviewing a PR where AI has been used extensively.

    In terms of functional requirements, it works.

    In terms of NFRs, such as maintainability, code quality metrics, sensible variable names, well-structured design and adherence to standards, God help us.

    The challenge I am facing is that the UAT has satisfied the user, so I am under tremendous pressure to rubber-stamp the PR.  The code has been produced at speed, and there is a lot of it to review.  Far more than I would usually expect in a PR, and GitHub is showing a lot of files as being "Too big to render by default" messages.

    If this were submitted to me by a human I would reject it outright and have a serious word with their manager.

    I don't blame AI for this.  I've reviewed PRs where AI was given clear instructions for the functional and non-functional requirements.  This included documented standards, project structure, etc.  With that sort of attention to detail, AI performs scarily well.  I fear that the way companies allow AI to be implemented is with inadequate guardrails, training and with a starry-eyed optimism over common sense.

     

     

  • WOW, David, what a dilemma you're in? I appreciate the fact that you have some standards to go by. We don't where I work. This has resulted in contractors introducing complete applications over the weekend, then creating a PR and assigning it to the most junior developer on the team. But things move so fast here at work that I never have the time to bring this terrible issue up, before its time to work on the next 3 THIS MUST BE DONE NOW!!! projects.

    Rod

  • One of the problems we're seeeing is the human reviewers, and CI systems. are getting overwhelmed with AI code. I do think it's fair to ask the PR be modified to include the NFR things that matter. AI ought to be able to clean those up and match your existing code easily

  • I agree, Steve. And with organizations such as mine, which is still learning how to do PR reviews, having AI generate lots of code will only result is people doing the basics, like open the branch where the code is, test to see if it compiles, then call it good and approve the PR.

    Rod

Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic. Login to reply