Russia is currently placing Russian citizens in the occupied parts of Ukraine exactly for this reason. If there will ever be a vote whether the Donbas Oblast or the Luhansk Oblast want to rejoin Ukraine, you can bet the vote will be pro Russia.
Same in Germany, although the employer can forbid this but needs to do this explicitly. Most employers don't forbid personal data on work machines or using your work email for personal things.
It also has something to do with the so called "Hackerparagraph" [1] under which whitehat hacking is basically impossible in Germany. Even writing a program that could potentially be used for hacking is a crime. If you followed the law word for word the authors of e.g. curl could be charged under this law.
> If you followed the law word for word the authors of e.g. curl could be charged under this law.
They really couldn't. BVerfG (Germany's constitutional court) has clearly said that dual use tools have a presumption of not being tools to break the law. It's been very clear that mens rea matters. And that a narrow reading of the law is the only constitutional reading.
The problem here is taking "word for word" as "by dictionary meaning", which is never how laws are read.
It's still a problematic law (together with §202a/b) because it doesn't clearly carve out space for grey-hat activities (white-hat attacks with authorization really don't fall under it even with creative reading).
On the upside, Germany is considering fixing that. On the downside, it moves with the speed of classic German bureaucracy and is being "discussed" since 2024.
> The problem here is taking "word for word" as "by dictionary meaning", which is never how laws are read.
Back in the days of "smart contracts" and "DAOS" this was something many well-meaning technical people struggeled with. Humans and their societies are flexible and therefore laws must be flexible as well (to a certain degree before it becomes damaging).
It's also why a lawyer/expert is usually recommended when engaged with legal matters: We as layman lack all the context around seemingly "simple" concepts, procedures and definitions. You can learn all of that or hire a professional.
Isn’t that by design so governments can prosecute citizens they don’t like? For example, curl is probably ok but that one annoying Kim Dotcom guy is probably going to catch a case under some dubious law.
The pirate bay case, one of the laws cited by the judges was an law written to target biker bars and their owners. It only takes a bit of creative work to bend laws and prior cases to match an already made conclusion, if that conclusion has enough political support.
In that way, I don't really think the government need to design laws to have loop holes in them. With enough political pressure they can get the judges to make any decision they like.
> some countries find such creative ways to stifle innovation while they look to be caring about safety or what not
I'm not sure white-hat hacking is broadly compatible with German culture. Keep in mind that going bankrupt in Germany permanently closes off lots of avenues, from future lending to whether you can be in senior management at a public company.
Bankruptcy does not usually permanently bar you from loans or holding senior management position, there are temporary restrictions, unless grossly negligent. But your point still stands I guess, when compared to the US
Not illegal per se in Germany but you won't find a legal job that doesn't require you to have a bank account. Benefits will also only be paid electronically (exceptions for some asylum seekers apply).
You also cannot get a tax refund or pay taxes without a bank account.
The comments explain the nuance there pretty well:
> This study had 16 participants, with a mix of previous exposure to AI tools - 56% of them had never used Cursor before, and the study was mainly about Cursor.
> My intuition here is that this study mainly demonstrated that the learning curve on AI-assisted development is high enough that asking developers to bake it into their existing workflows reduces their performance while they climb that learing curve.
Giving people a tool, that have no experience with it, and expecting them to be productive feels... odd?
That's a good point. Myself is the easiest person to fool.
I knocked together a quick analysis of my commit graphs going back several years, if you're interested: https://mccormick.cx/gh/
My average leading up to 2023 was around 2k commits per year. 2023 I started using ChatGPT and I hit my highest commits so far that year at 2,600. 2024 I moved to a different country, which broke my productivity. I started using aider at the end of 2024 and in 2025 I again hit my highest commits ever at 2,900. This year is looking pretty solid.
From this it looks to me like I'm at least 1.4x more productive than before.
As a freelancer I have to track issues closed and hours pretty closely so I can give estimates and updates to clients. My baseline was always "two issues closed per working day". These are issues I create myself (full stack, self-managed freelancer) so the average granularity has stayed roughly constant.
This morning I closed 8 issues on a client project. I estimate I am averaging around 4 issues per working day these days. I know this because I have to actually close the issues each day. So on that metric my productivity has roughly doubled.
I believe those studies for sure. I think there is nuance to using these tools well, and I think a lot of people are going backwards and introducing more bugs than progress through vibe coding. I do not think I have gone backwards, and the metrics I have available seem to agree with that assessment.
Love your approach and that you actually have "before vs. after" numbers to back it up!
I personally also use AI in a similar way, strongly guiding it instead of vibe-coding. It reduces frustration because it surely "types" faster and better than me, including figuring out some syntax nuances.
But often I jump in and do some parts by myself. Either "starting" something (creating a directory, file, method etc.) to let the LLM fill in the "boring" parts, or "finishing" something by me filling in the "important" parts (like business logic etc.).
I think it's way easier to retain authorship and codebase understanding this way, and it's more fun as well (for me).
But in the industry right now there is a heavy push for "vibe coding".
Vibrations are surely an issue with electromechanical systems but hardly with electronics. There are plenty of cheap electronic accessories for cars and you can observe that those keep functioning for years.
Since .NET 10 still doesn't support Type Libraries quite a few new Windows projects must be written in .NET Framework.
Microsoft sadly doesn't prioritize this so this might still be the case for a couple of years.
One thing I credit MS for is that they make it very easy to use modern C# features in .NET Framework. You can easily write new Framework assemblies with a lot of C# 14 features. You can also add a few interfaces and get most of it working (although not optimized by the CLR, e.g. Span). For an example see this project: https://www.nuget.org/packages/PolySharp/
It's also easy to target multiple framework with the same code, so you can write libraries that work in .NET programs and .NET Framework programs.
Most likely never will, because WinRT is the future and WinRT has replaced type libraries with .NET metadata. At least from MS point of view.
The current solution is to use the CLI tools just like C++.
However have you looked into ComWrappers introduced in .NET 8, with later improvements?
I still see VB 6 and Delphi as the best development experience for COM, in .NET it wasn't never that great, there are full books about doing COM in .NET.
That's not correct. You don't have to give your credit card details or even be logged in but you are still required to have any Visual Studio license. For hobbyists and startups the VS Community license is enough but larger companies need a VS Professional license even for the VS Build Tools.
How strict Microsoft is with enforcement of this license is another story.
You do not need a Professional or Enterprise license to use the Visual Studio Build Tools:
> Previously, if the application you were developing was not OSS, installing VSBT was permitted only if you had a valid Visual Studio license (e.g., Visual Studio Community or higher).
The license doesn't actually permit OSS development. Only compilation of near-unmodified third party OSS libraries.
You may not compile OSS software developed by your own organisation.
The OSS software must be unmodified, "except, and only to the extent, minor modifications are necessary so that the Open Source Dependencies can be compiled and built with the software."
Using VS build tools for open source development is covered by the Community licence [0], separate from this Build Tools licence change. That license is more open than you might expect, working as an individual it even permits proprietary development for commercial purposes.
Under that usage, the Community license counts as a valid Visual Studio license for Build Tools purposes, hence the second paragraph:
> This change expands user rights to the Build Tools and does not limit the existing Visual Studio Community license provisions around Open-Source development. If you already are a developer contributing to OSS projects, you can continue to use Visual Studio and Visual Studio Build Tools together for free, just like before.
That just confirms the parent comment's point. If you're just using the build tools directly, you're fine. If need to develop "with Visual Studio" i.e. the IDE, not just the command line tools, then you need the paid license.
It's actually not. It's complicated, but they're explicitly allowing Build Tools to be used to compile open source dependencies of closed source projects that do not need the MSVC toolchain for proprietary components.
It's why the example they give in the article is a Node.js application with native open source dependencies (e.g. sqlite3).
EDIT: it's clearer when read in context of the opening paragraph:
> Visual Studio Build Tools (VSBT) can now be used for compiling open-source C++ dependencies from source without requiring a Visual Studio license, even when you are working for an enterprise on a commercial or closed-source project.
I wish the post was clearer (though I'm not sure what that looks like). I've made the same mistake interpreting it, then had to go back and reread it a few times.
Well, let's say this is the world view of all companies about open-source software. Then what happens. If people "tend to not give crap" about licenses, all the nice guarantees of GPL etc also disappear.
GPL was made in response to restrictive commercial licensing. Yes is uses the same legal document (a license): but is made in response!
So is propriety seizes to exist, then it's not a problem GPL also seizes to exist.
Also: it's quite obvious to me that IP-law nowadays too much. It may have been a good idea at first, but now it's a monster (and people seem to die because of it: Aaron Swartz and Suchir Balaji come to mind).
There are zero guarantees and commercial software uses GPLd software as parts of their products all the time. Licenses do not work and you shouldn't respect them whenever you can.
https://github.com/microsoft/terminal
reply