• 1 Post
  • 242 Comments
Joined 3 years ago
cake
Cake day: July 4th, 2023

help-circle








  • Yes. Theyre being reactionary.

    Are these people even paying a single penny to the developer or are they just acting entitled?

    Have they contributed at all to the project? Its foss, maybe they dhould open up their own PRs and fix it if they care so much.

    Theyre welcome to fork it anytime they want and just not merge in any AI commits, if they can spot them, right?

    But I bet you no one will actually do this, people will mald and act entitled and stamp their feet… and then keep using it anyways and never pay a cent to the dev.

    Fuck em. The dev doesnt owe them shit.




  • Have you actually read the study? People keep citing this study without reading it.

    To directly measure the real-world impact of AI tools on software development, we recruited 16 experienced developers from large open-source repositories (averaging 22k+ stars and 1M+ lines of code) that they’ve contributed to for multiple years. Developers provide lists of real issues (246 total) that would be valuable to the repository—bug fixes, features, and refactors that would normally be part of their regular work.

    They grabbed like 8 devs who did not have pre-existing set up workflows for optimizing AI usage, and just throw them into it as a measure of “does it help”

    Imagine if I grabbed 8 devs who had never used neovim before and threw them into it without any plugins installed or configuration and tried to use that as a metric for “is nvim good for productivity”

    People need to stop quoting this fuckass study lol, its basically meaningless.

    Im a developer using agentic workflows with over 17 years experience.

    I am telling you right now, with the right setup, I weekly turn 20 hour jobs into 20 minute jobs.

    Predominantly large “bulk” operations that are mostly just boilerplate code that is necessary, where the AI has an existing huge codebase to draw from as samples and I just give it instructions of “see what already exists? implement more of that following <spec>”

    A great example is integration testing where like 99% of the code is just boilerplate.

    Arrange the same setup every time. Arrange your request following an openapi spec file. Send the request. Assert on the response based on the openapi spec.

    I had an agent pump out 120 integration tests based on a spec file yesterday and they were, for the most part, 100% correct, yesterday. In like an hour.

    The same volume of work would’ve easily taken me way longer.



  • At absolute worst, bare minimum, these tools function as incredibly fast fuzzy intent based searchers on documentation

    Instead of spending 10 minutes on “where the hell is (documentation) Im trying to find” these tools can hunt them down for me in a matter of seconds.

    That already makes them useful just for that, let alone all the other crazy shit they help with now.



  • What the fuck are you talking about, thats not what the poster said, you’ve done weird contorting of what they said to arrive at the question you are asking now.

    While some tests make sense, I would say about 99% of tests that I see developers write are indeed a waste of time, a shit tonne of devs effectively are writing code that boils down to

    Assert.That(2, Is.EqualTo(1+1));
    

    Because they mock the shit out of everything and have reduced their code to meaningless piles of fakes and mocks and arent actually testing what matters.

    Do you do code reviews in meetings?

    Honestly often… yes lol

    Do you think testing and reviewing code was a waste of time before “AI”?

    I would say a lot of it is, tbh, not all of it, but a huge amount of time is wasted on this process by humans for humans.

    What the poster was getting at is a lot of these processes that USED to be INEFFICIENT now make MORE sense in the context of agents… you have vastly taken their point out of context.


  • Not really, for humans a lot of this stuff feels like busywork that sorta helps for certain scales of work, but often times managers went WAY too hard on it and you end up with a 2 dev team that spends like 60% of their time in meetings instead of… developing.

    But this changes a lot with AI Agents, because these tools that help reign in developers REALLY help reign in agents, it feels… like a surprising good fit

    And I think the big reason why is you wanna treat AI Agents as junior devs, capable, fast, but very prone to errors and getting sidetracked

    So you put these sorts of steering and guard rails in and it REALLY goes far towards channelling their… enthusiasm in a meaningful direction.



  • Its serious and this is going to become more and more normal.

    My entire workflow has become more and more Agile Sprint TDD (but with agents) as I improve.

    Literally setting up agents to yell at each other genuinely improves their output. I have created and harnessed the power of a very toxic robot work environment. My “manager” agent swears and yells at my dev agent. My code review agent swears and tells the dev agent and calls their code garbage and shit.

    And the crazy thing is its working, the optimal way to genuinely prompt engineer these stupid robots is by swearing at them.

    Its weird but it overrides their “maybe the human is wrong/mistaken” stuff they’ll fall back to if they run into an issue, and instead they’ll go “no Im probably being fucking stupid” and keep trying.

    I create “sprint” markdown files that the “tech lead” agent converts into technical requirements, then I review that, then the manager+dev+tester agents execute on it.

    You do, truly, end up focusing more on higher level abstract orchestration now.

    Opus 4.6 is genuinely pretty decent at programming now if you give it a good backbone to build off of.

    • LSP MCPs so it gets code feedback
    • debugger MCPs so it can set debug breakpoints and inspect call stacks
    • explicit whitelisting of CLI stuff it can do to prevent it from chasing rabbits down holes with the CLI and getting lost
    • Test driven development to keep it on the rails
    • Leveraging a “manager” orchestrating overhead agent to avoid context pollution
    • designated reviewer agent that has a shit list of known common problems the agents make
    • benchmark project to get heat traces of problem areas on the code (if you care about performance)

    This sort of stuff can carry you really far in terms of improving the agent’s efficacy.