Forem: IndieHacker

Running Gemma 4 Locally on an iPhone 13 Pro with Swift

IndieHacker — Wed, 15 Apr 2026 10:02:46 +0000

🚀 Introduction

Running large language models on mobile devices has always felt out of reach. Most real-world applications rely heavily on cloud APIs due to hardware limitations.

But what if we could run modern LLMs directly on a phone?

In this post, I’ll share how I got Gemma 4 running locally on an iPhone 13 Pro, and the open-source Swift wrapper that makes it possible.

👉 https://github.com/mylovelycodes/LiteRTLM-Swift

⸻

💡 Why On-Device LLMs Matter

Cloud-based LLMs are powerful, but they come with trade-offs:
• Network latency
• API costs
• Privacy concerns
• No offline support

On-device inference changes the equation:
• ⚡ Lower latency (no network round trips)
• 🔒 Better privacy (data stays on device)
• 📶 Works offline
• 💰 Zero API cost

The challenge? Hardware constraints.

⸻

📱 The Experiment: Gemma 4 on iPhone 13 Pro

I wanted to explore how far we can push mobile hardware.

Surprisingly, with the right setup, it’s possible to run Gemma 4 locally on an iPhone 13 Pro.

Not perfectly—but well enough to be useful.

⸻

🛠️ The Approach

To make this work, I built:

👉 LiteRTLM-Swift
A lightweight Swift interface for running LiteRT-based LLMs on-device.

Key design goals:
• Native Swift API
• Minimal dependencies
• Easy integration into iOS/macOS apps

Instead of building a full framework, I focused on making something simple and practical.

⸻

⚙️ How It Works (High-Level)

The system relies on:
• A lightweight runtime (LiteRT)
• Model optimization (quantization, smaller variants)
• Efficient memory handling

At a high level:

Load the model into device memory
Run inference locally
Return generated tokens back to the app

Everything happens on-device — no server involved.

⸻

📊 Performance & Constraints

Let’s be honest — this is not comparable to cloud-scale inference.

What works well:
• Smaller / quantized models
• Offline inference
• Simple generation tasks

What doesn’t:
• Large models (memory limits)
• Long context windows
• High-throughput workloads

Key bottlenecks:
• 🧠 RAM constraints
• 🌡️ Thermal throttling
• ⏱️ Latency

Still, for many use cases, it’s already usable.

⸻

🧪 Real-World Use Cases

Even with limitations, on-device LLMs unlock interesting possibilities:
• Offline AI assistants
• Private note summarization
• On-device code tools
• AI features inside native apps

These are scenarios where privacy and availability matter more than raw speed.

⸻

🔓 Open Source

I’ve open-sourced the project here:

👉 https://github.com/mylovelycodes/LiteRTLM-Swift

The goal is to make on-device LLMs more accessible for Swift developers.

⸻

🤔 What’s Next

There’s still a lot to explore:
• Better model optimization
• Improved memory efficiency
• Support for more architectures
• Real-world app integrations

On-device AI is still early — but moving fast.

⸻

💬 Final Thoughts

Running Gemma 4 on an iPhone 13 Pro might sound surprising today.

But it’s a glimpse of where things are heading:

👉 AI moving closer to the user
👉 Less reliance on centralized infrastructure
👉 More control for developers

I’d love to hear how others are experimenting with local LLMs — especially on constrained devices.

How to Ask for Help Without Sounding Junior

IndieHacker — Sun, 12 Apr 2026 12:55:41 +0000

How to Ask for Help in English Without Sounding Junior (or Rude)

There's a moment every non-native English speaking developer dreads: you're stuck, you need help, and you have to ask for it in English.

Too vague and people can't help you. Too formal and you sound like a chatbot. Too blunt and you sound demanding. And if you're a non-native speaker, there's an extra layer of anxiety: "Will they think I don't understand the code, or will they realize I just don't have the English words?"

I've watched developers sit stuck for hours rather than ask a question in Slack — not because they couldn't solve the problem, but because they couldn't phrase the question.

Here are the patterns that actually work, organized from Slack DMs to public channels to formal escalations.

The "Can You Help Me" Problem

What non-native speakers write:

Hi, sorry to bother you. Can you help me? I have a problem with 
the API. I don't know how to fix it. Please help.

What the reader thinks: "Okay... what's the problem? I need to know what's broken before I can help. And why are they apologizing?"

What to write instead:

Hey — I'm hitting a 403 on the /users endpoint after the auth 
migration. I've checked the token scopes and they look correct. 
Could you point me in the right direction?

Why this works: It states what you tried, what you observed, and asks for a direction — not a solution. You're showing you've done work; you just need a nudge.

The 3-Part Template

Almost every effective help request follows the same structure:

1. What I'm trying to do: [goal]
2. What's happening instead: [symptom]
3. What I've tried: [your investigation]

Example — Slack DM:

Hey, quick question about the caching layer:

I'm trying to invalidate user sessions after a password change.
When I call `cache.delete(sessionKey)`, the old session still works
for ~60 seconds.

I checked the KV docs and it mentions eventual consistency — is that
what I'm seeing, or am I missing something?

Example — public channel:

Has anyone seen this before?

Our staging deploy is failing with `Error: Module not found: @internal/utils`.
This worked yesterday. The module exists in node_modules locally.

I've tried:
- Deleting node_modules + fresh install
- Checking the package-lock for version mismatches
- Verifying the import path matches the package.json exports

Any ideas? Happy to share the full error log.

Example — GitHub issue:

## Expected behavior
`POST /api/sync/push` should accept an array of entries and return
the server-side IDs.

## Actual behavior
Returns 400 with `{"error": "Invalid payload"}` when the array
contains entries with `null` values for optional fields.

## Steps to reproduce
1. POST to `/api/sync/push` with body: [{"word": "cache", "notes": null}]
2. Observe 400 response

## Environment
- API version: 2.1.0
- Client: macOS app v1.3.2

Notice the pattern: each example gets more structured as the audience gets larger and more formal. A DM to a colleague can be conversational. A public issue needs to be reproducible.

Level 1: The Quick DM

When: You have a specific, small question for someone who knows the answer.

Good openers:

Hey — quick question about [topic]:

Do you have a sec for a [topic] question?

Sorry to ping you directly — you're the expert on [thing]. Quick one:

Good closers:

Any pointers would be great.

No rush — whenever you have a minute.

If you're busy, I can also check with [person/team].

Non-native speaker traps:

❌ Common mistake	✅ Native-sounding version
Hi, are you busy?	Hey — quick question:
Sorry to disturb you	(just ask the question — the apology is unnecessary)
Can you help me?	Could you point me in the right direction on [X]?
I don't understand this	I'm not sure I follow the [specific part] — is it doing X or Y?
I have a doubt about...	I have a question about...
Please kindly assist me	(just ask the question directly)

The key insight: "Can you help me?" puts the burden on the other person to figure out what help you need. "Could you point me in the right direction on [specific thing]?" tells them exactly what you need and how much of their time it'll take.

Level 2: The Channel Post

When: You're stuck, you've tried things, and you don't know who has the answer.

Good openers:

Has anyone run into [specific problem]?

Sanity check: is [thing] supposed to behave like [observation]?

Looking for input on [topic] — context in thread 🧵

Non-native speaker traps:

❌ Common mistake	✅ Native-sounding version
I have a problem	I'm running into an issue with...
I met an error	I'm hitting a [error name] on...
This doesn't work	This is returning [unexpected result] instead of [expected result]
Who can help me with this?	Has anyone seen this before?
I can't fix this bug	I've been debugging this for a while — fresh eyes welcome
Please anyone help	(just describe the problem clearly — people will help)

Phrases that signal competence (even when you're stuck):

These phrases show that you've already put in effort:

"I've narrowed it down to..." — You've investigated
"My current theory is..." — You're thinking critically
"I've ruled out..." — You've tested hypotheses
"This started happening after..." — You've identified a timeline
"The weird part is..." — You've noticed something unexpected
"I'm leaning toward [X], but wanted a sanity check" — You have a hypothesis

Each of these frames you as a capable developer who needs a second opinion, not someone who can't do their job. The difference matters — especially when you're new to a team.

Level 3: The Pair Request

When: You need more than a pointer — you need someone to look at the problem with you.

How to ask without sounding needy:

Hey — I've been going back and forth on the caching approach for 
the sync endpoint. I have a working solution but I'm not confident 
it handles edge cases well. Would you have 15-20 min to pair on it?

No rush — anytime this week works.

I'm stuck on a Rust lifetime issue that I think is a conceptual gap 
on my part. Would you be up for a quick pairing session? I think seeing 
how you'd approach it would unstick me faster than docs.

The formula:

State what you've done (so they know you're not starting from zero)
State what kind of help you need (direction? review? pairing?)
Give a time estimate (15 min? 30 min?)
Offer flexibility ("no rush" / "anytime this week")

Non-native speaker traps:

❌ Too vague	✅ Specific and respectful
Can we have a meeting?	Would you have 15 min to look at something together?
I need your help with my code	I could use a second pair of eyes on the auth flow
Please teach me how to do this	I'm stuck on [specific thing] — would pairing help?
I don't know how to do this	I have an approach but I'm not sure it's the right one — can I run it by you?

Level 4: The Escalation

When: You've tried everything, asked around, and you're still blocked. You need to involve a lead or another team.

The structure:

**Impact:** [What's blocked and why it matters]
**What I've tried:** [Your investigation, briefly]  
**What I need:** [Specific ask — access? decision? expertise?]
**Timeline:** [When this becomes critical]

Example:

@team-lead Heads up — I'm blocked on the payment integration and 
it's on the critical path for the release.

**Impact:** Can't test the checkout flow. This blocks QA, which 
starts Monday.

**What I've tried:**
- The sandbox API returns 500 on all POST requests since Thursday
- I've checked our API keys, verified the payload format, and tested 
  with curl — same result
- RevenueCat's status page shows no outage

**What I need:** Either RevenueCat support access to file a ticket, 
or a decision on whether to mock the API and test against prod later.

**Timeline:** Need a path forward by EOD Friday for the Monday QA window.

Why this works: It's not "help me." It's "here's the situation, here's what I've done, here's exactly what I need from you." A tech lead can read this in 30 seconds and make a decision. Compare that to "I'm having issues with the payment thing, can we talk?"

Non-native speaker traps:

❌ Vague escalation	✅ Structured escalation
I'm blocked, can we talk?	I'm blocked on X — here's the context and what I need
This is very urgent	Impact: blocks QA starting Monday
I've tried everything	I've tried A, B, C — [specific results]
Someone needs to fix this	I need [specific thing] from [specific team/person]
Please help me urgently	Need a path forward by [date] for [reason]

The Anti-Patterns

1. The XY Problem

Bad:

How do I parse the last 3 characters of a filename in Bash?

Better:

I'm trying to route files to different processors based on their 
file extension. I was thinking of parsing the filename in Bash — 
is there a better approach?

The first question will get you a Bash answer. The second might get you "just use the file command" or "use path.extname() in Node" — actually solving your real problem.

The rule: Don't ask about your attempted solution. Ask about your actual problem. This is hard in any language, but especially hard in a second language because it's tempting to ask the shortest possible question.

2. The "No Context" Drop

Bad:

Is this right?
[code snippet]

Better:

I'm implementing rate limiting for the lookup endpoint. Does this 
sliding window approach look correct? Specifically, I'm not sure 
if the timestamp comparison on L8 handles the boundary correctly.

[code snippet]

The rule: Always say what the code is trying to do and what specific part you're unsure about. "Is this right?" forces the reader to reverse-engineer your intention from the code — which is work you should do for them.

3. The Premature "Sorry"

Bad:

Sorry, I know this is probably a stupid question, but I'm confused 
about how the middleware chain works. Sorry if this is obvious.

Better:

Quick question about the middleware chain: does `authMiddleware` run 
before or after `rateLimit`? I'm seeing different behavior depending 
on the route and want to make sure I understand the ordering.

The rule: Never apologize for asking a technical question. Never call your own question stupid. It doesn't make you look humble — it makes the reader think "should I bother answering this if even they think it's stupid?"

The Cheat Sheet

Situation	Open with	Close with
Quick DM	"Hey — quick question about [X]:"	"Any pointers would be great"
Channel post	"Has anyone run into [X]?"	"Happy to share more context"
Pair request	"Would you have [time] to pair on [X]?"	"No rush — anytime this week"
Escalation	"Heads up — I'm blocked on [X]"	"Need a path forward by [date]"

Instead of...	Write...
Can you help me?	Could you point me in the right direction on [X]?
I don't understand	I'm not sure I follow — is it doing X or Y?
I have a problem	I'm running into an issue with [X]
I met an error	I'm hitting a [error] on [endpoint/component]
This doesn't work	This returns [actual] instead of [expected]
Sorry, stupid question	Quick question:
I tried everything	I've tried A, B, C — here's what I saw
I have a doubt	I have a question about [X]

Why Asking Well Matters More Than You Think

The ability to ask clear questions is a senior engineer skill. It's not about English — it's about communication. But when you're working in a second language, unclear communication gets attributed to the wrong cause. People think "they don't understand the system" when the reality is "they understand the system perfectly but can't phrase the question."

A well-structured question does three things:

Gets you unstuck faster — people can help you in one message instead of five
Builds your reputation — clear questions signal clear thinking
Respects others' time — a 3-line question with context takes 30 seconds to answer. A vague "can you help?" takes 10 minutes of back-and-forth

The patterns are simple. The templates are copy-pasteable. Use them for a week and they'll become automatic.

This is Part 3 of the "English for Developers" series:

I'm building DevGlish — a macOS menu bar app that helps non-native speakers navigate developer English in real time. Select text, press ⌘⇧D, get context-aware guidance on phrasing, tone, and pronunciation. It knows the difference between Slack tone and GitHub tone.

Try it free →

The Art of Saying "No" in Code Review

IndieHacker — Thu, 09 Apr 2026 02:18:47 +0000

The Art of Saying "No" in Code Review: 7 Levels from Soft to Hard

There's a skill that nobody teaches in CS programs: how to reject code without making it personal.

Native English speakers learn this through years of cultural osmosis. Non-native speakers often learn it the hard way — by accidentally sounding rude, or by being so polite that their blocking feedback gets ignored.

I've collected these 7 levels from real code reviews across 4 companies and 3 countries. Each level serves a different purpose. Master all 7, and your code reviews will be clearer, kinder, and more effective.

Level 0: The Positive Observation

Not saying no at all — just pointing out what's good.

Nice approach here — the early return keeps the happy path clean.

TIL about this API. Clean usage.

This is much more readable than the previous version. 👍

When to use: When code is genuinely good. Sounds obvious, but most reviewers only comment when something is wrong. Positive comments build trust so that your "no"s land softer later.

Non-native speaker trap: Don't write "Good job!" — it sounds patronizing from a peer. Stick to specific observations: what is good and why.

❌ Sounds off	✅ Sounds native
Good job!	Nice — this handles the edge case cleanly
Very good code	This reads well, especially the error handling
I think this is perfect	LGTM 👍

Level 1: The Nitpick

"You could change this, but you don't have to."

Nit: `userCount` might read better than `cnt` here.

Ultra-nit: extra blank line on L42.

Style nit: we usually put the constant on the left in comparisons.

When to use: Naming, formatting, minor style preferences. Things that don't affect functionality or correctness.

The magic word: "Nit" or "Nit:" at the start. This single word tells the author: "I noticed this, but don't block your PR on it." It's a social contract — if you label something a nit, you can't later block the PR over it.

Non-native speaker trap: Don't write "You should rename this variable." Without the "Nit:" prefix, it sounds like a hard requirement.

❌ Sounds like a command	✅ Sounds like a suggestion
You should rename this	Nit: maybe `fetchUser` instead of `getData`?
Change this variable name	Nit: `count` → `activeUserCount` for clarity?
This name is bad	Nit: the name doesn't tell me what it counts

Level 2: The Suggestion

"Here's an alternative approach. Take it or leave it."

Consider extracting this into a helper — it's used in 3 places already.

Another option: we could use a Map here instead of filter + find. 
Would bring this from O(n²) to O(n). Up to you.

Have you considered using early return here? Might reduce the nesting.

When to use: When you see a better approach but the current one isn't wrong. The author should feel free to disagree.

Key phrases:

"Consider..." — the Swiss army knife of suggestions
"Another option:" — explicitly frames it as optional
"Have you considered..." — implies you're curious, not commanding
"Up to you" / "Take it or leave it" — explicit opt-out

Non-native speaker trap: "I think you should..." is NOT a suggestion in English. "Should" carries obligation. "I think" doesn't soften it enough.

❌ Hidden command	✅ Actual suggestion
I think you should use a Map here	Have you considered using a Map here?
It would be better to extract this	Consider extracting this — it's used in 3 places
You need to add caching	This might benefit from caching if it's called frequently

Level 3: The Question

"I don't understand this. Help me understand before I judge."

Curious: why `setTimeout` here instead of `requestAnimationFrame`?

Is there a reason we're not using the existing `parseDate` util? 
Might be duplicating logic — or maybe I'm missing context.

What happens if `user` is null here? I might be wrong, but this 
looks like it could panic on L47.

When to use: When you think something might be wrong but you're not sure. The question format gives the author an out — maybe they have context you don't.

Why this is powerful: Questions are face-saving. If the author made a mistake, they can fix it without anyone explicitly saying "you're wrong." If they had a good reason, they can explain without feeling defensive.

Non-native speaker trap: "Why did you do it this way?" sounds confrontational in English, even if it's genuinely curious in your language. Add a softener.

❌ Sounds confrontational	✅ Sounds curious
Why did you do it this way?	Curious about the approach here — was X considered?
Why didn't you use X?	Is there a reason we're not using X? (Might be missing context)
This doesn't make sense	Help me understand the flow here — I'm not sure I follow
What is this for?	Could you add a brief comment here? I had to read it twice

Level 4: The Concern

"I think this might cause problems. Let's discuss."

Concern: this allocates on every render. With 1000+ items, 
we might see jank. Want to memoize or move it outside the loop?

I'm a bit worried about the race condition here — if two requests 
hit this endpoint simultaneously, we could double-write. 
Could we add a lock or use an upsert?

Heads up: this pattern has bitten us before in the billing module 
(see #312). Might be worth adding a guard.

When to use: Real problems that need addressing, but where you're open to the author choosing how to fix it. You're flagging the issue, not dictating the solution.

Key phrases:

"Concern:" — like "Nit:" but serious
"I'm a bit worried about..." — personal concern, not accusation
"Heads up:" — framing as a friendly warning
"This pattern has bitten us before" — evidence-based, not opinion-based

Non-native speaker trap: "This is wrong" or "This has a bug" is too direct even when it's true. Frame it as a risk or concern.

❌ Too direct	✅ Appropriately concerned
This is wrong	I think there might be an issue here — [explain]
This will crash	This could panic if `user` is nil — want to add a guard?
You have a race condition	Heads up: I think there's a race condition here between X and Y
This code is inefficient	Concern: this is O(n²) — might be slow with large datasets

Level 5: The Blocker

"This needs to change before we can merge."

Blocking: this SQL query is vulnerable to injection. 
We need to use parameterized queries here. See our guide at [link].

This needs to be addressed: the API key is hardcoded on L23. 
Should come from env/secrets.

I can't approve this as-is: the migration is irreversible and 
we don't have a rollback plan. Can we discuss before merging?

When to use: Security vulnerabilities, data loss risks, breaking changes without migration, violations of critical conventions. Things that would cause real damage in production.

Key phrases:

"Blocking:" — the nuclear prefix, use sparingly
"This needs to be addressed:" — clear that this isn't optional
"I can't approve this as-is:" — states your position, invites discussion
"Can we discuss before merging?" — escalates to synchronous conversation

Non-native speaker trap: Two opposite mistakes here:

Being too soft on blockers: "Maybe we should consider not hardcoding the API key?" — NO. If it's a security issue, be direct.
Using blocker language for nits: "This needs to change: rename cnt to count." — NO. Save the strong language for real issues.

❌ Too soft for a real issue	✅ Appropriately firm
Maybe don't hardcode the API key?	Blocking: API key on L23 must come from env. Hardcoded secrets will hit our security scanner
I think this might have a SQL injection	Blocking: SQL injection on L45. Must use parameterized queries
Perhaps we should add auth here	This endpoint needs auth — it's currently public and returns PII

Level 6: The Redirect

"This is the wrong direction. Let's step back."

I think we might be overcomplicating this. The existing `UserService.fetch()` 
already handles this case — could we use that instead of building a new path?

Happy to pair on this if it'd help.

Before we go further: I chatted with @sarah and this feature is being 
redesigned in Q3. Might be worth checking if this approach still aligns. 
Can we sync briefly?

Stepping back a bit: the original issue (#234) was about reducing latency, 
but this PR adds a new caching layer. I wonder if we could solve it at the 
DB query level instead? Simpler and fewer moving parts.

What do you think?

When to use: When the approach itself is wrong, not just the implementation. This is the hardest "no" because you're rejecting the author's design decision, not a line of code.

Key phrases:

"Stepping back a bit:" — signals you're zooming out
"I wonder if..." — softest possible way to suggest an alternative direction
"What do you think?" — makes it a conversation, not a veto
"Happy to pair on this" — shows you're willing to invest time, not just criticize

Non-native speaker trap: "This approach is wrong" or "You should start over" will nuke the relationship. Even if the whole PR needs to be scrapped, frame it as a conversation.

❌ Relationship-ending	✅ Redirecting with respect
This approach is wrong	Stepping back — I wonder if there's a simpler path here
Start over	Before we go further, can we sync on the approach? I have some ideas
This is not what we need	I think the original issue might be solvable without this layer — want to discuss?
Why did you build this?	I might be missing context — is there a reason we're not using the existing X?

The Cheat Sheet

Print this. Pin it next to your monitor. Use it every code review.

Level	Prefix	Meaning	Example opener
0	(none)	This is good	"Nice — this handles..."
1	`Nit:`	Change if you want	"Nit: maybe X instead of Y?"
2	`Suggestion:`	Here's an alternative	"Consider..." / "Another option:"
3	(question)	Help me understand	"Curious:" / "Is there a reason...?"
4	`Concern:`	This might cause problems	"I'm a bit worried about..."
5	`Blocking:`	Must fix before merge	"This needs to be addressed:"
6	(conversation)	Wrong direction	"Stepping back:" / "Can we sync?"

The Meta-Rules

1. Match severity to language. Don't use Level 5 language ("This needs to change") for a Level 1 issue (variable naming). Don't use Level 1 language ("Nit: maybe don't") for a Level 5 issue (SQL injection).

2. One "Blocking" per review is enough. If you have 3 blockers, something went wrong upstream (unclear requirements, no design review). Have a conversation instead of leaving 3 red flags on a PR.

3. Always pair criticism with context. "This is O(n²)" is a complaint. "This is O(n²) — with our current dataset of 50K rows, this loop takes ~3s. Using a Map brings it to ~5ms" is actionable feedback.

4. Separate "what" from "how." Flag the problem (Level 4-5), but let the author choose the solution unless there's only one right answer. "This could panic on nil" is better than "Add a nil check on line 47" — the author might have a better fix in mind.

5. If you're angry, save as draft. Come back in 30 minutes. The PR will still be there. Your relationship with the author won't survive a review written in frustration.

Why This Matters Beyond Code

Code review is one of the few places where developers give and receive direct feedback daily. How you do it shapes how people perceive you:

Too soft → your feedback gets ignored, bugs ship
Too harsh → people stop requesting your review, you lose influence
Just right → you become the reviewer everyone wants, and your team's code quality goes up

For non-native speakers, the stakes are higher. You're already navigating a language gap. Getting the tone wrong in code review can create a reputation problem that has nothing to do with your technical ability.

The good news: unlike grammar, code review tone is a finite skill with learnable patterns. The 7 levels above cover ~95% of situations. Practice them deliberately for two weeks and they'll become automatic.

This is part of my "English for Developers" series. Part 1: How to Write a PR Description That Actually Sounds Native

I'm building DevGlish — a macOS menu bar app that gives you these kinds of context-aware English suggestions while you work. Select text → ⌘⇧D → instant guidance. It detects whether you're in GitHub, Slack, or email and adjusts the tone and phrasing accordingly.

Try it free →

How to Write a PR Description That Sounds Native

IndieHacker — Wed, 08 Apr 2026 05:21:18 +0000

How to Write a PR Description That Actually Sounds Native

I've reviewed thousands of PRs from developers across 6 countries. The code is usually fine. The English? That's where things get interesting.

Here's a collection of real patterns I've seen (anonymized), what native speakers actually think when they read them, and how to fix each one.

The "Please Kindly" Pattern

What non-native speakers write:

Please kindly review this PR. I have made some changes to the authentication module. 
Please let me know if you have any questions. Thank you for your time.

What native speakers think: "This reads like a customer service email, not a PR description."

What to write instead:

## What
Refactored the auth module to use JWT refresh tokens.

## Why
Session tokens were expiring mid-workflow (see #142). Refresh tokens let us extend sessions without re-auth.

## How
- Added `refreshToken()` to AuthService
- Updated middleware to auto-refresh on 401
- Migration: new `refresh_tokens` table

The rule: PR descriptions are technical documents, not letters. Use What/Why/How structure. Skip greetings and pleasantries.

The "I Think Maybe" Pattern

What non-native speakers write:

I think maybe we should consider possibly using a different approach here, 
if that's okay with you.

What native speakers think: "Are they unsure about the technical approach, or just being overly polite? I genuinely can't tell."

What to write instead:

I'd suggest using a connection pool here instead of creating new connections per request. 
The current approach will hit scalability issues around ~100 concurrent users.

The rule: One hedge word is polite. Three hedge words is confusing. "I'd suggest" or "Consider" is enough — then state your case directly.

The "You Should" Pattern

What non-native speakers write:

You should change this variable name. You should also add error handling here. 
You should not use var.

What native speakers think: "This feels like a lecture, not a code review."

What to write instead:

Severity	Template	Example
Nitpick	`Nit: [suggestion]`	Nit: `userCount` reads better than `cnt`
Suggestion	`Consider [doing X] — [reason]`	Consider extracting this into a helper — it's used in 3 places
Blocking	`[Issue]: [explanation]`	This will panic on nil input — we need a guard here

The rule: Frame feedback as observations about the code, not instructions to the person. "This will panic" vs "You should add a nil check."

The "Fixed Bug" Commit Message

What non-native speakers write:

fixed bug
update code
modify function
add some changes

What native speakers think: "What bug? What code? I'm going to have to read the entire diff."

What to write instead (Conventional Commits):

fix(auth): prevent session expiry during active requests

The JWT middleware was checking token expiry before processing the request,
causing 401s for long-running uploads. Now checks after.

Closes #142

The template:

<type>(<scope>): <what changed>

<why it changed — the context that the diff alone doesn't show>

<reference to issue/ticket>

Types: feat, fix, refactor, docs, test, chore

The "Please Help Me" Standup

What non-native speakers write:

Yesterday I was working on the task. Today I will continue working on it. 
I have no blockers.

What native speakers think: "This tells me nothing."

What to write instead:

**Yesterday:** Got the JWT refresh flow working end-to-end. Tests passing locally.
**Today:** Integration testing against staging, then PR.
**Blocked:** Need access to the staging KV namespace — @ops can you add me?

The rule: Be specific. Name the feature, the status, the next concrete action. "Working on the task" is a non-update.

The Cheat Sheet

Instead of...	Write...
Please kindly...	(just skip it)
I think maybe we should consider...	I'd suggest... / Consider...
You should...	Nit: / Consider... / This will [problem]
Fixed bug	fix(scope): description
I was working on the task	Got [specific thing] working, next up [specific thing]
Please let me know if you have any questions	(just skip it — they'll ask if they have questions)
Thank you for your time	(unnecessary in PR context)
I want to ask...	Quick question: ...
Can I know...?	Do you know...? / Is there a way to...?
I have met a problem	I ran into an issue with...

Why This Matters

These aren't grammar mistakes. They're register mistakes — using email-formal language in a casual-technical context, or using a command tone when a suggestion tone is expected.

Native speakers won't correct you. They'll just form a vague impression that your communication is "a bit off." Over time, that impression compounds.

The good news: the patterns are finite and learnable. Once you internalize the ~20 templates above, you'll sound native in 90% of dev communication.

I built DevGlish to solve this exact problem. It's a macOS menu bar app that gives you context-aware English suggestions while you work — select text, press ⌘⇧D, get instant guidance on pronunciation, phrasing, and native speaker conventions. It even detects which app you're in (Slack vs GitHub vs email) and adjusts the tone.

Free tier: 10 lookups/day. Try it →