I don't see how this would actually help. If people don't want to disclose they used AI they will just strip the message from the commit.
Maybe those customers should just be more selective with the people they allow to contribute to their project?
Also, this kind of message doesn't even bring valuable info: it doesn't explain how the AI was used (could be 99% vibe-coding, or just a quick "Please review current changes" + minor fixes at the end?), which model was used, etc. Like other commenters here I can't see this as anything else than a marketing push for Copilot.
Don't take it personally though, you are probably not the one that should be taking the heat since the change was directly pushed by your product manager.
> Also, as I said, information about the prompts quickly reveals competence / incompetence, and is crucial for management / business in hiring, promotions, managing token budgets, etc.
I fail to see why you would need that kind of information to find out if someone is not competent. This really sounds like an attempt at crazy micro-management.
The "distillation" that you want already exists in various forms: the commit message, the merge request description/comments, the code itself, etc.
Those can (and should) easily be reviewed.
Did you previously monitor which kind of web searches developpers where doing when working on a feature/bugfix? Or asked them to document all the thoughts that they had while doing so?
Except that nowadays it feels more like people asking you for the time every 2 minutes while standing just in front of Big Ben.
I see it everyday on forums/Discord servers where some users will treat you like their personal search engine simply because they are too lazy to spend 10s reading the results themselves.
Yep, the comment is wrong, this line won't wait for anything but rather check that both calls resolved to a truthy value.
There are also some other incorrect things in that post that makes the code overly complicated, like:
> Every async function needs a new Promise, and needs to resolve()
That's definitely not needed unless you call something that runs asynchronously without being `async` or returning a standard `Promise` (in which case you could probably use a generic wrapper to convert them to `Promise` objects and avoid having to do that everytime).
I'm wondering if selling physical copies of the game doesn't come with legal issues...
The "Nintendo" logo you see when booting a Game Boy comes from the cartridge and is checked against one stored in the console.
If they don't match the whole thing stops, which means that you have to add (and distribute) a Nintendo logo to your game in order for it to work on real hardware.
I have not tested this particular game on real hardware, but multiple games found ways around the console's logo checksum. It has a buggy implementation that can be circumvented, allowing you to never have the logo on your cartridge.
Hiding the URL would be a terrible idea, no matter how much "simpler" it would be for the average user: it would either only be enabled for a handful of websites chosen by Google (which would mean having an inconsistent UI) or create a lot of security issues (what if someone creates a website and manages to also display "Wikipedia FR" with a similar layout?).
> Except it doesn't provide Promises, Map, Sets (and I can't remember if they added Object.Assign support, but it also was not supported when I was using it). When you provide your own polyfills, TSC complains unless you provide typings and add specific config values informing it what you polyfilled.
I think you may have misunderstood what Typescript is and isn't.
It isn't meant to provide polyfills, it is only supposed to handle the grammar of the language that needs to be transpiled.
That's why you have the two following settings:
- target : Which version of the grammar will be available at runtime (eg. classes, async, ...), that's the part used by the transpiler
- lib : Which libraries (eg. promises, maps, sets, ...) you know will be available at runtime (only used for type-checking)
Using a polyfill is really easy if you are using the right value for "lib" since the it will have the same signature as the real method: simply import it once in your project.
That's fair enough. My actual main issue with this is that TS was hostile towards any external JS libraries, especially before 1.8, but still sporadically in 1.8+, and that affected polyfills too. I also had serious issues importing external libraries that provided their own polyfills.
It was sort of a catch-22 that it didn't like JS yet expected JS polyfills. This has been greatly improved but it took far too long for a project that purports to be a part of the JS ecosystem, which raises questions and I must admit, makes me cynical about whether this was a business tactic.
I've now written many replies with elaborations and clarifications of my criticisms, so it may seem like I'm excessively negative about TS. I actually really like the language itself, especially the static type checking, which is the one main selling point. The OO language features are great because they're optional. I just think everything around the language is rough, and if you're unlucky with it, it can ruin the whole experience.
I remember that at one point, people would declare `require` and use `import whatever = require('whatever')` for npm libraries. This thing was for the longest time absolutely hostile towards JS, and some remnants of that philosophy remain to this day.
I have not forgotten being told to write what amounts to C header files, for JavaScript, in order to allow TSC to play nice with the ecosystem! That was definitely hubris.
This seems to be confirmed here: https://socket.dev/openvsx/package/whatwedo.twig/versions/1....
reply