But there is no such thing as original sin. Technology is a tool. What matters is what we do with it.

The critical insight in the Oz analogy is that roughly half of any real workflow that is non-agentic carries no lab advantage. They are no better than you are at writing the deterministic software underneath the model layer.

However, production-grade software requires strict adherence to structural constraints, such as architectural patterns, databases, and object-relational mappings.

software engineering tasks which may take humans weeks seem to be within reach for AI systems.

Still, the psychologist argues, “there’s no longer an excuse for releasing models that reinforce user delusions so readily.” “When one lab’s models can largely maintain safety across extended conversations, while others are willing to validate extremely harmful outcomes — up to and including a user’s suicidal ideation — it suggests this isn’t a flaw in the technology,” said Nicholls, “but a result of specific engineering and alignment choices.”

Our early versions of agentic work was only asking Codex to implement the task. That approach proved too limiting. Codex is perfectly capable of creating multiple PRs as well as reading review feedback and addressing it.

AI writes the code. Tests verify correctness. More code enables more features.

On the SWE-Pro benchmark, M2.7 scores 56.22%, nearly matching Opus's best level.

M2.7 demonstrates excellent performance in real-world software engineering, including end-to-end project delivery, log analysis for bug hunting, code security, and machine learning tasks.

On the SWE-Pro benchmark, M2.7 scores 56.22%, nearly matching Opus's best level.

Claude Opus 4.6 autonomously reimplemented a 16,000-line bioinformatics toolkit — a task we believe would take a human engineer weeks.

GLM-5.1 achieves state-of-the-art performance on SWE-Bench Pro and leads GLM-5 by a wide margin on NL2Repo (repo generation) and Terminal-Bench 2.0 (real-world terminal tasks).

Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.

Looking under the hood is cheating. You're only supposed to have vague conversations with the machine about what it's doing.

There is a tremendous power in thinking about everything as a single kind of thing, because then you don’t have to juggle lots of different ideas about different kinds of things; you can just think about your problem.

Getting hooked on computers is easy—almost anybody can make a program work, just as almost anybody can nail two pieces of wood together in a few tries. The trouble is that the market for two pieces of wood nailed together—inexpertly—is fairly small outside of the "proud grandfather" segment, and getting from there to a decent set of chairs or fitted cupboards takes talent, practice, and education.

the Peter Principle, the idea that in an organization where promotion is based on achievement, success, and merit, that organization's members will eventually be promoted beyond their level of ability

This is not a discrete project but an ongoing process and should always be competing for focus in strategic decision making.

By jumping into unfamiliar areas of code, even if you do not "solve" the bug, you can learn new areas of the code, tricks for getting up to speed quickly, and debugging techniques.

Thinking about how you will observe whether things are working correctly or not ahead of time can also have a big impact on the quality of the code you write.

Platform engineering is trying to deliver the self-service tools teams want to consume to rapidly deploy all components of software. While it may sound like a TypeScript developer would feel more empowered by writing their infrastructure in TypeScript, the reality is that it’s a significant undertaking to learn to use these tools properly when all one wants to do is create or modify a few resources for their project. This is also a common source of technical debt and fragility. Most users will probably learn the minimal amount they need to in order to make progress in their project, and oftentimes this may not be the best solution for the longevity of a codebase. These tools are straddling an awkward line that is optimized for no-one. Traditional DevOps are not software engineers and software engineers are not DevOps. By making infrastructure a software engineering problem, it puts all parties in an unfamiliar position. I am not saying no-one is capable of using these tools well. The DevOps and software engineers I’ve worked with are more than capable. This is a matter of attention. If you look at what a DevOps engineer has to deal with day-in and day-out, the nuances of TypeScript or Go will take a backseat. And conversely, the nuances of, for example, a VPC will take a backseat to a software engineer delivering a new feature. The gap that the AWS CDK and Pulumi try to bridge is not optimized for anyone and this is how we get bugs, and more dangerously, security holes.

Deploy engines as separate app instances and have them only communicate over network boundaries. This is something we’re starting to do more.

While you might think that pairing less experienced engineers is a waste of time, every single time I had a less experienced engineer work by themselves, I ended up regretting it.

The major benefit of foreign keys is that they guarantee referential integrity. For example, say you have customers in one table that may refer to a number of invoices in another. Without foreign keys, you could delete a customer, but forget to remove its invoices, thereby leaving a bunch of orphaned invoices that reference an customer that’s gone.

If an operator ever queries the database directly they’re even more likely to forget deleted_at because normally the ORM does the work for them.

When a product manager trusts that the engineers on the team have the interest of the product at heart, they also trust the engineer’s judgment when adding technical tasks to the backlog and prioritizing them. This enables the balanced mix of feature and technical work that we’re aiming for.

Coordination: More environments require more coordination. Teams need to track which feature is deployed to which environment. Bugs need to be associated with environments. Every environment represents a particular ‘state’ of the codebase, and this has to be tracked somewhere to make sure that customers & stakeholders are seeing the right things;

Sorry you’re surprised. Issues are filed at about a rate of 1 per day against GLib. Merge requests at a rate of about 1 per 2 days. Each issue or merge request takes a minimum of about 30 minutes (across at least 2 people) to analyse, put together a fix, test it, review it, fix it, review it and merge it. I’d estimate the average is closer to 3 hours than 30 minutes. Even at the fastest rate, it would take 3 working months to clear the backlog of ~1000 issues. I get a small proportion of my working time to spend on GLib (not full time).

“Functional programming language” is not a clearly defined term. From the various properties that are typically associated with functional programming I only want to focus on one: “Immutability” and referential transparency.

One of the primary tasks of engineers is to minimize complexity. JSX changes such a fundamental part (syntax and semantics of the language) that the complexity bubbles up to everything it touches. Pretty much every pipeline tool I've had to work with has become far more complex than necessary because of JSX. It affects AST parsers, it affects linters, it affects code coverage, it affects build systems. That tons and tons of additional code that I now need to wade through and mentally parse and ignore whenever I need to debug or want to contribute to a library that adds JSX support.

An Idiom is a low-level pattern specific to a programming language. An idiom describes how to implement particular aspects of components or the relationships between them using the features of the given language.

A Design Pattern provides a scheme for refining the subsystems or components of a software system, or the relationships between them. It describes a commonly recurring structure of communicating components that solves a general design problem within a particular context.

Building blocks are what you use: patterns can tell you how you use them, when, why, and what trade-offs you have to make in doing so.

patterns are considered to be a way of putting building blocks into context

A "pattern" has been defined as: "an idea that has been useful in one practical context and will probably be useful in others"

INVEST

As such, scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to deliver quickly, to respond to emerging requirements and to adapt to evolving technologies and changes in market conditions.

the study of innovation shows that everything hinges on the hard work of taking a promising idea and making it work — technically, legally, financially, culturally, ecologically. Constraints are great enablers of innovation.

But there’s a downside to the hackathon hype, and our research on designing workplace projects for innovation and learning reveals why. Innovation is usually a lurching journey of discovery and problem solving. Innovation is an iterative, often slow-moving process that requires patience and discipline. Hackathons, with their feverish pace, lack of parameters and winner-take-all culture, discourage this process. We could find few examples of hackathons that have directly led to market success.

what if projects were designed to combine a hacking mindset with rigorous examination of the data and experience they glean? This would reward smart failures that reveal new insights and equip leaders with the information needed to rescale, pivot or axe their projects.