3 ms·

Build a new feature. If you aren't bogged down in bureaucracy it will happen much faster.

bandrami 7mo ago
Most of these are new features, but then they have to integrate with the existing software so it's not really greenfield. (Not to mention that our clients aren't getting any faster at approving new features, either.)
- willmadden 7mo ago
  Did you train a self-hosted/open source LLM on your existing software and documentation? That should make it far more useful. It's not claude code, but some of those models are 80% there. In 6 months they'll be today's claude code.
  - bandrami 7mo ago
    What would that help us with?
    - willmadden 7mo ago
      The LLM needs to understand your existing codebase if it's going to be useful building features that integrate with said codebase seamlessly without breaking things or assuming things that don't exist. That's not something you want to give away to a private AI company, so self-host an open source model.
      - bandrami 7mo ago
        I understood how that would help the LLM, I asked how that would help us. What decision would that inform for us that we're currently having trouble with?
        willmadden 7mo ago
        What "decision" are you talking about? You said you don't code, but you administer and maintain code. It sounds like you integrate new features into an existing codebase?
sdf2df 7mo ago
Its this kind of thinking that tells me people cant be trusted with their comments on here re. "Omg I can produce code faster and it'll do this and that". No simply 'producing a feature' aint it bud. That's one piece of the puzzle.
YesBox 7mo ago
I dont use LLMs much. When I do, the experience always feels like search 2.0. Information at your fingertips. But you need to know exactly what you're looking for to get exactly what you need. The more complicated the problem, the more fractal / divergent outcomes there are. (Im forming the opinion that this is going to be the real limitations of LLMs). I recently used copilot.com to help solve a tricky problem for me (which uses GPT 5.1): I have an arbitrary width rectangle that needs to be broken into smaller random width rectangles (maintaining depth) within a given min/max range. The first solution merged the remainder (if less than min) into the last rectangle created (regardless if it exceeded the max). So I poked the machine. The next result used dynamic programming and generated every possible output combination. With a sufficiently large (yet small) rectangle, this is a factorial explosion and stalled the software. So I poked the machine. I realized this problem was essentially finding the distinct multisets of numbers that sum to some value. The next result used dynamic programming and only calculated the distinct sets (order is ignored). That way I could choose a random width from the set and then remove that value. (The LLM did not suggest this). However, even this was slow with a large enough rectangle. So I poked my brain. I realized I could start off with a greedy solution: Choose a random width within range, subtract from remaining width. Once remaining width is small enough, use dynamic programming. Then I had to handle the edges cases (no sets, when it's okay to break the rules.. etc) So the LLMs are useful, but this took 2-3 hours IIRC (thinking, implementation, testing in an environment). Pretty sure I would have landed on a solution within the same time frame. Probably greedy with back tracking to force-fit the output.
- redhale 7mo ago
  > I don't use LLMs much Sorry to be so blunt, but it's not surprising that you aren't able to get much value from these tools, considering you don't use them much. Getting value from LLMs / agents is a skill like any other. If you don't practice it deliberately, you will likely be bad at it. It would be a mistake to confuse lack of personal skill for lack of tool capability. But I see people make this mistake all the time.
  - YesBox 7mo ago
    Would be helpful if you pointed out what I did wrong :). If it's "you didn't explain the problem clearly enough", then that aligns with my original comment.

Most of these are new features, but then they have to integrate with the existing software so it's not really greenfield. (Not to mention that our clients aren't getting any faster at approving new features, either.)

willmadden 7mo ago
Did you train a self-hosted/open source LLM on your existing software and documentation? That should make it far more useful. It's not claude code, but some of those models are 80% there. In 6 months they'll be today's claude code.
- bandrami 7mo ago
  What would that help us with?
  - willmadden 7mo ago
    The LLM needs to understand your existing codebase if it's going to be useful building features that integrate with said codebase seamlessly without breaking things or assuming things that don't exist. That's not something you want to give away to a private AI company, so self-host an open source model.
    - bandrami 7mo ago
      I understood how that would help the LLM, I asked how that would help us. What decision would that inform for us that we're currently having trouble with?
      - willmadden 7mo ago
        What "decision" are you talking about? You said you don't code, but you administer and maintain code. It sounds like you integrate new features into an existing codebase?

sdf2df 7mo ago

Its this kind of thinking that tells me people cant be trusted with their comments on here re. "Omg I can produce code faster and it'll do this and that". No simply 'producing a feature' aint it bud. That's one piece of the puzzle.

YesBox 7mo ago

I dont use LLMs much. When I do, the experience always feels like search 2.0. Information at your fingertips. But you need to know exactly what you're looking for to get exactly what you need. The more complicated the problem, the more fractal / divergent outcomes there are. (Im forming the opinion that this is going to be the real limitations of LLMs). I recently used copilot.com to help solve a tricky problem for me (which uses GPT 5.1): I have an arbitrary width rectangle that needs to be broken into smaller random width rectangles (maintaining depth) within a given min/max range. The first solution merged the remainder (if less than min) into the last rectangle created (regardless if it exceeded the max). So I poked the machine. The next result used dynamic programming and generated every possible output combination. With a sufficiently large (yet small) rectangle, this is a factorial explosion and stalled the software. So I poked the machine. I realized this problem was essentially finding the distinct multisets of numbers that sum to some value. The next result used dynamic programming and only calculated the distinct sets (order is ignored). That way I could choose a random width from the set and then remove that value. (The LLM did not suggest this). However, even this was slow with a large enough rectangle. So I poked my brain. I realized I could start off with a greedy solution: Choose a random width within range, subtract from remaining width. Once remaining width is small enough, use dynamic programming. Then I had to handle the edges cases (no sets, when it's okay to break the rules.. etc) So the LLMs are useful, but this took 2-3 hours IIRC (thinking, implementation, testing in an environment). Pretty sure I would have landed on a solution within the same time frame. Probably greedy with back tracking to force-fit the output.

redhale 7mo ago
> I don't use LLMs much Sorry to be so blunt, but it's not surprising that you aren't able to get much value from these tools, considering you don't use them much. Getting value from LLMs / agents is a skill like any other. If you don't practice it deliberately, you will likely be bad at it. It would be a mistake to confuse lack of personal skill for lack of tool capability. But I see people make this mistake all the time.
- YesBox 7mo ago
  Would be helpful if you pointed out what I did wrong :). If it's "you didn't explain the problem clearly enough", then that aligns with my original comment.