# Thomas Young Upcoder blog posts This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## The Alignment Trap: AI Safety as Path to Power DevFeed: [The Alignment Trap: AI Safety as Path to Power]() Original publisher: [Read original article]() Published: 2024-10-27T12:25:00Z Content type: opinion Language: en Sources: [Thomas Young]() Topics: [Artificial Intelligence](), [ai safety](), [Responsibility & Safety](), [trust]() Tags: [ai](), [ai-safety](), [alignment](), [networks](), [process](), [safety](), [surveillance](), [systems](), [trust]() ### AI overview The article argues that AI safety measures designed to make systems controllable and aligned with human values could also give governments, corporations, or other powerful organizations more effective tools for concentrating power. It compares AI-enabled control with historical limits on dictatorship, including unreliable loyalty, information distortion, cognitive constraints, and administrative friction. ### Source excerpt Recent discussions about artificial intelligence safety have focused heavily on ensuring AI systems remain under human control. While this goal seems laudable on its surface, we should carefully examine whether some proposed safety measures could paradoxically enable rather than prevent dangerous concentrations of power. The Control Paradox The fundamental tension lies in how we define "safety." Many current approaches to AI safety focus on making AI systems more controllable and aligned with human values. But this raises a critical question: controllable by whom, and aligned with whose values? When we develop mechanisms to control AI systems, we are essentially creating tools that could be used by any sufficiently powerful entity - whether that's a government, corporation, or other organization. The very features that make an AI system "safe" in terms of human control could make it a more effective instrument of power consolidation. Natural Limits on Human Power Historical examples reveal how human nature itself acts as a brake on totalitarian control. Even the most powerful dictatorships have faced inherent limitations that AI-enhanced systems might easily overcome: The Trust Problem: Stalin's paranoia about potential rivals wasn't irrational - it reflected the real difficulty of ensuring absolute loyalty from human subordinates. Every dictator faces this fundamental challenge: they can never be entirely certain of their underlings' true thoughts and loyalties. Information Flow: The East German Stasi, despite maintaining one of history's most extensive surveillance networks, still relied on human informants who could be unreliable, make mistakes, or even switch allegiances. Human networks inherently leak and distort information. Cognitive Limitations: Hitler's micromanagement of military operations often led to strategic blunders because no human can effectively process and control complex operations at scale. Human dictators must delegate, creating opportunities ## Is There a Power Play Overhang? DevFeed: [Is There a Power Play Overhang?]() Original publisher: [Read original article]() Published: 2024-05-08T09:43:25Z Content type: opinion Language: en Sources: [Thomas Young]() Topics: [Artificial Intelligence](), [Development]() Tags: [agent](), [ai](), [bias]() ### AI overview The post examines risks from increasingly capable AI, focusing on whether adding agent-like abilities could create a sudden increase in the risk of losing control or extinction. It reframes agency overhang as "power play overhang" and argues that people may be too narrowly imagining how dangerous AI could develop. ### Source excerpt This post is about risks in the development of increasingly capable AI, in particular the risk of losing control to AI and extinction risk. I'll suggest that a key question is, "When do we need to take this kind of risk seriously?" We'll look at the issue of 'agency overhang', which suggests that adding agent-like abilities to AI could result in a sudden and surprising increase in these kinds of risks. I'll draw on intuitions about humans taking administrative and political control (with reference to the 'Dictator Book Club') and rephrase agency overhang as 'power play overhang'. I'll finish by suggesting that a lot of people may be making a subtle but important mistake in imagining just one fairly specific path to dangerous AI. Normalcy Bias From Wikipedia: Normalcy bias, or normality bias, is a cognitive bias which leads people to disbelieve or minimize threat warnings. Examples cited there include failure to react to natural disasters such as a tsunami or a volcanic eruption. In terms of effects: About 80% of people reportedly display normalcy bias in disasters.[3] Normalcy bias has been described as "one of the most dangerous biases we have". They can't do that! There's a powerful cliché, found in many books and films, in which we witness some scene early in the development of a totalitarian regime. In this cliché we see the surprise and disbelief of normal people as the regime begins to tighten its grip. A great example of this is in "The Handmaid's Tale" when, in the early episodes, many characters express disbelief at the rapid changes in society, such as women losing their jobs and bank accounts, saying things like "They can't do that!" as the totalitarian regime takes control. Other examples relate to historical events, such as: "The Lives of Others" Set in 1980s East Germany, this shows how the Stasi (secret police) gradually infiltrates every aspect of citizens' lives. "The Diary of a Young Girl" Anne Frank documents her surprise and disbelief at the in ## C/C++ Include Guidelines DevFeed: [C/C++ Include Guidelines]() Original publisher: [Read original article]() Published: 2019-10-13T12:14:00Z Content type: tutorial Language: en Sources: [Thomas Young]() Topics: [c/c++](), [C](), [C++](), [Code quality](), [Code](), [modules]() Tags: [c](), [c-c-plus-plus](), [c-plus-plus](), [code](), [code-quality](), [compilation](), [dependencies](), [implementation](), [modules](), [source](), [structure]() ### AI overview An opinionated set of guidelines for organizing include files in C and C++. It covers header and source-file responsibilities, include ordering, repeated-include protection, dependencies, namespaces, naming, and related practices, while noting that C++20 modules change the situation. ### Source excerpt Some (opinionated) guidelines for include file organisation in C/C++. Intro I present a list of points, probably best considered as guidelines, but which I'll refer to as rules throughout the rest of this post, since it trips off the tongue that bit more easily (or perhaps I just have some hidden authoritarian streak). I'll assume the reader knows something about writing code in C or C++, and understands at least the basics about how compilation with include files works. Sometimes I'll say things are obvious to this intended audience, where I think this is necessary for completeness. This is about an ideal way to organise code. For large existing code bases changing the code to follow all of the rules may not be straightforward but it should be possible to make some incremental steps towards the code structure I describe, resulting in some kind of incremental improvements in overall code quality. Many of the rules have exceptions, and it can interesting to explore reasons for these exceptions, as well as the reasons for the rules themselves. Modules As an aside, please note that this is a 'pre-modules' document. If you're using c++ 20 and modules the situation will be different. (At the time of writing I don't have any experience working with modules, and I'm not aware of all the details about how modules will work. I'm hoping that if we follow the rules described here, we should be reasonably well placed for moving to C++20 modules, but if that's not the case, and there are module related details that you think should be taken into account in this document, please let me know in the comments.) The rules 1. Headers are for linkage details, implementation goes in source files. 2. Each source file should have a single matching header. 3. Linkage to a source file should go only through its header. 4. Guard against repeated includes. 5. Each header should be self-sufficient. 6. Each source file includes its own header first. 7. Low level includes come after high level i ## Automatic Object Linkage, with Include Graphs DevFeed: [Automatic Object Linkage, with Include Graphs]() Original publisher: [Read original article]() Published: 2018-05-31T13:33:00Z Content type: tutorial Language: en Sources: [Thomas Young]() Topics: [Code](), [C](), [C++](), [Library](), [Graphs](), [Testing]() Tags: [c](), [c-plus-plus](), [code](), [graphs](), [libraries](), [library](), [testing](), [unit-testing]() ### AI overview The article presents a custom build process for sharing C and C++ source code across multiple build targets. It uses include-relationship graphs to determine which object files belong in each link operation, reducing unnecessary dependencies associated with broad static libraries. ### Source excerpt In this post I describe an alternative approach to sharing source code elements between multiple build targets. It's based on a custom build process I implemented at PathEngine for our C and C++ code-base (but the core ideas could also be relevant to other languages with compilation to object files). We'll need to enforce some constraints on the way the source code is set up, notably with regards to header file organisation, but can then automatically determine what to include in the link operation for each build target, based on a graph of include relationships extracted from the source files. The resulting dynamic, fine grained, object-file centric approach to code sharing avoids the need for problematic static library decomposition, and the associated 'false dependencies'. Motivation We need to work with a bunch of different build targets, at PathEngine. There's a run-time pathfinding dll, for example, but also a 3D content processing dll, a 3D testbed application, and so on, with a lot of source code shared between these different targets. The code was originally split into a set of (internal) static libraries, for this purpose. based on things like theme (e.g. 'Geometry.lib') or application layer ('PathEngine_Core.lib', 'PathEngine_Interface.lib'). Different targets could then share common source code by sharing these static libraries. This worked, as far as it goes, but something didn't feel right. The libraries weren't particularly modular, for one thing, and just felt like big old bags of object files that didn't really reflect the actual structure of the underlying code. A bigger problem was that, for any kind of prototyping work, I ended up having to link in a big chunk of the PathEngine source code, even where only some small part of this was really required. Unit testing was also difficult to setup, for a similar reason. Since throwing out the static libraries and switching to an alternative approach (as described in this post), prototyping and unit test ## Static Libs Do Not Modular Make DevFeed: [Static Libs Do Not Modular Make]() Original publisher: [Read original article]() Published: 2017-09-23T13:12:00Z Content type: article Language: en Sources: [Thomas Young]() Topics: [Library](), [modules](), [C](), [C++](), [implementation](), [Software]() Tags: [build](), [c](), [c-plus-plus](), [dependencies](), [libraries](), [modules]() ### AI overview The article argues that splitting C/C++ source files into statically linked libraries does little by itself to improve modularity and can significantly increase dependencies. It discusses organizing code into libraries, defining interfaces, and hiding implementation details as additional aspects of modular design. ### Source excerpt A cautionary tale about statically-linked libraries, as generated by C/C++ build tools. As a project accumulates features, and complexity, it gets harder to understand exactly what's going on, and to find your way around the source code. You need to find some way to organise the code and try and keep things manageable. A common idea, in this situation, is to group some source files together to split out as a static library. I'm going to argue that this actually does very little, in itself, to increase modularity, can have the effect of significantly increasing dependencies, and is maybe not such a good idea, after all. Break it apart? So yeah, when something gets too big to work with, it makes sense to try to break it into pieces. Given a whole bunch of source files to work with, we probably want 'pieces' bigger than individual source files, and that means grouping source files together. Perhaps there are files that can be grouped together by theme (e.g. a bunch of source files related to 'geometry'). Or perhaps some kind of layered decomposition is possible (e.g. we can identify a bunch of 'core' source files). And then we can separate this group of files from the rest of our source code by putting them in a library. Making things modular Wiktionary defines 'modular' as follows: Consisting of separate modules; especially where each module performs or fulfills some specified function and could be replaced by a similar module for the same function, independently of the other modules. Libraries are a classic archetype for a software module, and splitting our code into libraries already kind of nails the first part of that, (the bit before the semicolon), right? The bit after the semicolon is probably also worth consideration, but we can tweak the code to better address this bit, incrementally, later on, by firming up the interface, hiding implementation details, and so on. Having our source code 'consisting of modules' already feels like a good start, and a step in th