My dad was an old-school architect. When AutoCAD replaced the drafting table—the ink, the ruler, the set square, the protractor—he thought it was crap, because now any total hack at drawing could do it.
For me, on the other hand, AutoCAD was amazing, because with AutoLISP you could draw with words. And now, with the LLM boom, I finally get him.
They absolutely do, the CEO has come out and said a few engineers have told him that they dont even write code by hand anymore. To some people that sounds horrifying, but a good engineer would not just take code blindly, they would read it and refine it using Claude, while still saving hundreds of man hours.
> They absolutely do, the CEO has come out and said a few engineers have told him that they dont even write code by hand anymore. To some people that sounds horrifying, but a good engineer would not just take code blindly, they would read it and refine it using Claude, while still saving hundreds of man hours.
TBH, that isn't sustainable. Skills atrophy. At some point they are going take the code blindly.
Considering what they have said in the past about agentic code changes, they are already doing just that - blindly approving code from the agent. I say this because when I last read what one of their engineers on CC tweeted/posted/whatever, I thought to myself "No human can review that many lines of code per month"[1].
---------
[1] IIRC, it was something stupid like 30kLoc reviewed in a month by a single engineer.
I keep telling my friends while experienced devs feel extremely productive. The newer ones will likely not develop skills needed to work with finer aspects of code.
This might work for a while, but you do a year or two of this, and then as little as a small Python script will feel like yak shaving.
I would love to hear/see a definitive answer for this, but I read somewhere that the relationship between MS and \A is such that the copilot version of the \A models has a smaller context window than through CC.
This would explain the "secret sauce", if it's true. But perhaps it's not and a lot is LLM nondeterminism mixing with human confirmation bias.
Agreed. I was an early adopter of Claude Code. And at work we only had Copilot. But the Copilit CLI isn't too bad now. you've got slash commands for Agents.MD and skills.md files now for controlling your context, and access to Sonnet & Opus 4.5.
Maybe Microsoft is just using it internally, to finish copying the rest of the features from Claude Code.
Much like the article states, I use Claude Code beyond just it's coding capabilities....
Same situation, once I discovered the CLI and got it set up, my happiness went up a lot. It's pretty good, for my purposes at work it's probably as good as Claude Code.
I'm amazed that a company that's supposedly one of the big AI stocks seemingly won't spare a single QA position for a major development tool. It really validates Claude's CLI-first approach.
> Zig where I used to use C/Rust (but admittedly I spent the least time here).
I really don't understand how that fit with the “I want something that allows me to focus my mental facilities on the complexities of the actual problem domain”.
For low-level stuff, Rust allows to offload the cognitive load of maintaining the ownership requirements to the machine. On the opposite, Zig is exactly like C as it forces you to think about it all the time or you just shoot yourself in the foot at the first opportunity…
For stuff that can be done with managed languages, then absolutely, the GC allows to completely ignore that aspect, at the cost of some performance you don't always care about because how fast the modern hardware is.
What is the difference between Kuberesolver and using a Headless Service?
In the README.md file, they compare it with a ClusterIP service, but not with a Headless on "ClusterIP: None".
The advantages of using Kuberesolver are that you do not need to change DNS refresh and cache settings. However, I think this is preferable to the application calling the Kubernetes API.
I can give an n=1 anecdote here: the dns resolver used to have hard-coded caching which meant that it would be unresponsive to pod updates, and cause mini 30s outages.
That meant that deploying a service which drained in less than 30s would have a little mini-outage for that service until the in-process DNS cache expired, with of course no way to configure it.
Kuberesolver streams updates, and thus lets clients talk to new pods almost immediately.
I think things are a little better now, but based on my reading of https://github.com/grpc/grpc/issues/12295, it looks like the dns resolver still might not resolve new pod names quickly in some cases.
