4 ms·

This article is right insofar as "development velocity" has been redefined to be "typing speed." With LLMs, you can type so much faster! So we should be going

This article is right insofar as "development velocity" has been redefined to be "typing speed." With LLMs, you can type so much faster! So we should be going faster! It feels faster! (We are not going faster.) But your definition, the right one, is spot on. The pace of learning and decisions is exactly what drives development velocity. My one quibble is that if you want to learn whether something is worth doing, implementing it isn't always the answer. Prototyping vs. production-quality implementation is different, even within that. But yeah, broadly, you need to test and validate as many _ideas_ as possible, in order take make as many correct _decisions_ as possible. That's one place I'm pretty bullish on AI: using it to explore/test ideas, which otherwise would have been too expensive. You can learn a ton by sending the AI off to research stuff (code, web search, your production logs, whatever), which lets you try more stuff. That genuinely tightens the feedback loop, and you go faster. I wrote a bit more about that here: https://tern.sh/blog/you-have-to-decide/ https://tern.sh/blog/you-have-to-decide/

add-sub-mul-div 1y ago
I think people are largely split on LLMs based on whether they've reached a point of mastery where they can work close to as fast as they think and the tech would therefore slow them down rather than accelerate them.
- no_wizard 1y ago
  The verbose LLM approach that Cursor and some others have taken really annoys me. I would prefer if it simply gave me the results (written out to files, changes to files or whatever the appropriate medium is) and only let me introspect the verbose steps it took if I request to do so. That’s what slows me down with AI tools and why I ended up sticking with GitHub Copilot, which does not do any of that unless I prompt it to
  - cestith 1y ago
    I want a merge request with a short, meaningful comment and the diffs just like I’d get from a human. Then I want to be able to discuss the changes if they aren’t exactly what’s needed, just like with a human. I don’t want to have to hold its hand and I don’t want to have to pair program everything with a chatbot. It also needs to be able to show a logic diagram, a data flow diagram, and a dependency tree. If an agent can’t give me that, it’s not really ready to work as a developer for me.
  - DenisM 1y ago
    LLM might rely on their own verbosity to carry the conversation in a stable direction.
  - daliusd 1y ago
    So you want Aider, Claude Code or opencode.ai it seems. I use opencode.ai a lot nowadays and am really happy and productive.
    - tharkun__ 1y ago
      I really wanted to use Aider. But it's impossible. How do people actually use it? Like, I gave it access to our code base, wanted to try a very simple bug fix. I only told it to look at one service I knew needed changes, because it says it works better in smaller code bases. It wanted to send so many tokens to sonnet that I hit the limits before it even started actually doing any coding. Instant fail. Then I just ran Claude Code, gave it the same instructions and I had a mostly working fix in a few minutes (never mind the other fails with Claude I've had - see other comment), but Aider was a huge disappointment for me.
      - daliusd 1y ago
        I don't know about Aider, I am not using it because of lack of MCP and poor GitHub Copilot support (both are important to me). Maybe in the future that will get better if that will be relevant. I am using opencode.ai with Claude Sonnet 4 usually. Sometimes I try to switch to different models, e.g. Gemini 2.5 Pro, but Sonnet is more consistent for me. It would be good to define what's "smaller code bases". Here is what I am working one: 10 years old project full of legacy consisting of about 10 services and 10 front-end projects. As well tried it on project similar to MUI or Mantine UI. Naturally on many smaller projects. As well tried it on TypeScript codebase where it has failed for me (but it is hard to judge from one attempt). Lastly I am using it on smaller projects. Overall question is more about task than about code base size. If the task does not involve loading too much context when code base size might be irrelevant.
        tharkun__ 1y ago
        Well apparently we're "big" then. About 15 years old code base. About 100 services or libraries. The service I tried to first use it on because of the "only use it on small code bases" was only about 300 files though (doesn't include tests even). But I guess Aider got overwhelmed (or rather overwhelmed the LLM with the repo map) by the entire code base's repo map (that's what it said it was updating before it proclaimed that there were too many tokens. Monorepo. And that was me already knowing what I wanted and just telling it to do it. I never added any files but the one service but it knows the entire repo. Claude code on the other I tell "I need to do X thing across the code base" and it just goes and does it (sometimes badly of course) but it has no issue just "doing its agent thing" on it. Aider wouldn't even be able to do both code and tests in one go? Like the whole idea of "only add the files you need" makes no sense to me for agentic use.
- tharkun__ 1y ago
  I can't. The LLM (Claude Code really) is just too slow. It is just so slow at doing the things I ask it to do once I'm at the review stage. Like the initial plan always sounds great and looks great. Then it goes to actually do the changes and proclaims victory after I left it alone doing other stuff, because it takes a while. Then I review what it did and what it didn't do and I inevitably find that it only did half of what it said it would do and did half of what it did do incorrectly despite what it told me what it would do. The use case here is a large code base that needs changes. Not new feature development on a green field (or a green corner of an established product). And it's just so unbearably frustrating. It's like giving the task to a Junior on probation. I tell them something, they go off for 10 minutes and tell me they're done and I look and find seven holes I need to tell them to fix. But they aren't the Junior that picks up stuff and gets better and needs less supervision. Instead it seems like the context gets more and more polluted and the Junior gets closer and closer to failing his probation. Many grey hairs added recently, because yeah, we also "have to be faster by using AI" now ...
skydhash 1y ago
Naur’s theory of programming has always felt right to me. Once you known everything about the current implementation, planning and decision making can be done really fast and there’s not much time lost on actually implementing prototypes and dead ends (learning with extra steps). It’s very rare to not touch up code, even when writing new features. Knowing where to do so in advance (and planning to not have to do that a lot) is where velocity is. AI can’t help.
- flail 1y ago
  I wouldn't discuss with that part, although there are definitely limits to how big a chunk of a big product a single brain can really grasp technically. And when the number of people involved in "grasping" grows, so does the coordination/communication tax. I digress, though. We could go with that perception, however, only if we assume that whatever is in the backlog is actually the right thing to build. If we knew that every feature has value to the customers and (even better) they are sorted from the most valuable to the least valuable one. In reality, many features have negative value, i.e., they hurt performance, customer satisfaction, any key metric a company employs. The big question: can we check some of these before we actually develop a fully-fledged feature? The answer, very often, is positive. And if we follow up with an inquiry about how to validate such ideas without development, we will find a way more often than not. Teresa Torres' Continuous Discovery Habits is an entire book about that :) One of her recurring patterns is the Opportunity Solution Tree, which is a way of navigating across all the possible experiments to focus on the right ones (and ignore, i.e., not develop, all the rest).
- himeexcelanta 1y ago
  Typing syntax and dealing with language issues takes a lot of mental overhead that AI mostly solves in the right hands. It’s not zero!
giancarlostoro 1y ago
I can agree with this sentiment. It does not matter how insanely good LLMs become, if you cannot assess it quickly enough. You will ALWAYS want a human to verify and validate, and test the software. There could be a ticking timebomb in there somewhere. Maybe the real skynet will kill us with ticking time bomb software bugs we blindly accepted.
- thenanyu 1y ago
  In most scenarios I can tell you if I like or dislike a feature much faster than it takes a developer to build it
  - k__ 1y ago
    If it just came down to the "idea guy liking or disliking a feature" things would be quite easy...
    - thenanyu 1y ago
      why doesn't it? it doesn't have to be you or me personally, it could be a representative sample of our users
      - cestith 1y ago
        So if you wait to put together a representative sample of users and gather the data long enough for the numbers to matter, you’ve gated further changes. If you’ve gated further changes for a week, why does it matter that the feature change was done in an hour or a day?
        thenanyu 1y ago
        Releasing it to users does not take a long time. Randomly select 5% of your user base and give them the feature. If your development process was mature, this would be a button you could push in your deployment env.
ajuc 1y ago
It's like speed of light in different mediums. It's not that photons slow down. They just hit more stuff and spend more time getting absorbed and remitted. Better developer wastes less time solving the wrong problem.

add-sub-mul-div 1y ago

I think people are largely split on LLMs based on whether they've reached a point of mastery where they can work close to as fast as they think and the tech would therefore slow them down rather than accelerate them.

no_wizard 1y ago
The verbose LLM approach that Cursor and some others have taken really annoys me. I would prefer if it simply gave me the results (written out to files, changes to files or whatever the appropriate medium is) and only let me introspect the verbose steps it took if I request to do so. That’s what slows me down with AI tools and why I ended up sticking with GitHub Copilot, which does not do any of that unless I prompt it to
- cestith 1y ago
  I want a merge request with a short, meaningful comment and the diffs just like I’d get from a human. Then I want to be able to discuss the changes if they aren’t exactly what’s needed, just like with a human. I don’t want to have to hold its hand and I don’t want to have to pair program everything with a chatbot. It also needs to be able to show a logic diagram, a data flow diagram, and a dependency tree. If an agent can’t give me that, it’s not really ready to work as a developer for me.
- DenisM 1y ago
  LLM might rely on their own verbosity to carry the conversation in a stable direction.
- daliusd 1y ago
  So you want Aider, Claude Code or opencode.ai it seems. I use opencode.ai a lot nowadays and am really happy and productive.
  - tharkun__ 1y ago
    I really wanted to use Aider. But it's impossible. How do people actually use it? Like, I gave it access to our code base, wanted to try a very simple bug fix. I only told it to look at one service I knew needed changes, because it says it works better in smaller code bases. It wanted to send so many tokens to sonnet that I hit the limits before it even started actually doing any coding. Instant fail. Then I just ran Claude Code, gave it the same instructions and I had a mostly working fix in a few minutes (never mind the other fails with Claude I've had - see other comment), but Aider was a huge disappointment for me.
    - daliusd 1y ago
      I don't know about Aider, I am not using it because of lack of MCP and poor GitHub Copilot support (both are important to me). Maybe in the future that will get better if that will be relevant. I am using opencode.ai with Claude Sonnet 4 usually. Sometimes I try to switch to different models, e.g. Gemini 2.5 Pro, but Sonnet is more consistent for me. It would be good to define what's "smaller code bases". Here is what I am working one: 10 years old project full of legacy consisting of about 10 services and 10 front-end projects. As well tried it on project similar to MUI or Mantine UI. Naturally on many smaller projects. As well tried it on TypeScript codebase where it has failed for me (but it is hard to judge from one attempt). Lastly I am using it on smaller projects. Overall question is more about task than about code base size. If the task does not involve loading too much context when code base size might be irrelevant.
      - tharkun__ 1y ago
        Well apparently we're "big" then. About 15 years old code base. About 100 services or libraries. The service I tried to first use it on because of the "only use it on small code bases" was only about 300 files though (doesn't include tests even). But I guess Aider got overwhelmed (or rather overwhelmed the LLM with the repo map) by the entire code base's repo map (that's what it said it was updating before it proclaimed that there were too many tokens. Monorepo. And that was me already knowing what I wanted and just telling it to do it. I never added any files but the one service but it knows the entire repo. Claude code on the other I tell "I need to do X thing across the code base" and it just goes and does it (sometimes badly of course) but it has no issue just "doing its agent thing" on it. Aider wouldn't even be able to do both code and tests in one go? Like the whole idea of "only add the files you need" makes no sense to me for agentic use.
tharkun__ 1y ago
I can't. The LLM (Claude Code really) is just too slow. It is just so slow at doing the things I ask it to do once I'm at the review stage. Like the initial plan always sounds great and looks great. Then it goes to actually do the changes and proclaims victory after I left it alone doing other stuff, because it takes a while. Then I review what it did and what it didn't do and I inevitably find that it only did half of what it said it would do and did half of what it did do incorrectly despite what it told me what it would do. The use case here is a large code base that needs changes. Not new feature development on a green field (or a green corner of an established product). And it's just so unbearably frustrating. It's like giving the task to a Junior on probation. I tell them something, they go off for 10 minutes and tell me they're done and I look and find seven holes I need to tell them to fix. But they aren't the Junior that picks up stuff and gets better and needs less supervision. Instead it seems like the context gets more and more polluted and the Junior gets closer and closer to failing his probation. Many grey hairs added recently, because yeah, we also "have to be faster by using AI" now ...

skydhash 1y ago

Naur’s theory of programming has always felt right to me. Once you known everything about the current implementation, planning and decision making can be done really fast and there’s not much time lost on actually implementing prototypes and dead ends (learning with extra steps). It’s very rare to not touch up code, even when writing new features. Knowing where to do so in advance (and planning to not have to do that a lot) is where velocity is. AI can’t help.

flail 1y ago
I wouldn't discuss with that part, although there are definitely limits to how big a chunk of a big product a single brain can really grasp technically. And when the number of people involved in "grasping" grows, so does the coordination/communication tax. I digress, though. We could go with that perception, however, only if we assume that whatever is in the backlog is actually the right thing to build. If we knew that every feature has value to the customers and (even better) they are sorted from the most valuable to the least valuable one. In reality, many features have negative value, i.e., they hurt performance, customer satisfaction, any key metric a company employs. The big question: can we check some of these before we actually develop a fully-fledged feature? The answer, very often, is positive. And if we follow up with an inquiry about how to validate such ideas without development, we will find a way more often than not. Teresa Torres' Continuous Discovery Habits is an entire book about that :) One of her recurring patterns is the Opportunity Solution Tree, which is a way of navigating across all the possible experiments to focus on the right ones (and ignore, i.e., not develop, all the rest).
himeexcelanta 1y ago
Typing syntax and dealing with language issues takes a lot of mental overhead that AI mostly solves in the right hands. It’s not zero!

giancarlostoro 1y ago

I can agree with this sentiment. It does not matter how insanely good LLMs become, if you cannot assess it quickly enough. You will ALWAYS want a human to verify and validate, and test the software. There could be a ticking timebomb in there somewhere. Maybe the real skynet will kill us with ticking time bomb software bugs we blindly accepted.

thenanyu 1y ago
In most scenarios I can tell you if I like or dislike a feature much faster than it takes a developer to build it
- k__ 1y ago
  If it just came down to the "idea guy liking or disliking a feature" things would be quite easy...
  - thenanyu 1y ago
    why doesn't it? it doesn't have to be you or me personally, it could be a representative sample of our users
    - cestith 1y ago
      So if you wait to put together a representative sample of users and gather the data long enough for the numbers to matter, you’ve gated further changes. If you’ve gated further changes for a week, why does it matter that the feature change was done in an hour or a day?
      - thenanyu 1y ago
        Releasing it to users does not take a long time. Randomly select 5% of your user base and give them the feature. If your development process was mature, this would be a button you could push in your deployment env.

ajuc 1y ago

It's like speed of light in different mediums. It's not that photons slow down. They just hit more stuff and spend more time getting absorbed and remitted. Better developer wastes less time solving the wrong problem.