<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>hank.bond</title><link>https://hank.bond/</link><description>Recent content on hank.bond</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sat, 15 Aug 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://hank.bond/index.xml" rel="self" type="application/rss+xml"/><item><title>The best pattern is the one you can understand</title><link>https://hank.bond/posts/the-best-pattern-is-the-one-you-can-understand/</link><pubDate>Sat, 15 Aug 2026 00:00:00 +0000</pubDate><guid>https://hank.bond/posts/the-best-pattern-is-the-one-you-can-understand/</guid><description>&lt;p&gt;Models are loosely a compression of all the easily accessible human knowledge (obviously this depends on their training corpus and parameter size etc.), so they have pretty much every software pattern stuffed in them. If you were to ask a colleague &amp;ldquo;what pattern should I apply to this problem?&amp;rdquo; they can only point you towards the patterns they are aware of. That colleague will hopefully also be able to communicate their motivation for choosing that pattern, either as a practical choice (it scales well) or a matter of taste (it makes sense). Now, you may &lt;em&gt;disagree&lt;/em&gt; that their proposal makes sense. After all, everyone has their own unique perspective that is informed by their skill level, domain of expertise, and aesthetic alignment.&lt;/p&gt;</description></item><item><title>When You Leave, What Comes with You?</title><link>https://hank.bond/microblog/2026-06-06-when-you-leave-what-comes-with-you/</link><pubDate>Sat, 06 Jun 2026 17:18:59 +0000</pubDate><guid>https://hank.bond/microblog/2026-06-06-when-you-leave-what-comes-with-you/</guid><description>&lt;p&gt;This one is a bit of a ramble but I have some loose questions bouncing around rn.&lt;/p&gt;&#10;&lt;p&gt;Who owns the Agentic capabilities you create for yourself in the course of working somewhere? When you learn something during your day job, it&amp;rsquo;s tacitly agreed upon that the knowledge in your meat machine is yours to keep. It&amp;rsquo;s not like the company has direct access to it anyway, they have to use You as an Interface to get access to it anyway. They own the code you create, but not the knowledge of how to re-create that code (outside of some strict trade-secret agreements I guess).&lt;/p&gt;</description></item><item><title>Your Coding Agent Should Maximize 'Youness'</title><link>https://hank.bond/microblog/2026-06-06-your-coding-agent-should-maximize-youness/</link><pubDate>Sat, 06 Jun 2026 14:59:51 +0000</pubDate><guid>https://hank.bond/microblog/2026-06-06-your-coding-agent-should-maximize-youness/</guid><description>&lt;h2 id="creative-vs-assertive"&gt;Creative vs Assertive&lt;/h2&gt;&#10;&lt;p&gt;This is not really a hot take, but I was just thinking about how in The Before Times we already had different developer setups when we did work. I&amp;rsquo;m pretty basic and just raw dog VS Code without any meaningful extensions. Plenty of coworkers have used JetBrains flavors, Vim, EMacs, some even use Sublime Text because they like the simplicity.&lt;/p&gt;&#10;&lt;p&gt;The human aspect of the code creation was also very different person to person. Each team member had their own affinity for certain design patterns, and as long as it was understandable to the others pretty much anything goes. Names of Things are also relatively arbitrary, so variance there was to be expected as well.&lt;/p&gt;</description></item><item><title>On Working with LLMs on Unfamiliar Territory</title><link>https://hank.bond/microblog/2026-05-26-on-working-with-llms-on-unfamiliar-territory/</link><pubDate>Tue, 26 May 2026 01:14:42 +0000</pubDate><guid>https://hank.bond/microblog/2026-05-26-on-working-with-llms-on-unfamiliar-territory/</guid><description>&lt;p&gt;Unlike when I am prototyping a solution using &lt;em&gt;tools, concepts, and frameworks that I already understand&lt;/em&gt;, when I am trying to work in an area where I cannot be a reliable judge, I tend to iterate much more carefully. There&amp;rsquo;s really two frames that I am under when working with Models and they are mostly mutually exclusive. I try to increase either speed of:&lt;/p&gt;&#10;&lt;ol&gt;&#10;&lt;li&gt;&lt;strong&gt;Output artifact creation&lt;/strong&gt; by leveraging my expertise and ability to Judge faster than I can Do.&lt;/li&gt;&#10;&lt;li&gt;&lt;strong&gt;Input knowledge acquisition&lt;/strong&gt; by leveraging the Model&amp;rsquo;s ability to Explain faster than I can Do.&lt;/li&gt;&#10;&lt;/ol&gt;&#10;&lt;p&gt;So in the second frame, the primary goal is that I bring myself up to speed until I feel comfortable defending the directions we have taken. Yes sometimes its just &amp;ldquo;well that&amp;rsquo;s the best I can understand this for now&amp;rdquo;, but when the session is over I am one step closer to reaching the first frame.&lt;/p&gt;</description></item><item><title>AI Layoffs are Tacit Admissions of Failure</title><link>https://hank.bond/posts/ai-layoffs-are-tacit-admissions-of-failure/</link><pubDate>Sun, 17 May 2026 00:00:00 +0000</pubDate><guid>https://hank.bond/posts/ai-layoffs-are-tacit-admissions-of-failure/</guid><description>&lt;p&gt;The last year has been pretty wild for the software industy. As of April 2026, this year has had 33k job cuts (if you ask Challenger, Gray &amp;amp; Christmas, who supposedly have been providing layoff stats for quite a long time [@challenger-apr-2026].) The common theme from the CEOs here is that AI is the main motivator (or enabler) of these layoffs.&lt;/p&gt;&#10;&lt;p&gt;If we take them at their word they are either&lt;/p&gt;</description></item><item><title>We Have the Model, Why do We Need You?</title><link>https://hank.bond/posts/we-have-the-model-why-do-we-need-you/</link><pubDate>Sun, 17 May 2026 00:00:00 +0000</pubDate><guid>https://hank.bond/posts/we-have-the-model-why-do-we-need-you/</guid><description>&lt;p&gt;I was thinking about how to properly communicate the value of&lt;/p&gt;&#10;&lt;ol&gt;&#10;&lt;li&gt;Software Engineering as a discipline, in the era of rapid LLM code generation&lt;/li&gt;&#10;&lt;li&gt;Me as an individual, basically &amp;ldquo;why should you hire me specifically?&amp;rdquo;&lt;/li&gt;&#10;&lt;/ol&gt;&#10;&lt;p&gt;In The Before Times, the answer was vaguely &amp;ldquo;I solve your business problem using code&amp;rdquo;.&lt;/p&gt;&#10;&lt;p&gt;This value was pretty clear to Business People, in that they would want &lt;em&gt;a thing to do a thing&lt;/em&gt; and had two options.&lt;/p&gt;</description></item><item><title>Semantic HTML Explorations</title><link>https://hank.bond/microblog/2026-05-14-semantic-html-explorations/</link><pubDate>Thu, 14 May 2026 20:42:10 +0000</pubDate><guid>https://hank.bond/microblog/2026-05-14-semantic-html-explorations/</guid><description>&lt;p&gt;Was talking with Chat about whether or not we were maximally using HTML tags that are more semantic in nature in this site&amp;rsquo;s templates and processing. Given that this is currently a Hugo based site, and its pretty easy to improve HTML usage with automation, I thought it would good to explore this.&lt;/p&gt;&#10;&lt;p&gt;Here are some cool (by my estimation) HTML tags that I was not aware of before.&lt;/p&gt;&#10;&lt;hr&gt;&#10;&lt;p&gt;&lt;code&gt;abbr&lt;/code&gt; is for acronyms and abbreviations. I find this valuable because while I love to use acronyms for the improved information density, I really don&amp;rsquo;t like assuming that everyone reading will be aware of what they mean. As a reader/learner I find these types of assumptions very freustrating, especially when they are for terms and abbreviations specific to an industry. Using this tag lets me document what abberviations stand for pretty easily.&lt;/p&gt;</description></item><item><title>Reflection is All You Need</title><link>https://hank.bond/posts/reflection-is-all-you-need/</link><pubDate>Sat, 25 Apr 2026 00:00:00 +0000</pubDate><guid>https://hank.bond/posts/reflection-is-all-you-need/</guid><description>To create great agents/skills: start very small and very simple with broad language telling it what you want (not how to do it), use it as-is, pay attention as it runs, add corrections for where it went wrong back into the prompt, repeat over and over and over. That&amp;rsquo;s it!</description></item><item><title>MCP vs CLI: The Token Tax</title><link>https://hank.bond/posts/mcp-vs-cli-the-token-tax/</link><pubDate>Thu, 19 Mar 2026 00:00:00 +0000</pubDate><guid>https://hank.bond/posts/mcp-vs-cli-the-token-tax/</guid><description>For local agentic workflows, CLI tools composed with unix pipes are leaner on tokens, faster to iterate, and more expressive than MCP. MCP is most useful for enterprises with more robust operational needs. For one developer talking to their own machine, go with the simpler CLI approach.</description></item><item><title>Agents must have the same context as Humans</title><link>https://hank.bond/principles/agents-must-have-the-same-context-as-humans/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://hank.bond/principles/agents-must-have-the-same-context-as-humans/</guid><description>Everyone has their own Agent framework, SKILLs for each role in a startup, RAG system that &amp;ldquo;solves the memory problem&amp;rdquo;. The problem is that its unlikely you will have the same needs, and worse yet</description></item><item><title>Design System</title><link>https://hank.bond/design-system/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://hank.bond/design-system/</guid><description>&lt;style&gt;&#10; .design-page .article-body {&#10; max-width: none;&#10; }&#10;&#10; .design-section {&#10; border-top: var(--chrome-rule);&#10; margin-top: 2rem;&#10; padding-top: 1rem;&#10; }&#10;&#10; .design-section &gt; h2 {&#10; margin-top: 0;&#10; }&#10;&#10; .design-grid {&#10; display: grid;&#10; gap: 1rem;&#10; grid-template-columns: repeat(auto-fit, minmax(9rem, 1fr));&#10; margin: 1rem 0 1.25rem;&#10; }&#10;&#10; .design-swatch {&#10; background: var(--c-white);&#10; border: var(--pixel-card-border);&#10; box-shadow: var(--pixel-panel-shadow);&#10; min-width: 0;&#10; padding: 0.5rem;&#10; }&#10;&#10; .design-swatch-chip {&#10; border: var(--chrome-rule);&#10; height: 4rem;&#10; margin-bottom: 0.5rem;&#10; }&#10;&#10; .design-swatch-chips {&#10; display: grid;&#10; gap: 0.35rem;&#10; grid-template-columns: 1fr 1fr;&#10; margin-bottom: 0.5rem;&#10; }&#10;&#10; .design-swatch-chips .design-swatch-chip {&#10; margin-bottom: 0;&#10; }&#10;&#10; .design-swatch-name,&#10; .design-swatch-value,&#10; .design-dither-label {&#10; display: block;&#10; font-family: var(--font-small);&#10; font-size: var(--font-small-size);&#10; line-height: 1.35;&#10; }&#10;&#10; .design-swatch-value {&#10; color: var(--c-gray-34);&#10; }&#10;&#10; .design-dither {&#10; align-items: flex-start;&#10; background-color: var(--c-white);&#10; border: var(--pixel-card-border);&#10; box-shadow: var(--pixel-panel-shadow);&#10; display: flex;&#10; min-height: 6rem;&#10; padding: 0.65rem;&#10; }&#10;&#10; .design-dither-scale {&#10; margin: 1rem 0 1.5rem;&#10; }&#10;&#10; .design-dither-scale h3 {&#10; font-family: var(--font-small);&#10; font-size: var(--font-small-size);&#10; margin: 0 0 0.65rem;&#10; }&#10;&#10; .design-dither-dark {&#10; color: var(--c-white);&#10; }&#10;&#10; .design-dither-label {&#10; -webkit-text-stroke: var(--readable-stroke-width) var(--c-white);&#10; paint-order: stroke;&#10; }&#10;&#10; .design-dither-dark .design-dither-label {&#10; -webkit-text-stroke-color: var(--c-black);&#10; }&#10;&#10; .design-font-grid {&#10; display: grid;&#10; gap: 0.75rem;&#10; grid-template-columns: repeat(auto-fit, minmax(14rem, 1fr));&#10; }&#10;&#10; .design-font-sample {&#10; background: var(--c-white);&#10; border: var(--pixel-card-border);&#10; padding: 0.75rem;&#10; }&#10;&#10; .design-font-sample span {&#10; display: block;&#10; font-family: var(--font-small);&#10; font-size: var(--font-small-size);&#10; margin-bottom: 0.4rem;&#10; }&#10;&#10; .design-font-chicago p {&#10; font-family: var(--font-chrome);&#10; font-size: 18px;&#10; letter-spacing: 0.04em;&#10; }&#10;&#10; .design-font-espy p {&#10; font-family: var(--font-copy);&#10; }&#10;&#10; .design-font-code p {&#10; font-family: var(--font-block-code);&#10; font-size: 18px;&#10; }&#10;&#10; .design-inline-sample {&#10; line-height: 1.9;&#10; max-width: 65ch;&#10; }&#10;&#10; .design-button-row {&#10; align-items: center;&#10; display: flex;&#10; flex-wrap: wrap;&#10; gap: 0.7rem;&#10; list-style: none;&#10; margin: 1rem 0 1.25rem;&#10; padding: 0;&#10; }&#10;&#10; .design-button-row .ui-button {&#10; font-size: 18px;&#10; }&#10;&#10; .design-emoji-grid {&#10; display: grid;&#10; gap: 0.75rem;&#10; grid-template-columns: repeat(auto-fit, minmax(10rem, 1fr));&#10; margin: 1rem 0 1.25rem;&#10; }&#10;&#10; .design-emoji-sample {&#10; align-items: center;&#10; background: var(--c-white);&#10; border: var(--pixel-card-border);&#10; display: flex;&#10; gap: 0.75rem;&#10; min-width: 0;&#10; padding: 0.75rem;&#10; }&#10;&#10; .design-emoji-sample &gt; span:first-child {&#10; color: var(--c-gray-34);&#10; font-family: var(--font-small);&#10; font-size: var(--font-small-size);&#10; line-height: 1.35;&#10; min-width: 4.5rem;&#10; }&#10;&#10; .design-emoji-row {&#10; align-items: center;&#10; display: flex;&#10; flex-wrap: wrap;&#10; gap: 0.6rem;&#10; }&#10;&lt;/style&gt;&#10;&lt;h2 id="type"&gt;Type&lt;/h2&gt;&#10;&lt;div class="design-font-grid"&gt;&#10; &lt;div class="design-font-sample design-font-chicago"&gt;&#10; &lt;span&gt;Chrome&lt;/span&gt;&#10; &lt;p&gt;System window labels and tiny controls.&lt;/p&gt;</description></item><item><title>Directives are not enforced by prompting</title><link>https://hank.bond/principles/directives-are-not-enforced-by-prompting/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://hank.bond/principles/directives-are-not-enforced-by-prompting/</guid><description>&lt;p&gt;You can ask the model nicely and it will &lt;em&gt;mostly&lt;/em&gt; listen &lt;em&gt;most&lt;/em&gt; of the time. &amp;ldquo;DO NOT SKIP THIS STEP!!!&amp;rdquo; is not engineering. If a regex, a parser, or a tool-call hook can enforce the rule, use it.&lt;/p&gt;&#10;&lt;p&gt;Need a list of actions to be taken &lt;em&gt;every time&lt;/em&gt;? Make each a tool call &lt;code&gt;&amp;lt;step_one&amp;gt;&lt;/code&gt;, with the loop/pipeline not finishing until the final &lt;code&gt;&amp;lt;end_run&amp;gt;&lt;/code&gt; tool is called. At the &amp;ldquo;end&amp;rdquo; of the conversation you can parse the tool calls to enforce that they were all called. If not, then either abort and retry the run, or if appropriate add a followup turn + directive to run the missing steps. Some agent frameworks give you a version of this when using their execution primatives, but its also something not terribly difficult to implement.&lt;/p&gt;</description></item><item><title>Every LLM session will build towards the next</title><link>https://hank.bond/principles/every-llm-session-will-build-towards-the-next/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://hank.bond/principles/every-llm-session-will-build-towards-the-next/</guid><description>A useful session should not evaporate when the chat ends. It should produce some durable improvement, a sharper prompt, a better script, a clearer spec, a committed fix, or even just a note about what went sideways. The next agent should start ahead, not at the same blank wall with a fresh cup of amnesia.</description></item><item><title>Import others' ideas, not their implementations</title><link>https://hank.bond/principles/import-others-ideas-not-their-implementations/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://hank.bond/principles/import-others-ideas-not-their-implementations/</guid><description>Everyone has their own Agent framework, SKILLs for each role in a startup, RAG system that &amp;ldquo;solves the memory problem&amp;rdquo;. The problem is that its unlikely you will have the same needs, and worse yet</description></item><item><title>Use code for everything you can</title><link>https://hank.bond/principles/use-code-for-everything-you-can/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://hank.bond/principles/use-code-for-everything-you-can/</guid><description>LLMs can handle ambiguity but are imprecise even in the best case. Your goal is to improve reliability, and so you must aim to use the most consistent tool whenever possible. When using LLMs, push as much functionality as you can into the deterministic layer by codifying functionality with actual code, not LLM instructions.</description></item></channel></rss>