I often felt that current ML speeds up newbie devs by effectively teaching them the language and libraries — but slows down experts that already know the stack well from memory.

It depends. You don’t need LLMs to write stuff for you that you already know. You use them to take.care of the drudge work or explore things you are not familiar with. Things like Copilot’s /explain can speed up onboarding even for seasoned developers, and Copilot can also help you speed up iterations on proofs of concept. For example, I’ve been using Copilot to experiment with some changes to the software architecture of some projects I own, and it’s fantastic at generating code following specific design patterns. It’s also fantastic to get it to iterate designs in near-real.time by prompting it with directives such as “repeat the last example but implementing X with design pattern Y and moving the implementation to Z”. You are presented with examples that you can browse through and get a taste of what you’d get, but with a fraction of the time. To top things off, you can prompt Copilot to present pros and cons and even propose optimizations.

Like any tool, it has its purposes. You just need to learn how to use it.

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.

Like most have already said, the auto complete is top tier (…)

My experience is the exact opposite. Even though it has its moments, more often than not it just hallucinates and proposes a lot of stuff that neither matches definitions nor could possibly compile. I guess that this might reflect the impact of having classes with similar names in multiple namespaces but it’s bad to the point I prefer to rely exclusively on plain old autocorrelation.

He’s not being run out of the project… yet.

To be honest, to me this all sounds like sociopath behavior to throw politically-inconvenient people under the bus in desperate self-preservation, and hoping this would intimidate anyone falling out of line.

Everyone in that group should present their immediate resignation. Shameful.

Imagine running Guido out of his own fucking project

Imagine running Guido out of Python and still have the gall to argue they are acting on Python’s best interests.

What a bunch of self-serving fools.

Boy, does that group sound like the ultimate bunch of social climbers trying to make a living out of someone else’s work.

I agree that complexity is the problem and I’m avoiding Kubernetes like the plague. I set up a nomad cluster in a few days and it just works, has service discovery, and is perfectly simple to understand.

I think Kubernetes gets a bad rap out of ignorance. You can make it as complex as you want, but you can also keep things trivial and simple if that’s what your aiming for.

Case in point, I operate a Kubernetes cluster with microk8s. I got my nodes up and running in a one-time setup, and after this all I need to do is kubectl apply -k to get my apps deployed and running. Each konfiguration script is trivial too. ingress, services, deployments. That’s it. A docker compose script is far more complex and hard to maintain than that. Where’s the complexity?

Honestly, have you ever gave kubernetes a try? If you did, what exactly did you tried to do? I bet that if you do an honest apples-to-apples comparison with any setup that you believe works, you’ll notice that you’re doing far more work to achieve the same result. This is a given as you’re pointing out nomad of all things as something simple.

I imaging trying to be a professional electrical engineer (despite having a degree)

That’s the definition of specious reasoning, and fails to address the point I made.

This might be relevant to the discussion:

https://en.wikipedia.org/wiki/Dunning–Kruger_effect

He is completely right in this context, not all European countries have the same workers right as Germany.

I understand that this isn’t an academic discussion on logic, but it’s also not correct to claim that Europe doesn’t have basic worker’s rights because there might be a country or two in the dozens of countries that make up Europe that might not have explicitly prohibit a specific form of abuse.

Focusing on code coverage (which doesn’t distinguish between more and less important parts of the code) seems like the opposite of your very good (IMO) recommendation in another comment to focus on specific high-value use-cases.

The usefulness of code coverage ratios is to drive the conversation on the need to track invariants and avoid regressions. I agree it’s very easy to interpret a metric as a target to optimize, but in this context coverage ratios is primarily used to raise the question on why wasn’t a unit test added.

It’s counterproductive to aim for ~100% but without this indicator any question or concern regarding missing tests will feel arbitrary. With coverage ratios being tracked, this topic becomes systematic and helps build up a team culture that is test-driven or at least test-aware.

Code coverage is an OK metric and I agree with tracking it, but I wouldn’t recommend making it a target. It might force developers to write tests, but it probably won’t convince them.

True. Coverage ratios are an indicator, and they should never be an optimizable target. Hence the need to keep minimum coverage ratios low, so that the team has flexibility to manage them. Also important, have CICD pipelines export the full coverage report to track which parts of the code are not covered.

The goal is to have meaningful tests and mitigate risks, and have a system in place to develop a test-minded culture and help the team be mindful of the need to track specific invariants. Tests need to mean something and deliver value, and maximizing ratios is not it.

That should be a disciplinary issue.

And that’s how you get teams to stop collaborating and turn your work environment to shit.

Here’s a way to convince a team to write unit tests:

• setup a CICD pipeline,
• add a unit test stage,
• add code coverage calculation,
• add a rule where unit tests fail if a code coverage metric drops.
• if your project is modularized, add pipeline stages to build and test and track code coverage per module.

Now, don’t set the threshold to, say, 95 %. Keep it somewhat low. Also, be consistent but not a fundamentalist.

Also, make test coverage a part of your daily communication. Create refactoring tickets whose definition of done specifies code coverage gains. Always give a status report on the project’s code coverage, and publicly praise those who did work to increase code coverage.