Drew Poling

I'm a software engineer in Pittsburgh with a background in mechanical engineering. I like building systems that behave the way you expect them to, and lately that means color tools, typefaces, and tooling for AI coding agents.

Projects

  • Moatlog

    Behavioral memory for AI coding agents built to reduce token usage and improve cross agent collaboration.

  • WebShades

    Generates a full tonal color palette from a single base color, with single click exports to integrate with semantic modern design systems.

  • drewp.co

    Type foundry for interfaces and code optimized against web environment use cases.

  • RentLemon

    A rental marketplace that analyzes your current rental price against the market. You enter your rent and unit details, and it compares them with similar units nearby to tell you whether you are getting a good deal, a fair price, or overpaying.

  • Optical Compiler

    A browser-based legibility benchmark for typefaces. It renders text at small sizes under simulated conditions like blurred vision, color blindness, and different displays.

  • Feedspace

    A social RSS reader that allows you to turn the feeds you follow into a shareable public page, and connect with your friends.

  • tiny-mood

    Zero-dependency npm package that turns text into a mood-driven CSS gradient background, optionally clamped to your brand colors.

Thoughts & ideas

  • Observations of current AI workflow 2026

    For the past few months I have been logging what my coding agents do. I built moatlog to capture the files they read and write, the shell commands they run, and the prompts I give them, across both Cursor and Claude Code. The original idea was to distill that history into context an agent could read at the start of a session, so it would stop relearning the same repo every time. This post is about what the data actually showed, and how it changed what I think that tool should do.

  • Components are contracts 2026

    A lot of component libraries are really collections. You get a button, an input, and a card, each designed, documented, and tested on its own. They look coherent side by side in a gallery. In a real app, where components get combined, share state, and end up in layouts nobody planned for, the gaps show up quickly.

  • Color as a system 2026

    When I started working on color for a component library, I assumed what most people assume: color is a list of decisions. Pick a primary, pick a neutral, name them, document them, and move on.

  • The pipeline is the test 2025

    I have been working on a side project built on the Riot Games API. The API gives you a lot of data: match history, champion stats, and performance metrics across dozens of dimensions. What it does not give you is a direct answer to the question I actually cared about: how strong is a champion right now compared to the rest of the roster?