301–310 of 827 posts
Earlier quoted context omitted.
1st dose is free
LLM APIs are pretty darn cheap for most of the developed worlds income levels.
You should consider how much it actually costs, not how much they charge.
How do people fail to consider this?
Earlier quoted context omitted.
LLM APIs are pretty darn cheap for most of the developed worlds income levels.
Yeah, because they're bleeding money like crazy now. You should consider how much it actually costs, not how much they charge. How do people fail to consider this?
Earlier quoted context omitted.
> That sounds awful. A truly terrible and demotivating way to work and produce anything of real quality This is the right way to work with generative AI, and it already is an extremely common and established practice when working with image generation.
I can recognize images in one look. How about that 400 Line change that touches 7 files?
This is why there has to be "write me a detailed implementation plan" step in between. Which files is it going to change, how, what are the gotchas, which tests will be affected or added etc.
It is easier to review one document and point out missing bits, than chase the loose ends.
Once the plan is done and good, it is usually a smooth path to the PR.
Tight feedback loops are the key in working productively with software. I see that in codebases up to 700k lines of code (legacy 30yo 4GL ERP systems). The best part is that AI-driven systems are fine with running even more tight loops than what a sane human would tolerate. Eg. running full linting, testing and E2E/simulation suite after any minor change. Or generating 4 versions of PR for the same task so that the h…
> Or generating 4 versions of PR for the same task so that the human could just pick the best one. That sounds awful. A truly terrible and demotivating way to work and produce anything of real quality. Why are we doing this to ourselves and embracing it? A few years ago, it would have been seen as a joke to say “the future of software development will be to have a million monkey interns banging on one million keyboar…
Not for the cloud provider. AWS bill to the moon!
Tight feedback loops are the key in working productively with software. I see that in codebases up to 700k lines of code (legacy 30yo 4GL ERP systems). The best part is that AI-driven systems are fine with running even more tight loops than what a sane human would tolerate. Eg. running full linting, testing and E2E/simulation suite after any minor change. Or generating 4 versions of PR for the same task so that the h…
Even if you tell the git-aware Jules to handle a merge conflict within the context window the patch was generated, it is like sorry bro I have no idea what's wrong can you send me a diff with the conflict?
I find i have to be in the iteration loop at every stage or else the agent will forget what it's doing or why rapidly. for instance don't trust Jules to run your full test suite after every change without handholding and asking for specific run results every time.
It feels like to an LLM, gaslighting you with code that nominally addresses the core of what you just asked while completely breaking unrelated code or disregarding previously discussed parameters is an unmitigated success.
Earlier quoted context omitted.
Here’s a few problems I foresee: 1. People get lazy when presented with four choices they had no hand in creating, and they don’t look over the four and just click one, ignoring the others. Why? Because they have ten more of these on the go at once, diminishing their overall focus. 2. Automated tests, end-to-end sim., linting, etc—tools already exist and work at scale. They should be robust and THOROUGHLY reviewed by…
A simple rule applies: "No matter what tool created the code, you are still responsible for what you merge into main". As such, task of verification, still falls on hands of engineers. Given that and proper processes, modern tooling works nicely with codebases ranging from 10k LOC (mixed embedded device code with golang backends and python DS/ML) to 700k LOC (legacy enterprise applications from the mainframe era)
Even before LLM it was a common thing to merge changes which completely brake test environment. Some people really skip verification phase of their work.
Earlier quoted context omitted.
But what does that mean ? If you tell the LLM "Say just 'hi' without any extra words or explanations", do you not get "hi" back from it?
Sometimes I get "Hi!", sometimes "Hey!".
Earlier quoted context omitted.
> Or generating 4 versions of PR for the same task so that the human could just pick the best one. That sounds awful. A truly terrible and demotivating way to work and produce anything of real quality. Why are we doing this to ourselves and embracing it? A few years ago, it would have been seen as a joke to say “the future of software development will be to have a million monkey interns banging on one million keyboar…
I'm not sure that AI code has to be sloppy. I've had some success with hand coding some examples and then asking codex to rigorously adhere to prior conventions. This can end up with very self consistent code. Agree though on the "pick the best PR" workflow. This is pure model training work and you should be compensated for it.
You have to be extremely verbose in describing all of your requirements. There is seemingly no such thing as too much detail. The second you start being vague, even if it WOULD be clear to a person with common sense, the LLM views that vagueness as a potential aspect of it's own creative liberty.
Earlier quoted context omitted.
A simple rule applies: "No matter what tool created the code, you are still responsible for what you merge into main". As such, task of verification, still falls on hands of engineers. Given that and proper processes, modern tooling works nicely with codebases ranging from 10k LOC (mixed embedded device code with golang backends and python DS/ML) to 700k LOC (legacy enterprise applications from the mainframe era)
Agreed. I think engineers though following simple Test-Driven Development procedures can write the code, unit tests, integration tests, debug, etc for a small enough unit by default forces tight feedback loops. AI may assist in the particulars, not run the show. I’m willing to bet, short of droid-speak or some AI output we can’t even understand, that when considering “the system as a whole”, that even with short-term…
Code, manually crafted by professionals, will almost always beat AI-driven code in quality. Yet, one has still to find such professionals and wait for them to get the job done.
I think, the right balance is somewhere in between - let tools handle the mundane parts (e.g. mechanically rewriting that legacy Progress ABL/4GL code to Kotlin), while human engineers will have fun with high-level tasks and shaping the direction of the project.
Earlier quoted context omitted.
1st dose is free
LLM APIs are pretty darn cheap for most of the developed worlds income levels.