I know this section is really just a comparrison of pyproject.toml and cargo.toml, but who on earth would use pip instead of UV as a drop-in replacement in 2026? Though calling it a comparrison is a bit of a stretch considering there is no text.
On top of that, I imagine that a lot of Python programmers who actually do use pip would also use requirements.txt and not pyproject.toml
Because it's rust for python dev, not rust for python dev who use uv. I would understand your comment if you mentioned poetry, but pip has been the standard for years
People learning Python or searching for it will run into endless answers using PIP. Then, lots of advice on how to work around PIP's problems. Then, multiple alternatives they have to consider. I only recently started using UV after going through all that.
Packaging, concurrency, and type errors had me strongly considering switching to Go or Rust recently. These are such long-solved problems in other languages that I question why we should put up with it in Python. Then, I remember it was the ecosytem, including job market and AI performance, that made me use Python.
So, maybe a Python/Rust combo... There's the extensions the OP article mentioned and a Python interpreter written in Rust.
I heard that Zed came with a lot of integrated AI and team sharing features that phone home, so that's an issue for anyone working with stuff like NIS2 compliance. Not that VSCode isn't a compliance nightmare as well.
Nice find. We're PoCing Cowork and I've personally been impressed with it so far, but it seems we'll have to wait with a wider rollout until Microoft give us more admin feature to turn off what users can do with it.
> Note: Admins have limited oversight of ‘Skills’, as Skills in Copilot Cowork are automatically loaded from a specific path in a user’s OneDrive.
I feel this part is a bit disingenuous. We have full control over the sharepoint containers which house users personal onedrives. We actively scan them and prevent a lot of files from getting in them. That being said, it's still a fair point, because a "skill" could basically be a text file.
I think few people would want to use an ORM for the stuff you use Go for, but there are things like SQLC which can generate a lot of your "dynamic DB magic" without actually being a real dependency. You can set SQLC up to run in a container in a completely isolated environment, and then use the output, but you can frankly also just maintain the SQL which frankly isn't that different than using an ORM once you've set up the automation with ridicilously strict policies.
We use Go for some of our more vital backend parts. We mainly use Python for entirely different reasons, but since we're an energy company it's nice to have a standard library that can do everything without any sort of external dependencies. It's not because we have some sort of "not invented here" fetish, it's because we have to write and maintain a literal fuckton of complaince documents for every external dependency we use and it's already a full time job for just for Python in our information security department.
Maybe it's just Microsoft moving to more model agnostic tech within their copilot. I recently started using Microsoft 365 Copilot because corporate added Cowork which runs on Opus 4.7 which was better than the alternative we have available. Unlike the "real" Claude Code or Cowork this only has access to files in a specific onedrive folder in your personal sharepoint container, so it's much more compliant to things like NIS2.
Technically we're using Copilot and we're playing for it through Microsoft licenses, but it's using Opus 4.7. Even before this, most of our custom agents within m365 copilot were one of the GPT models.
Or maybe you're right and they want their developers to use the copilot models.
I really dislike that I can't customize it with permanent config files, similar to how I can configure a regular GPT model agen. I guess it's probably because it's in the fancy word they use for "beta".
I haven't really used any other Copilot product in a while since they were so bad compared to our other corporate options, but I'm rather impressed with Cowork inside it. Exactly because we can actually use it without breaking any EU laws.
Around here C# is only really used at stagnant middle sized companies with horrible code bases. The sort where the company follow Uncle Bob religiously, while completely misunderstanding everything Uncle Bob ever said. Doesn't mean the language (and it's runtime) can't be good.
The examples in Clean Code show that Uncle Bob himself misunderstood heuristics as strict rules that are to be taken to the extreme. There's nothing to not misunderstand.
Yes, many people instinctively stay away from anything microsoft (except github, typescript and npm). But the stack is solid. I’m always reminded of Stack Overflow and how they built on asp.net and like 7 servers and it scaled very well for years.
Everyone has what they like and what they’re familiar with, and for better or worse, especially for startups it’s rarely .net. But I couldn’t imagine e.g. using js instead on the back end, but that’s just me.
I'm Danish so maybe that's part of it, but if I'm looking for something like kid's lunch boxes that aren't essentially from Temu resale sites I was already using LLM chat clients to find it.
I can search for google and find nothing, or I can use a non-login on chatgpt and get several options. It found me some French made lunchboxes that are being made by a car company (I think it was renault but I honestly can't remember) while every result on google was basically temu resales by "companies" that were basically registered to some private adress here in Denmark. I guess I'm an early adopter, and I'm sure LLM's will be ruined by advertising and hidden algorithms, but right now, I really don't see the point of traditional search engines.
LLM search will be ruined the exactly same way, just faster. Google search used to be good, until the company concluded they will earn more money by making it crap. Then it took some time for it to get worst, bit by bit.
With LLM, the same company will learn from previous experience and make it worst faster. It is exactly the same company, making exactly the same product (search), with exactly the same management and being subject of exactly the same market forces.
The result will be exactly the same, they will just get there faster.
I doubt it'll be ruined the same way. It's already got features traditional search engines never really did for us in Europe. Every search engine will assume that I want to buy things from websites that are either in Danish or in English and even if I try to configure something like Google to understand that I'd rather buy from Germany or France than the UK it just doesn't seem to get it. With LLM's I can search for shops on all sorts of EU websites, which comes in rather handy when you're buying vintage blood bowl things since there are a lot of local "ebays" in Spain, Italy and similar that I'd never find without them.
I have no doubt that Renault could pay ChatGPT to get it to recommend people buying lunch boxes. For all I know there might be a bunch of eco friendly "European produced" lunch boxes with compartments and the LLM recommended me the three which fit the needs I described because those companies paid for it. I didn't find any of them on Google though, that was all Temu resales.
I think Claude Cowork through the Microsoft thing which was copilot but is now named M365 (or something?) is likely creating every powerpoint resentation within our organisation at this point.
We have whatever AI is in teams transcribe every meeting, and it's scaringly good at it. It's also extremely good at sumerizing or finding things from pervious meetings when tasked. One disadvantage in this, is that I can see how stupid I sound on writing. I'll go "yeah, hmm, yeah, that's, yeah", but it really is pretty good.
I assume we're going to see a massive increase in AI with this Cowork inside the Microsoft client. We actually have a better tool available through a librechat where you can create and configure your own agents with the same filesystem access to your one drive, and a lot more tools and models than just Claude. Almost nobody has been capable of figuring out how to use it though, so they've been using the regular office365 copilot and it sucks so bad that a lot of people stopped beliving in AI.
It's ironic that Microsoft fumbling the ball on AI, but being very good at enterprise customers (especially non-IT) means that they'll likely be the company which is going to sell us AI tools that people will actually use. I have no idea why it's so hard for people to pick up the Librechat tool we're given access to through our equity fund. It's quite litterally a copy of ChatGPT where you can point-and-click configure an agent, but we're seeing that even employees who use a lot of ChatGPT privately don't use this tool professionally. Meanwhile everyone has been capable of using the Microsoft thing (that I personally think is less user friendly since you will need to add your configuration files to every promt).
"I have no idea why it's so hard for people to pick up the Librechat tool we're given access to through our equity fund"
That's because M365 is integrated with the whole Office/Exchange environment, especially in terms of security policies, etc. MS also guarantee that the data are private, this is very important for many companies both from the IP protection perspective and the liability to expose some users/customers data (think of GDPR regulations is Europe).
I don't know who is behind Liberchat, probably some good and friendly folks, but when it comes to privacy/security Microsoft has much more to loose and if shit happens it is easier to sue them than some random VC-financed company from the USA.
We've got a rather extensive AI setup through our equity fund and I've setup a group of agents for data architecture at scale. One is the main agent I discuss with and it's setup to know our infrastructure and has access to image generation tools, websearch, hand off agents and other things. I tend to use Opus (4-6 currently) and I find it to be rather great. As you point out it comes with the danger of making mistakes, and again, as you point out, it's not an issue for things I'm an expert on. What I rely on it for, however, is analysing how specific tools would fit into our architecture. In the past you would likely have hired a group of consultants to do this research, but now you can have an AI agent tell you what the advantages and disadvantages of Microsoft Fabric in your setup. Since I don't know the capabilities of Fabric I can't tell if the AI gives me the correct analysis of a Lakehouse and a Warehouse (fabric tools).
What I do to mitigate this is that I have fact checking agents configured to be extremely critical and non-biased on Opus, Gemini and GPT. Which are then handed the entire conversation to review it. Then it's handed off to a Opus agent which is setup to assume everything is wrong. After this, and if I'm convinced something is correct I'll hand the entire thing off to a sonnet agent, which is setup to go through the source material and give me a compiled list of exactly what I'll need to verify.
It's ridicilously effective, but I do wonder how it would work with someone who couldn't challenge to analytic agent on domain knowledge it gets wrong. Because despite knowing our architecture and needs, it'll often make conceptional errors in the "science" (I'm not sure what the English word for this is) of data architecture. Each iteration gets better though, and with the image generation tools, "drawing" the architecture for presentations from c-level to nerds is ridiclously easy.
I think it depends on what you mean by repeatable tasks. I reuse the critical handoff agents quite a lot since they are basically just set up to help spot bias and errors. I kind of reuse the top agent. I have a few "core" configurations that I can add to. So one will know our network, one will know our data architecture and so on, to keep them a little more focused. So for this specific agent that I described, I'll add a few lines on what I'm considering to the configuration, that I'll not reuse for anything unrelated to Microsoft Fabric. I've tried using these "core" agent configurations as hand-off agents in the past, but it doesn't seem to work well in our setup which is very isolated because we're NIS2 compliant.
I don't usually go back to the original prompt. I've actually done it a few times in regards to the presentation, to get some refined images but usually I'll start a new prompt.
In my previous jobby job I needed to pull CSVs out of Tableau, then from an ancient monolithic PHP admin and other sources, then manually merge them, reformat them in G Sheets, pivot this and that and send the report to my supervisor. Initially took 2 hours then down to one, but still senseless busy work. It was the “fault” of the incumbent IT, but if I could turn that hour into a minute… I wouldn’t get a raise, but I’d have more time for something else or nothing. I feel like this is still a scenario for countless many and perhaps the valley of the low hanging fruit. That’s where my question was coming from.
Your firm seems to operate on a higher plane, jealous :)
> Any examples how you see some engineers being left behind?
I don't know where you live, but around where I live in Denmark you'd fail for not using AI at a senior interview in a lot of places. Even places which aren't exactly AI fans use AI to some extend.
The biggest challenge we face right now is figuring out how you create developers who have enough experience to know how to use the AI tools in a critical manner. Especially because you're typically given agents for various taks, which are already configured to know how we want things to be written.
Around here on your southern neighbour, everyone is supposed to be doing AI and being evaluated by this, yet in many projects if clients don't sign off on the use of AI tools, there is no AI to use anyway.
Additionally there are the AI targets set by C suites based on what everyone is saying on TV, and what we can actually deliver based on the available data sets, integration points, and naturally those sign offs for data governance, and hallucinations guardrails.
I was just giving them an anecdotal example of what they were asking for. I think the answer is somewhere in the middle, but I'm not in a position to push any form of change on the C levels.
I've noticed that back in Europe everyone's in a panic mode, but that's because of the inferiority complex most people have vs both US and China. It's unwarranted.
I know this section is really just a comparrison of pyproject.toml and cargo.toml, but who on earth would use pip instead of UV as a drop-in replacement in 2026? Though calling it a comparrison is a bit of a stretch considering there is no text.
On top of that, I imagine that a lot of Python programmers who actually do use pip would also use requirements.txt and not pyproject.toml
reply