I don’t use chat, it’s usually useless.

I think Chat is the most useful feature of Copilot. Prompts like /docs work impeccably, but /explain and /optimize is also pretty good. /tests is hit-and-miss if you have zero tests and require too much context if you already have them. More often than not /fix is a waste of time.

Where I found Copilot to be quite useful is something unexpected: naming things. You can prompt it to give suggestions, you can ask it to refactor things for you. Quite nice.

I think that Claude is far better at generating code, and explore new stuff, but Claude is also down and broken extremely often,not to mention it's annoying limit of 10 questions per half a day.

I use chat the most. It's pretty good once you understand the importance of building context, set up personas, and feed it workable prompts. The biggest mistake I see people do is presume that you can expect it to output gold when inputting garbage.

Once you build up an understanding of what personas work for your personal tastes and what context you need to have, it can output impressive results. The most success I've been having is with somewhat complex refactorizations. Stuff like "refactor X so that Y and Y" can save you a lot of time.

The most disappointing experience has been with writing unit tests. copilot has this infuriating tendency to remove old tests when you're prompting it to add new ones. You need to explicitly request it to append tests to file X without overwriting existing tests for it not to mess up, and even then results are sketchy. For unit tests it's also important to setup good contexts otherwise whatever time you save by prompting copilot to write them will be wasted refactoring code to use specific frameworks and follow specific styles.

You just referenced two languages that don’t have proper sum types. lol.

You're complained about "Proper HTTP implementations in proper languages".

I provided two concrete examples of two of the most popular and production-grade programming language ever developed.

I can provide more.

You then tried to weasel out by moving your goal post from "Proper HTTP implementations in proper languages" to "languages that don't have proper sum types".

I won't waste more of my time with you. Whatever you're posting lacks relevance and does not justify any attention from anyone.

I would only recommend a monorepo if you’re a company with at least 5,000+ engineers and can dedicate significant time to internal infra.

It's funny because at least one FANG does not use monorepos and has no problem with them, in spite of being at the same scale or even perhaps larger than Facebook.

I wonder why anyone would feel compelled to suggest adopting a monorepo in a setting that makes them far harder to use and maintain.

Proper HTTP implementations in proper languages utilize header-name enums for strict checking/matching (...)

I don't know what you are talking about.

Java provides java.lang.Object.HttpHeaders, which is a constants class that provides static final String fields for the popular request and response headers.

.NET does the exact same thing with it's class Microsoft.Net.Http.Headers.HeaderNames.

I can go on and on.

Agile is not a system. It’s a set of principles, set by the Agile manifesto.

The Agile manifesto boils down to a set of priorities that aren’t even set as absolutes.

I strongly recommend you read upon Agile before blaming things you don’t like on things you don’t understand .

Logging in local time is fine as long as the offset is marked.

I get your point, but that's just UTC with extra steps. I feel that there's no valid justification for using two entries instead of just one.

The Philosophy section has quite a few wonky arguments; I’d skip it altogether.

I agree. I wish they moved that to a standalone section so that it could be easily skipable. Reference docs can and should have a rationale, but a lengthy rant is not what leads people to the site.

Because you’d have to stash your modifications to be able to switch branch.

OP said nothing about stashing, only committing WIP commits to feature branches. I don't think none of your remarks apply, because if you really need stuff from the WIP commits you can also cherry-pick them or checkout specific files.

When you have 1000+ Cypress tests, for example, it takes time to run, plain and simple.

It's one thing to claim that tests need time to run.

It's an entirely different thing to claim that the time it takes to run tests is proportional to test coverage.

More often than not, you have massively expensive and naive test fixtures in place that act as performance boat anchors and are massive bottlenecks. Thousands of tests run instantly if each test takes around a few milliseconds to run. For perspective, the round trip of network request that crosses the world is around a couple of hundreds of milliseconds. A thousand of sequential requests takes only a couple of minutes. If each of your tests takes that long to run, your tests are fundamentally broken.

So, you still have to go through all the dependencies, vulnerabilities and incompatibilities.

That's the point. There is no free lunch. Yet, you can live with stable, pinned versions and only upgrade the ones you really need to, and that means exercise your personal criteria instead of mindlessly upgrade everything just because there was a bump in a version number somewhere in an upstream dependency.

Yes, you can now kind of control the timing,

Timing, extent, scope, and impact. That's the point.

but it’s still unacceptable in my opinion, that you have to spend so much time just to not be an active danger to everyone.

You only spend the time you decide to spend. There are already vulnerability scanners that pinpoint exactly which versions need to be updated, and do that automatically for you. Mindlessly opening the floodgate to each and every change is by definition idiocy and a liability.