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.
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.
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.
"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!
> 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?
These days, my work has become: generate code for 20 minutes, then spend an hour reading it.
And then more hours cleaning it up and re-prompting.
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.
That's gotta be at least 10x or 20x more efficient than the old way of doing things.
It could be. Or it could be 1x, or 0.2x. You don’t have enough information to make that judgment.
I was joking. The workflow doesn't seem particularly fast or engaging in my opinion. AI code generation doesn't seem worthwhile to me.
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.
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.
"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!
> 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?