Jakob Essig

Software Engineers, Engineering Managers, and related folks will know this already, but there's a big difference in the types of software that you can write. Engineers will tend to prefer working in one over the other. And most people on the business side (particularly if you see engineers as "resources" rather than people) think that the engineers are completely fungible and can be used in either model. The first key differentiator is between *building* and *assembling*. Think carpentry versus a flat pack from Ikea. Some folks would be more than happy to get a bunch of hex nuts and particleboard and swenglish instructions to make their bookcase. Others want to saw the wood, drill the holes, sand the edges, and craft a bookcase. I fall into the "builder" category. I'm not happy in a software role where I just take a bunch of third party products and solutions and assemble them together into a product. Of course, I will always take help from the appropriate services and tools where it is available, or if it's a solved problem I don't have to reinvent (to use the bookcase example, I don't need to forge my own nails and screws.) When you're establishing your engineering or technical teams, understand what sort of team you are creating — is it one of craftspeople who want to build a novel solution or is it one of people who are happy to grab all the components and hook them together. There's nothing wrong with either, but it will make the difference between a happy team and a team who is not enjoying their work.

34

9 Comments

Losts of posts all of a sudden about how one can "use Claude Code for free" with a local LLM using new Ollama features. Folks, this is bullshit and only demonstrates ignorance. Let me explain why. Firstly, let's deal with "for free". There is no consumer hardware you can buy today that can run a language model with performance anywhere close to claude-4.5-series or gpt-5-series models. The closest reasonable option you can get is MacBook M4 Max with 128GB unified memory or 4 PCIe RTX 5090 with 32GB VRAM. That would allow you to squeeze in gpt-oss:120b in 4- or 6-bit quantization and use it with a decent context size and acceptable inference speeds. This would cost you around $5k, which is the same you'd pay for 20 years of Claude or Cursor at current $20/month. Even if you opt for maximum plan at $200/month (Claude Maximum Flexibility or Cursor Ultra), that's still over 2 years of usage non-stop. This is not "for free". By the way, memory prices are set to raise due to the fact that the demand vastly outstripping supply. The above may sound like a decent up-front investment paying itself back at year 3, but let me also deal with "use" part. Low-bit quantized gpt-oss:120b is no claude-opus-4.5. Coding is one of the most challenging tasks for LLMs because it requires long-range performance over long contexts AND precise nuanced recall of training data. Both suffer from quantization. I cannot tell by how much because there is no published coding benchmarks for quantized models, which should tell you that whoever tried that was not impressed enough to tell anyone. If you splurge for Mac Studio M3 Ultra 512 GB unified memory you can probably run gpt-oss:120b in BF16 or 8-bit variant of GLM-4.7 with better results, but slow. At that scale you will bottleneck at memory bandwidth (it's no NVLink linking GPUs directly in datacentre-class kit) and it's still not on par with 4.5-series Claude or 5-series GPT models. To add a disclaimer, the field of coding models is still evolving. We may eventually find a way to get better performance per GB of VRAM out of open models. That aside, running locally open LLMs can give you great perks like total privacy, ability to work in air-gapped environments, and using models fine-tuned to your exact needs. However, as of today, speaking purely in terms of price-performance, the cheapest way to use a coding agent is to go with a monthly subscription. That is so because the providers buy their compute in bulk AND also heavily subsidize your tokens from their own pockets. Microsoft famously said that a typical user of GitHub Copilot costs them $80/month while they charge only $20. You cannot beat that game. Next time you see a post about using Claude Code for free with Ollama, send them the link to this one.

22

4 Comments

When a dev leads with “clean architecture,” I pause. If they push for the perfect setup before writing a single feature, I ask why? It’s not that quality doesn’t matter. It’s that context does. Perfect code doesn’t help if no one needs what you built.

7

4 Comments

Coding agents are like 3D printers for software. You point it at a piece of software, tell it to replicate it and voila. Sure, the prints are very rough around the edges, but the tech will catch up. In months, not years. Someone just needs to create an Etsy for $5 SaaS kitch.

30

How will you answer this question as a backend engineer? A user tries to sign up on your application with an email or other unique identifier like an SSN, but this email or SSN already exists in your database. 1. What status code will you respond with? 400? 409? 200 with an error message? 500? What status code? 2. What specific error message will you send along? "Email already exists"? "Duplicate identity"? Let us know how you'll handle the response to a situation like this in the comments. Let's learn from one another. #backend

2

3 Comments

Anthropic's Claude Code release cadence is genuinely terrifying. Not in a bad way - in a "you blink and there's a new version" way. Today's 2.1.80: rate_limits field in statusline scripts. 5-hour and 7-day usage windows, used_percentage, resets_at. Everything you need to stop alt-tabbing to /usage mid-session. Already live in Vigil. Two progress bars in your menubar, green to red. Real-time. The gap between "Anthropic adds a field" and "it's in your tooling" is now measured in hours. If you're building on top of Claude Code, you're not maintaining software - you're surfing a changelog. https://lnkd.in/dQnfHAEh

2

What makes a good tool? The The Pragmatic Engineer released their 2025 survey of over 3k software engineers.  Part of the survey was around most disliked tools that engineers have to use Engineers are lazy (and they should be lazy).  They dislike tools that are inefficient, cause repetitive work, or are hard to use.  They especially dislike tools that do too many things, and do the most obvious, important things poorly. 💭 Food for thought

1,091

520 Comments