you can? that's why go.sum exists. you can also use the replace directive for more advanced scenarios.

Present iteration of LLMs are, despite what normies would believe, aren't optimised to provide correct solutions. They are optimized to __sound smart__.

This may be just an undesirable artifact of the RLHF process. But the end result is same. They try (?) too hard to sound smart.

Last generation LLM writing was too obvious in its soulless journalistic nature. But the current generation LLMs do all the following things to appear smart; From the lowest levels to highest level

- use clever writing styles and punchlines. Not X, it's a Y'ed Z. (Though it's not funny and makes no sense).

- Overstuff the technical terms, most often using a +. "Add a shim + iptables rule + signal handler".

- Over engineer the low level design. (Eg rather write a function to do some complex parsing when a way exists to avoid it altogether. Write tricky bash script and parse the output for what could be achieved by stdlib in few more lines).

- over engineer the code flow: this is rather because they're clueless and can't step back. But I have fun seeing the LLM come up with 4 5 levels of branching and then extract it into a function, whereas a human would step back and try to avoid the branching.

- over engineer the high level design: well your mistake is letting the word soup machine lead the design. It will add all and kitchen sink with need bullet points and + marks. Only a pleb not sufficiently educated in the matters of computer science will be impressed with such Markdown kitchen sink designs. It's fine to rely on LLM for brainstorming and discovering how to do A, B and C. But if you outsource the job of design, it's instincts (!) to sound maximally smart using bullet lists and + marks will kick in.

https://m.youtube.com/watch?v=IU4ByUbDKNc

So they exist in many rescensions across India each with their own edits and interpolations. Some attempt has been made to create "critical" editions by taking the intersection of existing manuscripts but since there's no expectation of fidelity in transmission, we will never know what the original stories were.

So you can get even the western indologists to agree the battle of 10 kings mentioned in Rigveda very likely happened, and a Vasishtha and a Vishwamitra and a Trasadasyu existed in real life. However the epics leave out or conflict in many details with the aforementioned Vedic texts. Eg: a shantanu finds mention in Rigveda, a Parikshit and Janamejaya are mentioned in later samhitas. However there's no mention of pāndavas, kāuravas or a grand scale war. Neither there is a mention of a vyāsa / krishna dvaipayana in vasishtha's lineage in the accurately transmitted texts. It's very difficult to take Mahābhārata as an accurate historical document.

Eg: Indra would have a much larger role in original versions of mahābhārata and rāmāyana compared to Hindu popular conscience. In Ramayana he defeated kabandha, lent weapons to Rāma, and the hero is frequently compared to him as "Indra among men" - making him technically the most mentioned God in Valmiki's text (https://manasataramgini.wordpress.com/2017/02/12/the-ramaya%...).

In Mahabharata he fights equally with the krishna-arjuna in the burning of khandava episode until a truce is reached (and for reasons beyond the present redactions of the epic and owing to his prominence as ārya national god, the new capital of pāndavas is named.... Indraprastha!).

This kind of stuff is virtually unknown to AI, which reinforces the present pop understanding of the epics, which is to say super shallow and not very interesting.

Numbers 31.17-18

Define the interface and functions and let the AI fill in the blanks.

Eg: I want XYZ class with methodFoo and methodBar which connects to APIabcd and fetch details. Define classes for response types based on API documentation at ...., use localLibraryXYZ for ABCD.

This is the way I found to work well for me. I maintain a tight grip over the architecture, even the low level architecture, and LLM writes code I can't be bothered to write.

I find tab completions very irritating. They're "almost" correct but miss some detail. I'd rather review all of that at once rather than when writing code.

(you can theoretically pass "reload": true (or similar option) in launch.json for auto reload, tho I haven't felt the need to use that in my workflows.)