{"id":178,"date":"2026-08-04T21:43:00","date_gmt":"2026-08-04T21:43:00","guid":{"rendered":"https:\/\/oliverng.com\/ai\/?p=178"},"modified":"2026-08-07T14:03:53","modified_gmt":"2026-08-07T14:03:53","slug":"burnout-starting-to-get-it","status":"publish","type":"post","link":"https:\/\/oliverng.com\/ai\/2026\/08\/04\/burnout-starting-to-get-it\/","title":{"rendered":"Burnout"},"content":{"rendered":"\n

It is summer. I’ve slowed down with LLMs. More than anything I’m getting tired. Between running overnight agents, reviewing PRs and one shot-ing \/goals …. it is time to take a break.<\/p>\n\n\n\n

\"My
GitRepo activity for the last 12 months. The change from doing nothing to something is the point.<\/figcaption><\/figure>\n\n\n\n

Since checking in my first git repo in early 2026, I haven’t stopped working on my hobby projects. Things have come a long way since early 2025.<\/p>\n\n\n\n

So what have I learned.<\/p>\n\n\n\n

    \n
  1. LLMs close the prototyping gap<\/strong>. I can’t count the number of times I’ve sat on my hands, thinking, wow this is a great idea… If only I could find someone to help me get started. Now, my ideas get done with a prompt. Hours on hours of dev work, debugging, testing done in a matter of hours. Look at the git chart above and you can see how each week one of my ideas came to reality. And this is only the stuff checked-in. My day to day projects for my household go back even further.<\/li>\n\n\n\n
  2. LLMs don’t replace humans. (but maybe some coders).<\/strong> Models love to code. It used to be an art to review the beauty in someone’s code. There are many roads to a solution and elegance in the approach. I grew up with BASIC, VB and Java. But do I still care? I don’t care. I just want to put an idea to paper. And often, even crappy code, is good enough. For me, the narrative against AI slop is not about whether this code is good enough. For me, it is code vs no code at all.<\/li>\n\n\n\n
  3. Bad product manager = bad product<\/strong>. LLM coding is amazing, but a bad feature is still a bad feature. If you’re not coding, then most work is developing features, dog fooding the feature, iterating and verification tests. For now, critical thinking is better in the human brain. The number of times I’ve had to ask the LLM to re-design the app UX after adding a small detail is frustrating. It seems the current issue is that tokens are so expensive. If I wanted a model to code and to design UX, I would burn so many tokens and responses would be dreadfully slow. So the trade-off, is how much time and money do I want to give up each prompt for a multi-model, multi-context, coding model? It’s a familiar situation where we have a designer arguing against a coder for how an app should look and perform. “Why did you add a field that introduces line breaks and messes up the design?”<\/em> Can I create an agent-team that argues this on every prompt? Sure. But I don’t want to burn all my tokens each turn either, so I must be more intentional. I am guessing this is the next step on frontier models, where it is less about the work itself, but the work “around” the work where things often go from good to “great”.<\/li>\n\n\n\n
  4. The harnesses are too technical<\/strong>. Coding is hard to explain to regular folks. “It creates and runs tests on its own!” is meaningless. But to people who code, we know how much time debugging takes. I would argue that having code that immediately runs without even a syntax error is a dream. So an argument for application prototyping is an argument assuming someone gets npm, node.js, git,PRs, branching, worktrees etc. Concepts that are foreign to many. For example, in Cowork, editing documents without a git repo can be immediately destructive. And people do not know how to revert, backup, or run change control on their documents. How would they know how to solve for that.<\/li>\n\n\n\n
  5. Differentiation<\/strong> is disappearing<\/strong>. I’ve shared my frustration with having to pre-select a model. It is unintuitive because the description of “your hardest work” is itself ambiguous. I likely do not have very hard work. Not only that, but it is not like I will re-run my prompt with another model to do a comparison so I end up assuming Fable’s work is just better than Sonnet work. For every model that I’ve chosen in the past 6 months, the job done is good enough. And while I’ve advocated for the Claude harness over others for months, Copilot, GPT, and Gemini all now have the exact same features. With open weights catching up, it is to the point where I question the added value of model point releases. I would advocate to those who are asking me what LLM to use, to use whatever gives you the highest model at the cheapest cost.<\/li>\n\n\n\n
  6. Verify, verify, verify. <\/strong>Current thinking models do not prioritize tests as much as they should. My guess is that writing tests sometimes is more context than writing code so the trade off of more tests vs longer runs is not worthwhile user experience. For many of the features I’m building that are outside of design and UX, I ask specifically for tests, code review on tests, \/goals on tests. Setting these guardrails early as you vibe-code will save you hassle down the road because syntax perfection does not imply app perfection. I build a lot of apps that require calculations and financial models and my heart skips a beat every time I want to introduce a new component that touches my engine.<\/li>\n<\/ol>\n\n\n\n

    <\/p>\n","protected":false},"excerpt":{"rendered":"

    It is summer. I’ve slowed down with LLMs. More than anything I’m getting tired. Between running overnight agents, reviewing PRs and one shot-ing \/goals …. it is time to take a break. Since checking in my first git repo in early 2026, I haven’t stopped working on my hobby projects. Things have come a long […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[],"class_list":["post-178","post","type-post","status-publish","format-standard","hentry","category-lessons"],"_links":{"self":[{"href":"https:\/\/oliverng.com\/ai\/wp-json\/wp\/v2\/posts\/178","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/oliverng.com\/ai\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/oliverng.com\/ai\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/oliverng.com\/ai\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/oliverng.com\/ai\/wp-json\/wp\/v2\/comments?post=178"}],"version-history":[{"count":7,"href":"https:\/\/oliverng.com\/ai\/wp-json\/wp\/v2\/posts\/178\/revisions"}],"predecessor-version":[{"id":190,"href":"https:\/\/oliverng.com\/ai\/wp-json\/wp\/v2\/posts\/178\/revisions\/190"}],"wp:attachment":[{"href":"https:\/\/oliverng.com\/ai\/wp-json\/wp\/v2\/media?parent=178"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/oliverng.com\/ai\/wp-json\/wp\/v2\/categories?post=178"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/oliverng.com\/ai\/wp-json\/wp\/v2\/tags?post=178"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}