Lukas Welinder

The fastest way to signal "we're serious about Flutter" is not your stack. It's your constraints. Senior developers are trying to predict their day-to-day. I see a lot of founders who can't answer these: Release cadence. Performance bar (startup time, jank, app size). Native work expected in the next 6 months. Who owns incidents and hotfixes. If you can't answer those, the role is undefined. Tomorrow I'm posting the 2023–2025 store trend line.

23

1 Comment

Developers weren’t just builders. They were gatekeepers. If you couldn’t code, you didn’t create. You waited. On engineering bandwidth. On roadmaps. On someone else’s priorities. Syntax was the wall. Know where the semicolon went? You shipped. Didn’t? You stood outside. That divide shaped more than workflows. It shaped status. Developers got the leverage. The scarcity gave them the power to decide what shipped and when. Everyone else adapted around them. It wasn’t about being smarter. It was about access — and access wasn’t evenly distributed. Some people were in the right rooms early, tripped into syntax, and built from there. Others never got the chance. That was the difference. But syntax was only the first kind of alpha. The second was quieter. Harder to see. More enduring. System knowledge. Knowing which database could survive Black Friday traffic. When to debounce vs. throttle. How to shard writes across regions. Not just writing code — architecting it. That’s the tacit layer. Built from war stories. Outages. Scaling pain. Years in the trenches. It’s still here. And it still matters. For now. I remember the first time I tried to shortcut it. I’d tell Claude what I wanted. It would spit out code. I’d paste it. It would break. I’d send back the error. It would try again. Loop by loop, something shifted. Reddit called it “copy-paste monkey.” They saw a hack. I saw a door opening. People who’d been locked out started building demos. Then products. Then real companies. The wall between “technical” and “non-technical” was never about intelligence. It was about translation. And now, translation is free. What matters now isn’t syntax. It’s clarity. How well you can think. Break things down. Iterate. That’s what the agent understands. And that’s what it rewards. The syntax advantage is gone. Developer privilege is flattening. System knowledge is next. Today, the agent can’t always choose the perfect database. But if you tell it the trade-offs, it will. If you give it context, it will architect with precision. That tacit edge still holds. But only for now. Soon, even that will be embedded. And leverage will shift again — to anyone who can think clearly enough to guide the machine. That shift isn’t coming. It’s here. And it’s not going away.

18

2 Comments

If you’re a US startup hiring mobile this quarter: screen for release ownership, not Flutter trivia. Senior candidates don’t separate “engineering” from “shipping.” They own releases, hotfixes, and the messy production stuff that actually matters. One question that works: “Tell me about a release that went sideways. What broke, how did you diagnose it, and what did you change so it wouldn’t happen again?” The answer tells you if they’ve actually owned production when it broke.

17

5 Comments

Don't believe the BS that you can use Claude Code for free. Ollama recently made their API compatible with Claude Code. Many creators quickly jumped on the opportunity to farm engagement with the hook: "You can now use Claude Code for free!" My thought? Claude Code without Opus 4.5 is not Claude Code. Period. But this is exciting news. Not because I can use Claude Code for free, but because I see an opportunity to optimize costs by delegating easier tasks to local LLMs. The key question is: what tasks can local LLMs handle? I tested out 7 local LLMs. In this post, I will explain the BS and share my 1st experiment. -- Why the BS? Claude Code has been praised as one of the best AI tools by its users, not only for coding but for many other tasks. But the price feels steep to many. The $20/month plan is not enough for any serious work. You need to at least subscribe to Max 5x ($100/month). Many heavy users, including me, subscribe to Max 20x ($200/month). It’s a steal. But still, many were eager to try it but aren't ready to pay. Ollama's recent announcement means you can buy a Mac, a Strix Halo, or a GPU and use Claude Code for "free" with local LLMs. It’s appealing, as it is a one-time investment, and you can use the machine for other purposes. Creators are leveraging this opportunity to farm engagement. But the reality? Claude Code without Opus 4.5 is not the same Claude Code we praised. Local LLMs are far less intelligent. -- But for those who understand the difference, we see an opportunity to optimize costs by delegating some easier tasks to local LLMs. I'm interested in finding out what tasks local LLMs can handle. This is my typical flow when using Claude Code. This is for coding, but I have similar flows for marketing and content creation. 1. Research and planning 2. Create PRD and implementation plan 3. Break plan into bite-sized tasks 4. Implement + review with reflection pattern 5. Final review with agents 6. Final review and QA by me Based on my quick tests, we can forget about asking local LLMs to do research and planning. All of them failed at a simple instruction: "Visit https://learnparrot.ai/ and tell me about the website." So, I think the most viable use cases would only be (4) — implementation + review loops. While it looks like a very narrow use case, it is where we burn a lot of tokens. So I think it is worth a try. The main selection criteria for this will be instruction-following capability. One very common task is to refer to code samples or templates to code a new feature or page. This is a good test of instruction-following. So, I crafted my first test: - Used Opus to create HTML that I can screenshot as a LinkedIn carousel to display info for each model. - Turned one of the pages into a template and deleted the rest. - Asked each LLM to refer to the template to code its own page, given its specs. Swipe the carousel to see the results. Who would you hire? #LocalLLM #ClaudeCode #VibeCoding

20

10 Comments

We just crossed 1,000 convo's with devs on docs, here’s what we’ve learned & what’s still broken… 1. Stale docs are worse than no docs. You can’t learn from something that’s out of date Most devs don’t trust the docs, and honestly they’re right not to 2. Devs want markdown. Managers want Notion/Confluence Guess who usually wins? Now you're stuck in “wiki hell,” where docs are easily out of date & not a part of the dev workflow 3. Not all docs are created equal. Design docs need real-time collab. Google Docs is the best I’ve seen for this API docs need structure. Setup guides need to live with the code. Most tools ignore these nuances 4. Information architecture is user experience. If your team can’t find the doc, it doesn’t exist. And no two companies organize the same way. 5. Too many tools = zero trust. Slack, Google Docs, Notion, GitHub, 3 Diagramming tools Where’s the truth? No one knows. 💬 After 1,000+ convos, one thing is clear: Documentation is still broken. What problems am I missing?!

27

24 Comments

As agents get better at vibe coding, it's getting clear to me that they can generate tons of code, but they still need solid primitives to plug into. When I'm building something, I reach for Stripe for payments, Clerk for auth, Supabase for my database. Clean APIs, clear docs, they just work. Turns out agents need those same primitives. If you're having an agent generate a SaaS app, you point it at the same stack—APIs with clear boundaries, SDKs that make sense, connections that don't break. What's missing: REST APIs don't expose constraints or permission boundaries. An agent can read the docs, but can't ask "can I refund this charge given the user's current state?" without just trying it and seeing what breaks. I think as this pattern matures, these services will start optimizing specifically for agent consumption. Not just APIs, but schemas, capability metadata, example flows, etc. Everything to make integration safer and more predictable. Some are already shipping with MCP servers by default, turning every core primitive into something an agent can actually reason about and use securely. But here's the question: are we just teaching agents to replicate our architectural choices? Stripe takes 3% of every transaction. Clerk locks you into their auth patterns. These are human trade-offs based on human constraints. Maybe optimizing these services for agents is the right move. Or maybe the real opportunity is agents that know when NOT to use Stripe—when a simpler payment flow fits, or when rolling custom auth actually makes more sense. We might be automating our own assumptions.

27

8 Comments

TypeScript doesn’t slow you down. It slows down the mistakes. When you’re building fast, it’s easy to miss a typo, a wrong param, or forget what shape that object had. TS won’t let you get away with that. It’s not about writing more code It’s about writing code that holds up when your app grows, or your team scales. I didn’t realize how helpful it was until I joined a codebase that didn’t use it. Never again. #TypeScript #DeveloperExperience #CodeQuality #WebDev

11

2 Comments