+1

Artificial Intelligence Models.md

reviewed

··· 100 100 - An good (updated) sense of estimation. 101 101 - Build "partial autonomy" products where humans stay in the loop to verify output, rather than fully autonomous agents. 102 102 - [If you need to gather context, do that first in its own session](https://mariozechner.at/posts/2025-11-30-pi-coding-agent). Create an artifact that you can later use in a fresh session to give your agent all the context it needs without polluting its context window with tool outputs. 103 103 + - In a world of abundant, near-unlimited coding capacity, human taste becomes most of the game. 103 104 104 105 ## Agents 105 106

+2

Programming.md

reviewed

··· 25 25 - Reuse [patterns](https://www.digitalocean.com/community/tutorials/gangs-of-four-gof-design-patterns). 26 26 - The number of moving pieces on average doubles every 18-24 months. No one fully understands [[Systems]]. 27 27 - [There are different notions of simplicity](https://vitalik.eth.limo/general/2018/11/25/central_planning.html) (Kolmogorov complexity vs VC Dimension). What is "simple" to describe or appears to have few knobs in one language for describing it is devilishly complex in another, and vice versa. 28 28 + - Most performance wins come from removing work, not adding cleverness. 28 29 - [Good taste is writing code that looks so simple, everyone else says "anyone could have written that!"](https://news.ycombinator.com/item?id=45411143) 29 30 - **Do one thing and do it well**. 30 31 - By focusing on a single task, a program or function can eliminate much extraneous code that often results in excess overhead, unnecessary complexity, and a lack of flexibility. [Good software makes hard things easy](https://medium.com/s/story/notes-to-myself-on-software-engineering-c890f16f4e4d). ··· 34 35 - Once you have a working prototype, apply guidelines and previous learnings. Then, focus on performance. 35 36 - There is nothing so useless as doing efficiently that which should not be done at all. 36 37 - Writing program code is a good way of debugging your thinking. 38 38 + - [You can edit a bad page, but you can't edit a blank one.](https://addyosmani.com/blog/21-lessons/) 37 39 - Apply small improvements at each iteration. Running the program will make it more resilient and robust as more errors get fixed. 38 40 - Premature optimization is the root of all evil. Abstraction is a form of optimization and shouldn't be done before the space has been properly explored to know what abstractions should be built. Standardization is a form of optimization and shouldn't be proposed until there's a body of evidence to support what's being standardized. 39 41 - [Increased efficiency can sometimes, counterintuitively, lead to worse outcomes](https://sohl-dickstein.github.io/2022/11/06/strong-Goodhart.html).

+1

Teamwork.md

reviewed

··· 43 43 - Things you haven't built yet. 44 44 - Things you shouldn't have built that way. 45 45 - Accidental complexity is a sum of all the shortcuts you have taken. Complexity attracts more complexity and compounds in a non-linear way. Every shortcut you take is an invitation to more shortcuts elsewhere. 46 46 + - Your code doesn't advocate for you. People do. In organizations, decisions get made in meetings you're not invited to, using summaries you didn't write, by people who have five minutes and twelve priorities. If no one can articulate your impact when you're not in the room, your impact is effectively optional. [Make the value chain legible to everyone, including yourself](https://addyosmani.com/blog/21-lessons/). 46 47 - When the context changes a lot, you can use [the blue tape technique](https://randsinrepose.com/archives/the-blue-tape-list/) to notice what is wrong with it: 47 48 1. Notice everything that feels off. 48 49 2. Make a list of everything that feels off, no matter how big or small.