Windows is in a weird spot. In its 40-year history, the operating system has weathered its fair share of missteps, but Windows 11 is testing the patience of its users in new ways. Persistent bugs, performance issues, intrusive prompts, ads, and bloatware have eroded the core Windows experience. Early system requirement decisions have also damaged trust among Microsoft's most loyal users, an erosion that's accelerated by the company's aggressive push into AI that doesn't always deliver on its promises.
Windows is at breaking point, and Microsoft knows it. Sources familiar with the company's plans tell me Windows engineers are now focusing on …
I wish Microsoft would just do something new. Leave all the compatibility baggage behind, and dream up a new kernel. It's a crime that in 2026 system updates take nearly an hour on some machines. No Linux install ever has that problem.
A new study looks at how current security practices around container use are falling short of helping developers achieve their stated goals. The report from BellSoft surveyed over 400 developers and finds 23 percent report having experienced a security incident. The problem here isn't detection, it's the gap between disclosure and remediation. In this window, which can often be weeks or months, organizations operate with known exposures. When it comes to the cause of problems 62 percent of respondents say human errors are the biggest contributor to container security mistakes. Package managers present a particularly critical security concern, as they… [Continue Reading]
When Andrej Karpathy, former director of AI at Tesla and one of the most influential voices in modern artificial intelligence, casually admitted on X that he now does most of his programming in English rather than code, it struck a nerve.
Not because developers weren’t already sensing this shift, but because he said it, and because he revealed something many wouldn’t openly admit:
It hurts the ego a bit.
This wasn’t just another AI hot take. A top expert openly admitted that software development has changed in a fundamental way. Karpathy was clear:
This is easily the biggest change to my basic coding workflow in 2 decades of programming and it happened over the course of the few weeks.
Karpathy, in his own words
Karpathy explains how, over the course of just a few weeks coding in Claude, his workflow flipped almost entirely. What was once mostly handwritten code is now largely driven by LLMs, guided through natural language.
I really am mostly programming in English now, a bit sheepishly telling the LLM what code to write… in words. It hurts the ego a bit, but the power to operate over software in large “code actions” is just too net useful.
That sentence carries more weight than it first appears. It openly acknowledges the productivity gains while naming the quiet discomfort many developers feel but rarely articulate. Even for Karpathy, something is unsettling about no longer being the one writing the code line by line.
It feels like I’m cheating. Which is a very weird feeling to have. It takes a while to unpack. It’s because some code that used to be a point of pride and high IQ and knowledge is suddenly free and instant and it’s very disorienting.
This shift isn’t about convenience or a slightly better tool. Karpathy describes it as a phase change, not an incremental improvement.
The role of software engineers moves away from writing individual lines of code and toward orchestrating large code actions. LLMs don’t behave like perfect assistants; they act more like eager but sloppy junior developers: fast, capable, and occasionally careless. They don’t ask clarifying questions, they guess. And sometimes they guess wrong.
The result is faster output, but also a different kind of responsibility. Less mechanical, more abstract. Less about syntax, more about judgment.
Community reaction and a bruised identity
The reaction to Karpathy’s post helps explain why it resonated so widely. Some developers see this evolution as liberating, with fewer repetitive tasks, more leverage, and more time spent on meaningful problem-solving. Others see something more troubling: a slow erosion of the craft that shaped their professional identity.
A familiar split emerges: on one side are builders who embrace orchestration, prompting, and verification, on the other are developers who feel that if they’re not writing code, they’re not really programming anymore.
That tension is emotional, not technical. Programming has never been just a job. For many, it’s a source of pride. When that pride is challenged, even by efficiency, it stings.
I let Claude Code turn @karpathy's post into agent skills. It first generated a bunch of skill files and around 800 lines of descriptions.
What makes this moment particularly interesting is that Karpathy hasn’t been blindly optimistic about AI agents. In the past, he’s openly questioned their maturity, arguing that today’s agents are unreliable and far from fully autonomous.
This contrast is important. He’s saying these tools are too useful to ignore, but he’s also clear they’re still messy, fragile, and imperfect. This isn’t hype, it’s real challenges. And challenges are what spark meaningful discussion.
Am I really a developer if I’m not writing code?
This conversation goes beyond the usual AI discourse cycle. If top engineers are moving from writing code to guiding systems, if success is measured by results rather than lines of code, and if pride, not skill, is the main barrier, then something bigger is happening.
We’re not just changing tools, we’re renegotiating what it means to be a developer.
The real question isn’t if this trend will keep going. It’s this: If programming becomes mostly about language, judgment, and style, what happens to being defined by code?
Karpathy’s post doesn’t give answers but shows the tension. Is moving away from manual coding progress or loss? Empowerment or subtle deskilling?
And if top engineers admit it “hurts the ego,” what does that mean for the future of the profession?
By the end of 2025, LLM coding agents reached a level of coherence that triggered a shift in software engineering. Intelligence is now outpacing tools, workflows, and organizational structures. The industry is just starting to catch up, and 2026 is shaping up to be a fast-moving year as development learns to harness this new power.
Sentry connects logs to issues, traces, and session replays Sentry is an application monitoring platform that helps you understand exactly what’s going wrong when your code breaks, and gives you the context you need to fix it fast (we support every major language and framework, including .NET, MAUI, and ASP.NET Core). That means rich debugging context like stack traces, app and device state, and performance data all in one place. Now, with structured logging, you can also send your logs directly to Sentry and see them alongside errors, traces, session replays, and more. You can start sending logs to Sentry today with just a few lines of code.
jQuery UI 1.14.2 has been released. It includes a fix for tabs with unicode characters in tab IDs and adds support for tabs on pages with URL credentials (issue #2344, issue #2213, PR #2345), drops dependency on the jQuery Mousewheel plugin (PR #2338 + PR #2342).
Apart from that, easing demos were fixed (PR #2320) and the test infrastructure has been migrated to jquery-test-runner (PR #2325).
This release has been tested against jQuery 1.12.4, 2.2.4, 3.6.4, 3.7.1 & 4.0.0. Since jQuery follows semver, newer jQuery <5 versions within each major version line should generally work as well.
jQuery UI 1.14.2 triggers no jQuery Migrate messages except for its initialization one when running its test suite against jQuery 4.0.0 with jQuery Migrate 4.0.2 or jQuery 3.7.1 with jQuery Migrate 3.6.0, i.e. the latest versions at the time of this release.
Reminder about maintenance state
Please remember jQuery UI is in a maintenance state: we’ll make sure the library is compatible with new jQuery releases and that security issues are fixed but no new significant feature work is planned. We’ll also try to fix important regressions from jQuery UI 1.12.1 or newer; older long-standing bugs may not get fixed. Note that this does not affect jQuery Core which is still actively maintained.
See the 1.14 Upgrade Guide for a list of changes that may affect you when upgrading from 1.13.x. For full details on what’s included in this release see the 1.14.2 Changelog.
Thanks
Thanks to all who helped with this release, specifically: Michał Gołębiowski-Owczarek, Timmy Willison & Felix Nagel.
Log in
