flâneur

Emily Zhang

6 followers · 1 following · 344 views

on the atlas — 35

highlights — 56

  • To prevent context collapse and brevity bias during iterative rewrites, one key design choice in ACE is that the curator does not rewrite a full prompt blob. It instead outputs a collection of structured, itemized bullets in the form of (identifier, description), and these bullets are merged into a structured context logbook with deterministic logic. The context items are refined and deduplicated periodically.
    Harness Engineering for Self-Improvement | Lil'Log
  • The model knows best; minimal tooling is sufficient. The agent creates the necessary abstractions for the task at hand when given access to simple primitives. We find diminishing (even negative) returns with additional hand-engineering, e.g., pre-built functions or memory abstraction modules. Structured search over raw game logs, even exceeding 100k lines, remains tractable and effective under our RGB setup.
    Hill-climbing ARC-AGI-3
  • The model knows best; minimal tooling is sufficient. The agent creates the necessary abstractions for the task at hand when given access to simple primitives. We find diminishing (even negative) returns with additional hand-engineering, e.g., pre-built functions or memory abstraction modules. Structured search over raw game logs, even exceeding 100k lines, remains tractable and effective under our RGB setup.
    Hill-climbing ARC-AGI-3
  • In the majority of harnesses, the control flow is fixed from the start. Some approaches choose depth, allowing the underlying model access to a persistent environment that accumulates state [12]. This relies on the reasoning or interleaved thinking (reasoning while calling tools) of the underlying model. Others choose width, employing parallel sampling of the same or various agents, aggregating results at the end [7][11]. In both cases, agents lack the autonomy to dynamically choose one or the other.
    SotA ARC-AGI-2 Results with REPL Agents | Symbolica Blog
  • Eventually it is possible that many harness improvements will be internalized into core model behavior, but the interface with external context and tools should remain. We have seen a softer version of this pattern with prompt engineering: manual prompt tricks became less central as instruction tuning and model reasoning improved, but the need to specify goals, constraints, context, and evaluation did not disappear.
    Harness Engineering for Self-Improvement | Lil'Log
  • He is not a relativist, for the main point of the essay on taste is that some judgments of taste are superior to others. Nor, in his own terms, is he a skeptic regarding aesthetic properties and value judgments. Despite his philosophical view that beauty is not a real property of things, Hume never questions the meaningfulness of general practice of making aesthetic judgments. Because the verdicts of taste are sentiments, devoid of truth-value, there is no opportunity for the conflicts and failures of reason that give rise to philosophical skepticism.
    Hume’s Aesthetics (Stanford Encyclopedia of Philosophy)
  • Houses will be designed and built apart from any need to satisfy our taste for beauty, and representational art will be produced in order to provide visual information. The interesting questions are why houses and visual representations also appeal to taste, and what this appeal tells us about the relative contributions of human nature and education as conditions for appropriate responses to our surroundings.
    Hume’s Aesthetics (Stanford Encyclopedia of Philosophy)
  • Although recognition of aesthetic and moral beauty is a manifestation of taste (and perhaps they cannot ultimately be distinguished from one another), taste must not be dismissed as subjective, idiosyncratic preference.
    Hume’s Aesthetics (Stanford Encyclopedia of Philosophy)
  • Value judgments are expressions of taste rather than reasoned analysis. Values cannot be addressed except in the context of a general theory about our shared human nature.
    Hume’s Aesthetics (Stanford Encyclopedia of Philosophy)
  • So Hume’s reflections on aesthetics occupy a pivotal niche between the appearance of fine art theory and Kant’s defense of an independent aesthetic judgment in the Critique of Judgment – a defense clearly influenced by Kant’s reading of Hume’s essays and An Enquiry Concerning the Principles of Morals.
    Hume’s Aesthetics (Stanford Encyclopedia of Philosophy)
  • Mental taste arises in response to ideas that arise in response to impressions (e.g., viewing a photograph occasions thoughts about the place pictured, leading to thoughts about experiences one had or might have there, and the thoughts arising in this imaginative process are pleasurable or painful). Hume regards this “immediacy” of taste as entirely compatible with the influence of intellectual and imaginative faculties.
    Hume’s Aesthetics (Stanford Encyclopedia of Philosophy)
  • As a matter of self-respect, you should try to believe the truth no matter how uncomfortable it is, like I said before; but as a matter of human nature, it helps to make a belief less uncomfortable, before you try to evaluate the evidence for it.”
    Leave a Line of Retreat - LessWrong
  • The hope is that it takes less courage to visualize an uncomfortable state of affairs as a thought experiment, than to consider how likely it is to be true. But then after you do the former, it becomes easier to do the latter.
    Leave a Line of Retreat - LessWrong
  • There was no economic logic in doing what the sculptor did. But it spoke to a deep human need. We need sewage pipes, yes, but we also need to honor the sense of aliveness that rushes through us. As in the apocryphal story about a legislative session during the Second World War, when someone suggested cutting the arts funding to support the war effort, and Churchill answered, “But then what are we fighting for?” It is ok to sacrifice yourself to the hunger for art; that is what the sculptor’s work says to me.
    On the compulsion to make art - by Henrik Karlsson
  • The feeling of a hand in 1972 made into an object that will stand for millennia… It is hard not to see a parallel to some of the oldest preserved cave paintings, which are hands that have been held up against the cave wall and preserved as silhouettes by color pigments blown at the hand. We were here; we felt this.
    On the compulsion to make art - by Henrik Karlsson
  • The work was what kept him connected to himself and to the life force he felt in the world. “The more you work, the more things come to you. It’s a very amusing function,” the sculptor writes. “You get into a good circle, where the more you make, the more you can do, and the more ideas come to you. And conversely, if you’re away from it, it’s very hard to get going again. And your stomach starts to hurt, and you get depressed. Then you just have to throw yourself into it, but that can be hard. … I love the feeling of stone dust between my teeth after a long winter.”
    On the compulsion to make art - by Henrik Karlsson
  • I found much more comfort in the stories of artists who fixed toilets but never got famous, and who did it anyway. It helped me remember that that cave man desire to populate the earth with your art is normal.
    On the compulsion to make art - by Henrik Karlsson
  • All of the artists had been outsiders. They had not been part of a scene. But when you grouped them, they looked like a constellation—like lone suns, hung in infinite darkness, that from afar revealed themselves to be part of the same pattern. It was a pattern of people with a compulsive need to look at the landscapes around them, at their small life worlds, and to capture what they saw. I imagined myself and Johanna as a part of the constellation and took comfort in that.
    On the compulsion to make art - by Henrik Karlsson
  • Coming back was more of a culture shock than going. All I really wanted to do [after returning to California] was to go find a grassy meadow and just sit. I didn’t want to drive a car. I didn’t want to go to San Francisco or do all these things. I didn’t want to do it. So I didn’t, for about three months. I just read and sat. When you are a stranger in a place, you notice things that you rapidly stop noticing when you become familiar. I was a stranger in America for the first time in my life, and so I saw things I’d never seen before. And I tried to pay attention to them for those three months…
    Make Something Wonderful | Steve Jobs
  • His ideas were not arguments, but intuitions, born of a true inner freedom and an epic sense of possibility.
    Make Something Wonderful | Steve Jobs
  • But one of the ways that I believe people express their appreciation to the rest of humanity is to make something wonderful and put it out there. And you never meet the people. You never shake their hands. You never hear their story or tell yours. But somehow, in the act of making something with a great deal of care and love, something’s transmitted there. And it’s a way of expressing to the rest of our species our deep appreciation. So we need to be true to who we are and remember what’s really important to us.
    Make Something Wonderful | Steve Jobs
  • Not so in the world of engineering. Good engineers are right, a lot. They’re right about concrete factual statements about how software systems work (e.g. endpoint X has rate limit Y). They’re right about concrete plans (e.g. we can’t add this check here, but it’ll work there). They’re right about a million small decisions that they make when they write code, which shows up in their code generally working and causing fewer bugs. You can assess an engineer based on how smart they sound in conversation, whether they use light mode VSCode or dark mode vim, what their title is, and so on. But if y…
    Good engineers are right, a lot
  • We need to engage people from all parts of the educational ecosystem — teachers, parents, administrators, developer, policymakers — in a movement supporting human-centered education, to ensure that children can develop their hundred languages, and grow up as creative, curious, caring, and collaborative learners. That’s the best way to ensure a pluralistic, democratic, human-centered society.
    In the age of AI, we need a human-centered society more than ever | by Mitchel Resnick | Medium
  • The child has a hundred languages (and a hundred hundred hundred more) but they steal ninety-nine
    In the age of AI, we need a human-centered society more than ever | by Mitchel Resnick | Medium
  • The child has a hundred languages a hundred hands a hundred thoughts a hundred ways of thinking of playing, of speaking
    In the age of AI, we need a human-centered society more than ever | by Mitchel Resnick | Medium
  • I worry that many of the new AI applications in education will: reduce children’s sense of agency and control diminish children’s sense of joy and accomplishment undermine children’s opportunities for personal expression replace opportunities for human connection.
    In the age of AI, we need a human-centered society more than ever | by Mitchel Resnick | Medium
  • We need to expand opportunities for children to develop the most human of their abilities. That is, we need to help them develop as creative, curious, caring, and collaborative learners. These qualities have always been important, but they are more important now than ever before, given the technological and political disruptions confronting today’s societies.
    In the age of AI, we need a human-centered society more than ever | by Mitchel Resnick | Medium
  • - Outside commencement date
    RMS Avails & Conflict Checking Requirements - Google Sheets
  • You can assess an engineer based on how smart they sound in conversation, whether they use light mode VSCode or dark mode vim, what their title is, and so on. But if you have the time, it’s far more reliable to assess them based on whether they’re right a lot. For technical colleagues, this assessment comes automatically: you can just ask yourself whether you feel default relaxed or suspicious when they make claims, or how much of a critical eye you naturally bring to review their PRs. Otherwise you can pay attention to what they say with confidence, and whether it turns out to be correct. If …
    Good engineers are right, a lot
  • You can assess an engineer based on how smart they sound in conversation, whether they use light mode VSCode or dark mode vim, what their title is, and so on. But if you have the time, it’s far more reliable to assess them based on whether they’re right a lot. For technical colleagues, this assessment comes automatically: you can just ask yourself whether you feel default relaxed or suspicious when they make claims, or how much of a critical eye you naturally bring to review their PRs. Otherwise you can pay attention to what they say with confidence, and whether it turns out to be correct. If …
    Engineers who won’t commit
  • I think what’s often motivating this attitude is that many engineers (me included) really, really, pathologically hate being wrong. I get a sick feeling in my chest when I’m wrong about something, particularly in public. I think about it afterwards for a long time. This is useful, because it makes me put in the effort to be right. But it also makes it emotionally difficult to give an educated guess in a meeting that might end up being dead wrong. I’ve had to work to become OK with doing that, so I sympathize with people who can’t. But I also see it for what it is: cowardice. When people are re…
    Engineers who won’t commit
  • In code, check the INTERSECTION (not UNION) of all permissions that affect a particular UI area or endpoint (AND instead of OR). Essentially in code, it can then be easy to show/hide an entire area (or lock down an entire page readonly) based on a general permission, and then make sub-areas/buttons/functions check a more specific permission in addition. If a function/area checks UNION of more general and more specific permissions, it will be unclear when permissions do or do not control things (since a child permission is overriding a more general permission).
    A simple user permission model for sophisticated systems - DEV Community
  • However, in my experience, there’s no substitute for being able to just turn off some high-volume low-importance feature via a killswitch. When things are really bad, sometimes you want to turn everything remotely non-essential off in the hopes that you’ll be able to get the essentials running sooner.
    Every service should have a killswitch
  • When might you want to use a killswitch? Sometimes it’s a way to instantly remediate a software bug. If you’ve got code that’s systematically deleting user data, or adding nonsense comments to their posts, it’s useful to be able to turn that off.
    Every service should have a killswitch
  • If your company has a feature flagging system - which it should - this can be as simple as adding a return if feature_enabled?(pdf_converter_job_killswitch) to the top of your scheduled job. If the job ever goes out of control (running way too often, or using too many resources) you can turn it off by creating or enabling that feature. Enabling a feature flag is usually many minutes quicker than a code deploy. During an incident, when deploying is difficult, it can be hours quicker.
    Every service should have a killswitch
  • Whether you should fail open or closed depends on the specific feature. In my view, a rate limiting system should almost always fail open. That means that a problem with the rate limiting code isn’t necessarily a big user-facing incident. However, auth should (obviously) always fail closed: it’s better to deny a user access to their own data than to give a user access to some other user’s data. There are a lot of cases where it’s not clear what the right behavior is. It’s often a difficult tradeoff.
    Everything I know about good system design
  • You also need to make sure you’re not retrying write events that may or may not have succeeded (for instance, if you send a “bill this user” request and get back a 5xx, you don’t know if the user has been billed or not). The classic solution to this is to use an “idempotency key”, which is a special UUID in the request that the other service uses to avoid re-running old requests: every time they do something, they save the idempotency key, and if they get another request with the same key, they silently ignore it.
    Everything I know about good system design
  • Retries are not a magic bullet. You need to make sure you’re not putting extra load on other services by blindly retrying failed requests. If you can, put high-volume API calls inside a “circuit breaker”: if you get too many 5xx responses in a row, stop sending requests for a while to let the service recover
    Everything I know about good system design
  • You should also have basic observability into the operational parts of the system. That means CPU/memory on the hosts or containers, queue sizes, average time per-request or per-job, and so on. For user-facing metrics like time per-request, you also need to watch the p95 and p99 (i.e. how slow your slowest requests are). Even one or two very slow requests are scary, because they’re disproportionately from your largest and most important users.
    Everything I know about good system design
  • One thing I’ve learned from my most paranoid colleagues is to log aggressively during unhappy paths
    Everything I know about good system design
  • The trick is to mainly focus on the “hot paths”: the part of the system that is most critically important, and the part of the system that is going to handle the most data.
    Everything I know about good system design
  • Suppose you did need to serve up-to-date data to a million clients (like GMail, does). Should those clients be pushing or pulling? It depends. Either way, you won’t be able to run it all from a single server, so you’ll need to farm it out to other components of the system. If you’re pushing, that will likely mean sticking each push on an event queue and having a horde of event processors each pulling from the queue and sending out your pushes. If you’re pulling, that will mean standing up a bunch (say, a hundred) of fast4 read-replica cache servers that will sit in front of your main applicati…
    Everything I know about good system design
  • If we’re talking about background services instead of users with web browsers, it’s easy to see why pushing can be a good idea. Even in a very large system, you might only have a hundred or so services that need the same data. For data that doesn’t change much, it’s much easier to make a hundred HTTP requests (or RPC, or whatever) whenever the data changes than to serve up the same data a thousand times a second.
    Everything I know about good system design
  • You shouldn’t overuse events. Much of the time it’s better to just have one service make an API request to another service: all the logs are in the same place, it’s easier to reason about, and you can immediately see what the other service responded with. Events are good for when the code sending the event doesn’t necessarily care what the consumers do with the event, or when the events are high-volume and not particularly time-sensitive (e.g. abuse scanning on each new Twitter post).
    Everything I know about good system design
  • If you need to cache the result of a really expensive operation (say, a weekly usage report for a large customer), you might not be able to fit the result in Redis or Memcached. Instead, stick a timestamped blob of the results in your document storage and serve the file directly from there. Like the database-backed long-term queue I mentioned above, this is an example of using the caching idea without using a specific cache technology.
    Everything I know about good system design
  • For instance, if you’re calculating how much to charge a user in a billing service, you might need to do an API call to look up the current prices. If you’re charging users per-use (like OpenAI does per-token), that could (a) be unacceptably slow and (b) cause a lot of traffic for whatever service is serving the prices. The classic solution here is caching: only looking up the prices every five minutes, and storing the value in the meantime. It’s easiest to cache in-memory, but using some fast external key-value store like Redis or Memcached is also popular (since it means you can share one ca…
    Everything I know about good system design
  • There will be two main components: a collection of queues, e.g. in Redis, and a job runner service that will pick up items from the queues and execute them. You enqueue a background job by putting an item like {job_name, params} on the queue. It’s also possible to schedule background jobs to run at a set time (which is useful for periodic cleanups or summary rollups). Background jobs should be your first choice for slow operations, because they’re typically such a well-trodden path.
    Everything I know about good system design
  • You should try and minimize the amount of stateful components in any system.
    Everything I know about good system design
  • A typical database setup will have one write node and a bunch of read-replicas. The more you can avoid reading from the write node, the better - that write node is already busy enough doing all the writes. The exception is when you really, really can’t tolerate any replication lag (since read-replicas are always running at least a handful of ms behind the write node). But in most cases replication lag can be worked around with simple tricks: for instance, when you update a record but need to use it right after, you can fill in the updated details in-memory instead of immediately re-reading aft…
    Everything I know about good system design
  • If you’re designing a service that might generate massive query spikes (e.g. some kind of bulk-import API), consider throttling your queries.
    Everything I know about good system design