<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="3.9.3">Jekyll</generator><link href="https://stephen.bochinski.dev/feed.xml" rel="self" type="application/atom+xml" /><link href="https://stephen.bochinski.dev/" rel="alternate" type="text/html" /><updated>2026-06-20T14:28:30-04:00</updated><id>https://stephen.bochinski.dev/feed.xml</id><title type="html">Stephen Bochinski</title><subtitle>Blog</subtitle><author><name>Stephen Bochinski</name></author><entry><title type="html">AI Coding at Home Without Going Broke</title><link href="https://stephen.bochinski.dev/blog/2026/06/13/ai-coding-at-home-without-going-broke/" rel="alternate" type="text/html" title="AI Coding at Home Without Going Broke" /><published>2026-06-13T00:00:00-04:00</published><updated>2026-06-13T00:00:00-04:00</updated><id>https://stephen.bochinski.dev/blog/2026/06/13/ai-coding-at-home-without-going-broke</id><content type="html" xml:base="https://stephen.bochinski.dev/blog/2026/06/13/ai-coding-at-home-without-going-broke/">&lt;p&gt;There are three ways to do AI coding at home without spending like a company, and which one fits depends mostly on how much you trust the next year of hardware and model releases. The first is to self host. You buy the machine, run open source models locally, and pay nothing per token after that. The upfront cost is steep and the models you can actually run at home are weaker than what the frontier labs ship, so this only pays off if you can keep the rig busy with long running tasks where a slower, cheaper model grinds away overnight. Most people can’t keep a home machine that loaded, and the hardware you buy today may look like a bad bet in a year.&lt;/p&gt;

&lt;p&gt;The second is to skip the hardware and rent those same open source models from a provider at API rates. For most people this is the right call. You avoid putting thousands of dollars on one GPU setup while configurations are still in flux, you skip the work of squeezing long running performance out of an open model, and you can switch to whatever is cheaper or better next month without reselling a box. Something like &lt;a href=&quot;https://openrouter.ai&quot;&gt;OpenRouter&lt;/a&gt; makes the move close to a one line change.&lt;/p&gt;

&lt;p&gt;The third is to min-max the frontier subscriptions from OpenAI and Anthropic. Around $400 a month of plans buys roughly $2800 of API usage at list prices, which is a real bargain right up until you hit the ceiling. The plans are metered, and any large AI native workflow will chew through the included tokens fast. They shine for the work you drive by hand and fall short as the engine for an agent running all day.&lt;/p&gt;

&lt;p&gt;What I’ve seen work best is a blend of the last two. Keep a couple of frontier subscriptions for the hard thinking and the spec writing, and pay API rates for open source models to handle the small mechanical pieces. Lean on spec driven development so the expensive models produce the plan and the cheap ones fill it in. Do that well and you can build what a team of twenty engineers would put out in a month for around a thousand dollars.&lt;/p&gt;</content><author><name>Stephen Bochinski</name></author><summary type="html">There are three ways to do AI coding at home without spending like a company, and which one fits depends mostly on how much you trust the next year of hardware and model releases. The first is to self host. You buy the machine, run open source models locally, and pay nothing per token after that. The upfront cost is steep and the models you can actually run at home are weaker than what the frontier labs ship, so this only pays off if you can keep the rig busy with long running tasks where a slower, cheaper model grinds away overnight. Most people can’t keep a home machine that loaded, and the hardware you buy today may look like a bad bet in a year.</summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://stephen.bochinski.dev/assets/posts/2026-06-13-ai-coding-at-home-without-going-broke.png" /><media:content medium="image" url="https://stephen.bochinski.dev/assets/posts/2026-06-13-ai-coding-at-home-without-going-broke.png" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">What’s Left for AI-Assisted Coding</title><link href="https://stephen.bochinski.dev/blog/2026/05/24/whats-left-for-ai-assisted-coding/" rel="alternate" type="text/html" title="What’s Left for AI-Assisted Coding" /><published>2026-05-24T00:00:00-04:00</published><updated>2026-05-24T00:00:00-04:00</updated><id>https://stephen.bochinski.dev/blog/2026/05/24/whats-left-for-ai-assisted-coding</id><content type="html" xml:base="https://stephen.bochinski.dev/blog/2026/05/24/whats-left-for-ai-assisted-coding/">&lt;p&gt;The tools are already good at the work in front of them. Give an agent a clear task and enough context and it will write something reasonable. The harder questions show up on large projects with large teams, where the code is one part of a much bigger system of decisions, and two pieces are still missing.&lt;/p&gt;

&lt;p&gt;The first is memory. Most of the effort right now goes into steering the agent and making sure it has the right context. There is no agreed upon approach for what a developer should carry between sessions, or for what a team should share across them. Without that, context goes missing and the agent fills the gap with its own assumptions. In the worst case it makes a decision that is quietly wrong and nobody catches it until later. In the better case you spend your day reminding it of requirements it should have known from the start.&lt;/p&gt;

&lt;p&gt;The second is end to end testing the agent can run on its own. This is a security and capability problem for the tooling around the agent. To verify its own work it needs the same kind of access an employee has, enough to deploy, to test, and to reach a production-like environment, with room to escalate when a task calls for it. That runs straight into the &lt;a href=&quot;https://en.wikipedia.org/wiki/Principle_of_least_privilege&quot;&gt;principle of least privilege&lt;/a&gt;, and at a large company with heterogeneous access systems and a dozen deployment workflows, granting that access safely is hard.&lt;/p&gt;

&lt;p&gt;Solve both and the job changes shape. The agent remembers what the team has decided and can prove its changes work in something close to production. At that point the only artifact the engineer writes is the specification, and everything downstream of it becomes the machine’s problem.&lt;/p&gt;</content><author><name>Stephen Bochinski</name></author><summary type="html">The tools are already good at the work in front of them. Give an agent a clear task and enough context and it will write something reasonable. The harder questions show up on large projects with large teams, where the code is one part of a much bigger system of decisions, and two pieces are still missing.</summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://stephen.bochinski.dev/assets/posts/2026-05-24-whats-left-for-ai-assisted-coding.png" /><media:content medium="image" url="https://stephen.bochinski.dev/assets/posts/2026-05-24-whats-left-for-ai-assisted-coding.png" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">Another Round, Another Agent</title><link href="https://stephen.bochinski.dev/blog/2026/01/10/another-round-another-agent/" rel="alternate" type="text/html" title="Another Round, Another Agent" /><published>2026-01-10T00:00:00-05:00</published><updated>2026-01-10T00:00:00-05:00</updated><id>https://stephen.bochinski.dev/blog/2026/01/10/another-round-another-agent</id><content type="html" xml:base="https://stephen.bochinski.dev/blog/2026/01/10/another-round-another-agent/">&lt;p&gt;Another Round follows teachers who experiment with drinking to see if it makes them better at their jobs, chasing a kind of &lt;a href=&quot;https://xkcd.com/323/&quot;&gt;Balmer Peak&lt;/a&gt; effect. It works for a bit. Then it slides into dependency and one of them dies.&lt;/p&gt;

&lt;p&gt;That arc feels familiar in the way people use AI agents. A little help can make you faster and sharper. Too much, too often, without discipline, and you stop noticing what you no longer understand. It feels productive right up until it fails.&lt;/p&gt;

&lt;p&gt;Anything the AI writes still has your name on it. You own the code. That means testing it, reviewing it the way you would review a colleague, and understanding what it does. It is easy to accept changes without the full context or the long tail of consequences. That is how you end up in trouble.&lt;/p&gt;

&lt;p&gt;The movie ends in tragedy because they keep chasing the feeling instead of owning the risk. Agent use can drift the same way. Discipline is the difference between a tool and a habit you cannot control.&lt;/p&gt;</content><author><name>Stephen Bochinski</name></author><summary type="html">Another Round follows teachers who experiment with drinking to see if it makes them better at their jobs, chasing a kind of Balmer Peak effect. It works for a bit. Then it slides into dependency and one of them dies.</summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://stephen.bochinski.dev/assets/posts/2026-01-10-another-round-another-agent.png" /><media:content medium="image" url="https://stephen.bochinski.dev/assets/posts/2026-01-10-another-round-another-agent.png" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">AI Is Plastic</title><link href="https://stephen.bochinski.dev/blog/2026/01/07/ai-is-plastic/" rel="alternate" type="text/html" title="AI Is Plastic" /><published>2026-01-07T00:00:00-05:00</published><updated>2026-01-07T00:00:00-05:00</updated><id>https://stephen.bochinski.dev/blog/2026/01/07/ai-is-plastic</id><content type="html" xml:base="https://stephen.bochinski.dev/blog/2026/01/07/ai-is-plastic/">&lt;p&gt;Plastic won. People complain about it, but it unlocked access to things that used to be out of reach. It made products cheaper, more available, and more disposable. It spread everywhere because it was good enough.&lt;/p&gt;

&lt;p&gt;AI feels the same. It is inferior to handcrafted human work with current tech, and that is obvious to anyone who cares about craft. It still gets used because it covers the majority of use cases at a fraction of the cost. It makes things faster, cheaper, and more available, and that wins.&lt;/p&gt;

&lt;p&gt;There is no need for AI to match the best human output. It only needs to be good enough for most people, most of the time. That is the reality of how tools get adopted in the real world.&lt;/p&gt;

&lt;p&gt;I think it will replace plenty of work we used to hold dear. Many things built by people will be swapped for something cheaper. That’s ok. You can hate that, or you can recognize the shape of the wave.&lt;/p&gt;

&lt;p&gt;Plastic will outlive all of us and most of everything we make. Most likely AI will follow the same path.&lt;/p&gt;</content><author><name>Stephen Bochinski</name></author><summary type="html">Plastic won. People complain about it, but it unlocked access to things that used to be out of reach. It made products cheaper, more available, and more disposable. It spread everywhere because it was good enough.</summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://stephen.bochinski.dev/assets/posts/2026-01-07-ai-is-plastic.png" /><media:content medium="image" url="https://stephen.bochinski.dev/assets/posts/2026-01-07-ai-is-plastic.png" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">Agents Are Now Table Stakes</title><link href="https://stephen.bochinski.dev/blog/2026/01/05/agents-are-table-stakes/" rel="alternate" type="text/html" title="Agents Are Now Table Stakes" /><published>2026-01-05T00:00:00-05:00</published><updated>2026-01-05T00:00:00-05:00</updated><id>https://stephen.bochinski.dev/blog/2026/01/05/agents-are-table-stakes</id><content type="html" xml:base="https://stephen.bochinski.dev/blog/2026/01/05/agents-are-table-stakes/">&lt;p&gt;The recent paper &lt;a href=&quot;https://arxiv.org/pdf/2512.14012&quot;&gt;“Professional Software Developers Don’t Vibe, They Control”&lt;/a&gt; is a solid read. The authors studied experienced developers using coding agents and found what most of us already know in practice: pros don’t hand over the wheel. They plan, they steer, they verify.&lt;/p&gt;

&lt;p&gt;I read it as confirmation that agents are now part of the craft.&lt;/p&gt;

&lt;p&gt;We used to treat AI tools like optional experiments. Fun to try, easy to ignore. That era is over.&lt;/p&gt;

&lt;p&gt;Coding agents now sit in the same category as version control, code review, and tests. Those practices are required to ship professional software, even when they are boring and slow.&lt;/p&gt;

&lt;p&gt;I hear this a lot: “My work is too complex for LLMs.” Maybe. It usually means you haven’t figured out how to use them well yet.&lt;/p&gt;

&lt;p&gt;Agents are force multipliers. If you have taste, they help you move faster. If you don’t, they help you move wrong faster. The solution is to learn the skill and use them with intent.&lt;/p&gt;

&lt;p&gt;We’re past the point where AI use is a personal preference. It’s a professional capability. People who can steer agents well will ship more, learn faster, and have more leverage. People who can’t will be left behind by those who can.&lt;/p&gt;

&lt;p&gt;That isn’t hype. It’s the same dynamic we saw with every other shift in tooling. The ones who mastered version control, testing, and CI didn’t just move faster. They raised the bar for everyone else, and everyone else had to catch up.&lt;/p&gt;

&lt;p&gt;The paper is right. Professional teams control agents. Vibes are just noise. And now, controlling agents is part of the job, even if it feels a bit awkward at first.&lt;/p&gt;</content><author><name>Stephen Bochinski</name></author><summary type="html">The recent paper “Professional Software Developers Don’t Vibe, They Control” is a solid read. The authors studied experienced developers using coding agents and found what most of us already know in practice: pros don’t hand over the wheel. They plan, they steer, they verify.</summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://stephen.bochinski.dev/assets/posts/2026-01-05-agents-are-table-stakes.png" /><media:content medium="image" url="https://stephen.bochinski.dev/assets/posts/2026-01-05-agents-are-table-stakes.png" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">AI Personas</title><link href="https://stephen.bochinski.dev/blog/2026/01/02/ai-personas/" rel="alternate" type="text/html" title="AI Personas" /><published>2026-01-02T00:00:00-05:00</published><updated>2026-01-02T00:00:00-05:00</updated><id>https://stephen.bochinski.dev/blog/2026/01/02/ai-personas</id><content type="html" xml:base="https://stephen.bochinski.dev/blog/2026/01/02/ai-personas/">&lt;p&gt;I keep seeing teams lean on AI personas as if they are a substitute for sound engineering practice. The pattern is familiar: line up a “Product Manager,” “Senior Engineer,” and “QA” persona and let them talk it out. As much as I hate to admit it, I get the appeal. It feels like you are recreating a product team in a chat window. In practice, it rarely leads to better work.&lt;/p&gt;

&lt;p&gt;The core issue is simple: the model already has the capabilities those personas claim to represent. You do not get a smarter plan because you told the model to be a “Product Manager.” You get a different tone. Maybe a different format. But you do not get new knowledge, better reasoning, or a magically realistic process. You get the same model, wearing a different hat.&lt;/p&gt;

&lt;p&gt;People mistake narrative for rigor. The conversation feels more structured, but the output quality doesn’t materially change.&lt;/p&gt;

&lt;p&gt;Watching my kids play makes the analogy hard to unsee. They line up dolls, assign roles, and act out a story where each one has a job. It’s creative and fun. It also doesn’t constrain anything. The story works because they want it to work.&lt;/p&gt;

&lt;p&gt;AI personas operate similarly. The model is improvising. You are steering tone and format. The thinking stays the same. If the “Architect” tells the “Engineer” to “consider scalability,” that does not mean scalability got real analysis. It means the model wrote the word “scalability.”&lt;/p&gt;

&lt;p&gt;Agents and subagents can be valuable when they help manage context. They let you isolate a slice of the problem, preserve key details, and reduce the amount of irrelevant stuff the model has to juggle. That’s real leverage.&lt;/p&gt;

&lt;p&gt;Most “persona” workflows skip the context management part and default to story and role-play.&lt;/p&gt;

&lt;p&gt;You can see this clearly in “vibe coding” a website by spinning up a fake product team. Product Manager persona for requirements, Software Architect persona for system design, Software Engineer persona for implementation, QA persona for testing. It’s theater. The model already has those capabilities, and it’s the same model in each step. You created a script.&lt;/p&gt;

&lt;p&gt;If you want better output, focus on what actually changes the model’s behavior. Provide tighter context, ask for constraints, break work into smaller, concrete steps, and specify the format and trade-offs you care about. That is how you reduce hallucinations and improve outcomes.&lt;/p&gt;

&lt;p&gt;If you like personas because they help you think, fine. But call it what it is: a prompt style. If you want real leverage, invest in context management and decomposition. It’s less fun than pretending your AI is a team, but it’s far more effective.&lt;/p&gt;

&lt;p&gt;At some point, you have to decide whether you want a story or a result. The dolls are great for play. They are not great for real work. I still think the simple stuff works best, even if it’s not as fancy or impressive.&lt;/p&gt;</content><author><name>Stephen Bochinski</name></author><summary type="html">I keep seeing teams lean on AI personas as if they are a substitute for sound engineering practice. The pattern is familiar: line up a “Product Manager,” “Senior Engineer,” and “QA” persona and let them talk it out. As much as I hate to admit it, I get the appeal. It feels like you are recreating a product team in a chat window. In practice, it rarely leads to better work.</summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://stephen.bochinski.dev/assets/posts/2026-01-02-ai-personas.png" /><media:content medium="image" url="https://stephen.bochinski.dev/assets/posts/2026-01-02-ai-personas.png" xmlns:media="http://search.yahoo.com/mrss/" /></entry></feed>