• 4 Posts
  • 53 Comments
Joined 3 years ago
cake
Cake day: June 11th, 2023

help-circle


  • I’m lead in my team and AI is being used to varying degrees. One colleague is a problem, but was a problem before AI as well. Me and my other three colleagues have a common understanding of you have to take ownership, understand what you’re doing, and document it.

    As a reviewer, I ask for the information it lacks.

    We (our company) has another project started with “AI first” too, and now still works mainly through “document features and behavior and stuff in md files and AI generates it” - so mostly about spec writing and AI generating. I don’t know how well that works, but I’ve heard bad more than good things (which may be common anyway) and it certainly hasn’t lead to meeting timelines (now more than half a year behind the original planned release).

    Personally, I’m still skeptical about AI use, but do use it occasionally. Our project is simply too complex (and legacy and long history of changed dotnet technology as well). It’s more feasible on newer projects, but Blazor isn’t a straight forward framework either, mixing razor, html, css, component isolation, SAP lifecycle, render modes and whatnot.

    I haven’t used AI to a degree where I feel it significantly [negatively] impacts my capabilities. Thankfully, my team hasn’t pivoted into that completely, either. I see the risk and hope pushes though. The promise of AI speeding things up. The customer saying “a bit more risk is fine”; but it’s on us to communicate the difference between risks (the bug fix missed one additional unknown place vs long term maintainability and its associated risks).


  • Quoting here for full context/content and archiving:

    Hello all,

    Thank you all for the vocal and clear feedback. We intended this change to simplify the setup for developers who use agents to build APIs with coding agents as we see many people struggling in wiring these up. Installing skills for coding agents is a new way of working with Postman and we thought that the in-product and website messaging conveys the intent.

    Based on the feedback from the community, we understand this wasn’t the case so we will be re-designing the experience with the right level of control.

    In the meantime, we are reverting this change.

    Notably, early earlier comments

    • provided proof that information on the website about the cli being included was added later than the issue report
    • one comment said they received this stuff as an update

    So the “in product and website messaging” seems like bullshit/lies evading accountability, attempting to change facts.

    The supposed goal of “simplify setup for developers who use agents” leading to changes on existing workflows and setups for people without explicit consent, confirmation, or information - questionable at best.

    Seems pretty clearly like malware/malware behavior.


  • I guess I don’t know what kind of posts you mean specifically, but yes, please do.

    “Programming” can be and is typically interpreted quite broadly. It’s not just “writing code” but development in general, and entails computer science.

    Looks like this programming.dev instance does not have a computer science community yet, but I would love to see one. Cross-posting is possible too.

    Tangential, there’s !experienced_devs@programming.dev, but that’s a different branch even if it can entail compsci.

    I would love to see more practice or science or theory or hands-on posts in this community.

    In the end, there’s the option of just trying and seeing what votes and comments tell; appreciation or rejection.




  • I didn’t have this issue, but I will share my opinion anyway.

    What do you mean by “actual programming”? I would expect that to include not knowing stuff beforehand, to explore and prototype solutions and missing information. That’s the opposite of what you seem to expect, judging from the rest of your sentence? (missing know how, unclear docs, no youtube course to follow along to)

    I learned through hacking website and related stuff in php, going into a popular C++ FOSS project, and other projects. I oriented myself through what already existed and documentation.

    The best way to learn is through self interest, through actual projects or functionality you try to implement. If it’s scoped small enough, with a doable challenge, that’s how you grow.



  • The advantage of decompilation as a task is that you have a reference output you can validate against.

    I would assume the approach, mechanisms, and quality of produced code is similar to general/prompted code generating.

    I assume the produced code (and its quality) depends on the compiled code; how much was stripped or obfuscated, and what runtime are we talking about which may or may not have language constructs that guide structure. With little metadata or code structure left AI would shift more into it’s general patterns than if there is more metadata available that already defines structures or names.

    The thought of integrating a deterministic decompiler and then use AI to structure it and make it more readable while verifying the output remains the same seems like an interesting extension or alternative workflow and toolchain.

    I have not used these kinds of AI decompilation tools or workflows, but thinking purely from my background and general experience.




  • It’s a broad topic.

    Be mindful of how you communicate. Differentiate between questions, risks, wrongs, subjective. Talk with your teammates. Establish a common understanding of deliberate word use or forms, intentions, and necessities to answer or change or not.

    Consider whether passive and non-aggressive communication is the best approach. Some people may not pick up on defensive tone and just not care. Maybe they need more direct and pushy speech and discussions where you point stuff out, including the overall approach to working together and your assumptions or expectations.

    Be mindful of sharing alternative approaches or knowledge vs not commenting to reduce own time investment and number of comments. Discuss with your team where the sweet spot is. This may change over time and is different with different people, their experience in general and in the project.

    Make it clear that the one submitting the code is the owner and person responsible. They have to take ownership.

    If necessary, establish a common understanding of where to commit time investment. Usually it’s much preferable for the author to invest time into a well documented submission over a reviewer trying to understand and find things out through analysis and questions.

    Try to find a common understanding of not just the solution but what the authors understanding and intentions, what edges and alternatives did they consider, what risks or decision basis did they use.

    Establish understanding on what your role as reviewer is. Risk reduction? Common standardized solutions and code? Are you lead and give long term direction, including how things are implemented to reduce long term complexity and variance? Do you teach through reviews?

    If necessary or unclear, ask what or how deep you are being asked to review. Depending on the author expertise and trustworthyness and your load, sometimes merely approving a concept and a broad peek into the most risky parts or what you want to see the approach on may be enough. Sometimes they may be confident and just want approval on the concept, not every code change.

    Be mindful of when to not post comments but ask for a shared screen meeting and talk for them to walk you through or explain things. The author should also be mindful of when they think discussion before asynchronous written review makes sense.

    Consider whether you are always the one who should review. At all, or first. Maybe someone else can. Maybe you can do a second review pass, maybe only on remaining open questions.




  • I’ve been pretty pissed off at “helping bad people” with my freely given information since roughly the summer of 2022.

    The true test of our industry and community; will or how much will the current felt theft non-attribution and non-appreciation of good-will work influence or destroy good-will work like FOSS, free public resources and commons, and their communities.

    Good-will work was, presumably, always thankless for most people. No monetary gain, little direct feedback and appreciation or acknowledgement.

    Now that, seemingly, AI becomes the consumer and interface instead of people, it feels even worse. I would understand if this tips the scales for many people.


  • For me, the same rules apply, but as you say or hint, SQL as a language is different from higher, “structured” programming languages.

    Adding comments on subqueries, applies, conditions, doing deliberate line breaks or oneliners, procedure comments and documentation where they make sense - most of the same things apply and are applicable. Structuring and commenting works quite well, until it doesn’t for performance and readability reasons where you don’t want to introduce additional procedures or functions or separate other aspects.

    In those cases, it is what it is. Often comments can live on the lines where the aspect is.

    I also like to use block comments with open and closing block indication like

    -- \ Table or aspect something stuff \
    […]
    -- / Table or aspect something stuff /
    

    The language doesn’t provide the structure for it, but I can still implement that structure through text comments alone.


  • My colleague who didn’t ask nor describe his changes now generates descriptions and code comments through AI and it doesn’t improve anything. It’s verbose, imprecise, confusing, and irritating.

    I wonder if and how much communication reduced with my other colleagues. I guess probably a bit where they now ask AI (first). But not significantly, in my team, luckily. We still regularly talk. But maybe it’s on a path of reduction right now. I would find it sad and bad as well.


  • It really is a very visible demonstration of human faultiness.

    A reasonable engineering approach would have been an interesting new technology with open discussion and assessment and expansion of exploration. Instead, we get hype cycles and hyperbole claims and lies primarily driven and publicized and repeated as market marketing and investor marketing and an industry driven by money and investment rather than technology and reasonably explorative and increasing usage.

    It’s sad and tragic. But not surprising. It’s a consequence of human psyche, social constructs and market and society system structure.

    When I hear my colleague does a presentation differently for internal towards developers with more reasonable AI takes and a different one for external which basically practically joins the AI hype instead of voicing boundaries, it’s pretty sad that it can’t be honest communication throughout and be understood as such.

    I don’t see it as an isolated fault of “corporate leadership” as in of development factories/teams. It’s a broad issue, from the AI companies, press hype, industry hype, to then corporate and broader industry leadership eating it up and implementing and expecting marketing and hype claims.