63 pointsby giuliomagnifico5 hours ago8 comments
  • gkamal2 hours ago
    This looks like measuring what is easy to do, rather than what really matters.

    PR open counts, issues created , ceos/founders spending more time on linear don't automatically lead to better outcomes (in my experience they are often negatively correlated:-) )

  • agnishom16 minutes ago
    I didn't know Linear has "AI features". Linear is boring, but that's actually fine by me.

    I use LLMs to write my code, but this does not show up in this data.

  • slopsosnan hour ago
    The AI Slopologists strike again. More garbage by garbage people.
    • subarctic41 minutes ago
      Can't tell if you mean the people the article is talking about or the article itself
      • what18 minutes ago
        ¿Por qué no los dos?
  • jdw644 hours ago
    These days, my work has become: generate code for 20 minutes, then spend an hour reading it.
    • tankaiji3 hours ago
      And then more hours cleaning it up and re-prompting.
      • danggggg3 hours ago
        Why not just write the code yourself? To me it seems like methodically constructing the pull request by hand is probably faster than lazily prompting and re-prompting.
        • denkmoon3 hours ago
          because my manager will ping me and say "anon you aren't prompting enough" like they never heard of Goodhart's law before.
          • what16 minutes ago
            Write a script to make random prompts and use tokens. Not like they look at what you’re actually prompting.
        • jdw643 hours ago
          Writing code directly takes longer to warm up. Usually, I'd keep tens of thousands of lines in my head. In the past, I spent a lot of time designing error propagation and execution contexts. (Talented people might figure it out right away, but unfortunately I don't have that kind of talent.) So I'd have to think about things like Result<T> and how far to propagate errors—and worry about whether my approach would conflict with the existing codebase.

          But these days, AI just generates code following the existing patterns of the codebase. In the past, staring at a blank screen meant going through a checklist of things to design—starting from policies and writing everything down step by step. Now, I just ask AI and it gives me a template—which is great. Then if the AI makes a mistake, I fix it manually.

          Of course, I still hand-code sometimes—but only in the areas I enjoy. Most of the time, I use AI coding. Both are fun, and they complement each other in interesting ways. Doing both together is actually enjoyable.

          • skydhash3 hours ago
            For me, coding is either a flow state (when I have huge swaths of code to write) or deeply thinking about just a few lines (mostly to figure if I caught everything). The latter case is when I procrastinate the most, because I usually have an idea of a solution, but don’t want to do the work of actually verifying if it’s correct. Using AI then is skipping the enjoyable part (writing the code) to the unpleasant part (formulating hypothesis and verifying them).
            • jdw642 hours ago
              I feel similarly, but at the same time, I think I am the exact opposite. I actually find formulating hypotheses more fun.

              For hobby projects or things I start casually, I usually do not think about errors and such at all. When it is a tool I want to build or need for myself, I really do not care about that part.

              In my case, I do not contribute to open source at all. Mostly, I deliver code for factory systems or specific companies, and usually, there are strict enterprise requirements. (To be precise, there is always that mandatory code the lead developer on their end dictates, right?) That kind of code is mostly no fun, but it has to meet their requirements and often clashes with my own style. Having AI write that code for me is a huge relief.

              In that sense, I think it is just a difference in personality and preferences. I originally became a programmer because I wanted to make games. I started programming because I found it fascinating to see things drawn and displayed on the screen. Becoming a programmer was all because making Flash games was so much fun... So in that regard, for me, writing code is just 'drawing what I want on the screen', which is why I guess I do not mind if the code is written by AI.

              When I contribute to other people's projects, I do not use AI for anything other than English translation, but for my own projects, I have no hesitation.

              Is this really just a difference in inclination? It is not that I did not enjoy writing code, but rather that seeing what I want rendered on the screen brings me more joy.

              When the concept of 'vibe coding' first came out, I really hated it (since my knowledge was earned over 4 to 5 years of getting scolded by lead developers as a subcontractor and factory software provider). But thinking about it, what I really wanted to do as a developer was just to build the worlds I envisioned, so I decided not to let it bother me too much.

              We talk often here on HN, and I really enjoy debating with you. I learn a lot from you.Mr."skydhash", I actually remember you quite often, and I even steal a few keywords from your posts sometimes. Because we have different tendencies, we occasionally clash, but having these conversations is exactly what makes it enjoyable.

              Thank you for always replying. Have a great day, and I hope this does not offend you in any way.

              • skydhashan hour ago
                > Is this really just a difference in inclination? It is not that I did not enjoy writing code, but rather that seeing what I want rendered on the screen brings me more joy.

                I've been tinkering with things since a very young age, started learning about computers in middle school and really started with programming in college (I had the basics since high school, but I was interested more in 3D modeling). So writing code is more like tinkering for me and I don't really particularly care about the result other than making it happen (correctly). Once it's done, it's no longer a subject of intellectual interest.

                So the joy of creating a program is in the creation itself. Once it's done I merely use it (or maintain it if it's part of the work).

                I don't condemn AI use, even when doing vibe coding. My main issue is with the hypers stating that it's ok to lower a codebase quality or encouraging recklessness (and the dubious anecdotes) in a collaborative settings. If you can ensure quality and collaborate easily with your colleagues, go ahead. If you can't, then you shouldn't send PRs around.

                > Thank you for always replying. Have a great day, and I hope this does not offend you in any way.

                Have a great day too. I always appreciate the different point of views on a subject. It's a big world and everyone has their own perspectives.

                • jdw64an hour ago
                  >If you can't, then you shouldn't send PRs around.

                  I think this is exactly why our differences emerge.

                  I rarely collaborate with colleagues. In contract delivery work, that is simply how things operate. Usually, after the architecture is divided into modules, I take on the role of implementing one entire area from start to finish. Because of this, I actually have almost no experience with direct code level collaboration.

                  While multiple developers typically share a single code base and constantly exchange PRs, I take full responsibility for the internal implementation within the designed I/O interfaces, which seems to be where our divergence stems from.

                  When the modules are finally integrated, it only becomes a matter of accountability. In that sense, aside from my own website, I might not actually be doing any sustainable development. To be honest, as you know if you try AI vibe coding, the AI's abstraction and my abstraction are different. Because I am not used to its structure, it is not easy for me to manually fix the code generated by AI. Even if I do fix it, I mostly just tweak the surface level. In that regard, I completely agree that there are valid concerns regarding long term maintenance. However, since meeting strict deadlines and ensuring the required behavior are more important to me than long term maintainability, I tend to be more lenient toward AI generation.

                  It seems we reached different conclusions because we operate in completely different domains. It is always fascinating to see how perspectives differ depending on the field when having these conversations. Have a nice day.

    • mulanrooan hour ago
      [dead]
    • danggggg3 hours ago
      That's gotta be at least 10x or 20x more efficient than the old way of doing things.
      • dullcrisp3 hours ago
        It could be. Or it could be 1x, or 0.2x. You don’t have enough information to make that judgment.
        • danggggg3 hours ago
          I was joking. The workflow doesn't seem particularly fast or engaging in my opinion. AI code generation doesn't seem worthwhile to me.
          • dullcrisp3 hours ago
            Well you got me. I’d agree about that workflow, but something more rapid like a few seconds generating code and then a couple minutes reading it can be more engaging to me than writing it out yourself. I think it’s near time we all stop having such strong opinions about the matter either way personally.
            • danggggg3 hours ago
              > I think it’s near time we all stop having such strong opinions about the matter either way personally.

              I don't think this is reasonable given how abusive the pro-AI rhetoric has been for years now.

              • slopinthebag4 minutes ago
                Yeah I kinda agree. The AI boosters have been super annoying for a while.

                I’m not anywhere close to an AI booster but I find value in it. I think we should think of it less like some intelligent being or “agent” and more as a code generation tool. It would both be more productive and healthier.

              • dullcrisp3 hours ago
                I’m entitled to my opinion about your opinion just like you’re entitled to your opinion about my opinion about your opinion.
                • danggggg3 hours ago
                  If you don't accept my opinion as your own you're going to lose your job and become a member of a permanent underclass.
                  • dullcrispan hour ago
                    You make it sound like it’s a motivated opinion.
          • slopinthebag3 hours ago
            It’s worthwhile to me under specific conditions, mainly that the codebase has existing patterns and abstractions that the LLM utilizes, and they’re actually good. It’s not a common case but I’m lucky that one of the codebases I’m in is one I built myself mostly by hand, and LLMs are really effective in it at the moment. My main concern is making sure the generated code maintains the high standard, but it’s definitely saving me time.

            I’ve kind of changed my mind on prompting, it’s definitely a skill. It’s a skill based on your own skills in the domain. I’m at the point where I can get the LLM to generate the same code (roughly speaking) that I would have written. So it’s basically generating the same thing I would write, just faster. So it’s like reading your own code. Using it as a crutch to do things you aren’t capable of is where people run into trouble. That’s where the massive amounts of code review come into play. For me, I’m only ever reviewing 100-300 loc changes at a time. Often less. Because I know what I’m doing and can break things down into manageable diffs.

            Can’t see myself going back, but also can’t see myself doing it without the experience I have without LLMs. Which is a bit of an issue for new developers. Not sure what the solution is for that.

            • dullcrisp3 hours ago
              That plus if you’ve ever stared at your code and then searched StackOverflow to see if you could find a better way of doing it, it’s like having that running continuously.
              • slopinthebag7 minutes ago
                Yeah it’s great for prompting for improvements, granted you can actually judge the suggestions for yourself. They’re often slightly or majorly bad.
  • greatgib3 hours ago
    "Pull requests are up 111% in two years". Would be more honest to say that the number of pull requests "detected" by linear are up XXX%. Because it only works if you setup git repo tracking and use it properly. And at that point it is not obvious if more teams are using linear and using it correctly, or if the number of PR really increased that much!
  • 0xbadcafebee3 hours ago
    > Time spent on customer requests, docs, and projects held steady [..] AI has so far changed how teams execute far more than how they decide what to build

    I think the measurement for this may be flawed. We do mostly use AI to decide how to build. But what we build is influenced by AI-driven research into a problem or task. That's largely done in coding and desktop AI tools, not Linear Asks/AI.

    I'm working on accelerating my team's work by implementing AI-driven code pipelines with guardrails to eliminate as much unnecessary review time as possible. Also making a chatbot for turning repetitive tasks & PRs into buttons, and an "architectural guidance" chatbot that gives advice tailored to our business, software/system architecture, cloud, standards, etc. This puts AI and automated jobs in the center of both how (automated task) and what (architecture guidance).

    But this has a not-so-great implication for Linear. With my tools, a human never has to touch a ticket, so we could use any ticketing system with an API or CLI. Linear is a great product because they made a great interface. What happens when I replace their interface with a chat bot?

  • Phill_Madd2 hours ago
    [flagged]
  • CircuitSeuss4 hours ago
    [dead]