4,777 karma · joined October 7, 2011
Talking about MCP agents if that’s not obvious.
Finding the reliable sources of data or enough metadata and experience to make your own judgement is the key skill today.
One full time job equivalent can buy a lot of tooling. Tooling that not only replaces this role but also shifts the feedback a lot closer to dev introducing the breaking change.
One top level "superrepo" is the best of both worlds. You don't break the limits of git, you can include third party repos, you can seal off access to some secret repos. All while still giving benefit of everything checked out in one place. Tooling for flattening the git log exists and is relatively cheap to build yourself, It's easy to design CI that runs both big and small jobs in the superrepo and the subcomponents.
Nested submodules = Game over. Don't ever do it. This is the worst of both worlds. Common components included twice or more need to be aligned to exact same revision, without help of semantic versioning. Components far down the dependency tree need to be uplifted recursively through a chain of submodules, resulting in 10 commits with no common CI for one tiny change.
Not to mention how slow this is, instead of just reading a piece of code or instantly query my already existing internal mental model of it, I have to type a prompt, wait for the response, read the response, hope it understood my intent, hope it understood the code, map it to my own understanding.
"In this comprehensive guide, we compare metal A vs metal B" with 100s of similar articles for every unique permutation of metals. Yeah right someone did that comparision... "Best pocket knife", "Best filet knife", Best Chef knife", bla blabla
I'm not complaining, the new stricter warnings are usually for the better, what I'm saying is that the bedrock of that world isn't as stable as it's sometimes portraited.
Never again.
There's probably a rule against apps impersonating the OS on the App Store, one could only wish for Apple using a more heavy hand against this type of "experience".
The tutorial on requests looks uncanny for being generated with no prior context. The use cases and examples it gives are too specific. It is making up terminology, for concepts that are not mentioned once in the repository, like "functional api" and "hooks checkpoints". There must be thousands of tutorials on requests online that every AI was already trained on. How do we know that it is not using them?
repo = "myorg/myrepo"
tag = "v1.2.3+deadbeef"
out = check_output(["git", "ls-remote", f"https://github.com/{repo}", f"refs/tags/{tag}"], cwd=os.path.expanduser("~/dev"), stderr=PIPE)
Converting exceptions to exits is an anti-pattern that hides the source of the error, f-strings has been a thing for 10 years and argument quoting happens automatically. Progress of output isn't visible in bash either when you capture output with $(), unless you "tee", which opens up another can of "pipefail"-worms.Have you tried actually doing this? Most of the time it makes up urls that don't exist or contradict the answer it just gave.
btw, "scale up" is the second most common answer from those who can't provide better solutions. :)