DEV Community: John

A focus app should treat blocked attempts like product analytics

John — Thu, 25 Jun 2026 15:23:51 +0000

Most focus apps measure the easy thing.

They count how long the timer ran.

That is useful, but it misses the moment that actually matters: the moment you tried to break focus.

When I started building Monk Mode, I kept coming back to one belief:

Distraction is not a motivation problem. It is an enforcement problem.

If a blocker only reminds you to focus, it is basically asking the most distracted version of you to make the responsible decision. That is a bad product assumption.

The product has to be useful when you are already reaching for the distraction.

The event I care about most

For a focus app, a blocked attempt is not just a negative event.

It is signal.

It tells you:

which app or site pulled you first
what time your focus usually breaks
whether your schedule is realistic
whether your rules are too strict or too weak
whether you are recovering faster over time

A normal timer can say, "You focused for 42 minutes."

A stricter focus tool should also be able to say, "You tried opening Instagram 9 minutes in, then YouTube 18 minutes in, then recovered without ending the session."

That is a very different product.

Why reminders are not enough

A reminder assumes the user forgot their intention.

But most distraction is not forgetting.

You know exactly what you should be doing. You still open the app.

That is why soft focus tools often feel good in setup and weak in the moment. They let you design the ideal version of yourself, then they hand control back to the version of you that is tired, bored, stressed, or avoiding a hard task.

I wanted Monk Mode to handle that second version of the user.

That means hard iOS app and website blocking, open limits, schedules, strict modes, challenge alarms, focus sessions, streaks, XP, and recovery analytics.

Not because gamification magically fixes discipline, but because the product should make recovery visible.

Blocked attempts are a recovery loop

The first version of blocked-attempt logging is simple:

User starts a focus session.
User tries to open a blocked app or site.
The app blocks it.
The session continues.

The more interesting version is what happens after that.

Did the user immediately try another app?
Did they keep trying the same one?
Did they stop after one block?
Did they end the focus session?
Did they come back stronger tomorrow at the same time?

That is where the product can move from "blocker" to "coach" without becoming preachy.

A good analytics screen should not shame the user. It should show the pattern clearly enough that the next rule becomes obvious.

If your blocked attempts cluster at 11:30 PM, maybe the real feature is a sleep schedule.

If they cluster 15 minutes into deep work, maybe the user needs shorter sessions or stricter early-session rules.

If the same app keeps appearing, maybe it needs an open limit instead of a full block.

The UX challenge

There is a tension here.

If you show too much data, the focus app becomes another dashboard to procrastinate in.

If you show too little, the user only gets a vague sense that they are "bad at focus."

The goal is not to turn distraction into quantified guilt.

The goal is to make the enforcement loop visible:

what pulled you
when it pulled you
whether the block worked
whether you recovered

That is enough.

Everything else should earn its place.

What I am building toward

Monk Mode is my attempt to build a stricter Screen Time alternative for people who do not need another gentle reminder.

The product is built around hard blocking, schedules, strict modes, open limits, challenge alarms, focus sessions, and recovery analytics.

The thesis is simple:

If the environment keeps winning, stop treating focus like a personality trait.

Treat it like enforcement design.

I am building Monk Mode here:

https://www.monk-mode.lifestyle/index.html#pricing

Still early, still learning, but blocked-attempt logs have become one of the clearest product ideas in the whole app.

They turn "I got distracted again" into "here is the exact point where the system needs to get stronger."

That feels like the right direction for a focus tool.

Why Screen Time fails developers who need real focus

John — Thu, 25 Jun 2026 04:57:59 +0000

Most focus tools assume distraction is a motivation problem.

For developers, I think that is usually wrong.

The hard part is not knowing that TikTok, X, Reddit, YouTube, or Slack side quests are hurting the session. We know. The hard part is that the failure happens in a 5 second window where your tired brain negotiates with a device designed to win that negotiation.

That is why basic Screen Time style limits feel good during setup and weak during actual work.

Where Screen Time breaks down

Minute limits sound reasonable, but they are easy to rationalize:

"I only need 2 minutes to check one thing."
"I will stop after this video."
"I already broke the limit, so today is cooked."
"I need this app for one valid reason, so the whole block has to be softer."

The feature is framed around usage reduction. Deep work needs enforcement.

Open limits are often better than minute limits

For developer focus, I like open count limits more than time limits.

Example: instead of "20 minutes of YouTube per day," use "2 opens per day."

Why it works better:

It targets the impulse loop at the point of entry.
It makes every unlock feel expensive.
It avoids the trap where one long session quietly consumes the whole day.
It is easier to understand during a work sprint.

If the app is blocked after two opens, there is no mental math. You either spend an open or you do not.

Schedules should map to real work contexts

A good blocker should let you think in workflows, not just clocks.

Examples:

Morning build block: no social apps until the first meaningful commit.
Client work block: messaging allowed, feeds blocked.
Night recovery block: no algorithmic feeds after 10 PM.
Weekend mode: softer limits, but no infinite scroll.

Developers often need the internet, docs, GitHub, package registries, and sometimes chat. The goal is not to block the web. The goal is to block the parts that hijack attention.

Strict mode matters because future you is not always trustworthy

A focus system is only as strong as its escape hatch.

If the escape hatch is too easy, it becomes part of the habit loop. You do not need a reminder. You need a rule that still holds when you are bored, stressed, or avoiding the next hard task.

That can mean challenge alarms, delay before unlock, scheduled strict modes, or a recovery flow that makes you pause before changing the rule.

Logs beat vibes

One underrated feature: blocked attempt logs.

If you can see that you tried to open X 17 times during a coding block, that is useful data. It shows the actual friction points in your day.

Recovery analytics are useful too. Not for shame, but because focus is a system. If you keep failing at 3 PM, the answer might be food, sleep, task size, or a different schedule. Without logs, you are guessing.

What I am building

I am building Monk Mode, an iOS focus system with hard app and site blocking, open limits, schedules, strict modes, challenge alarms, blocked attempt logs, focus sessions, XP, streaks, and recovery analytics.

The core idea is simple: distraction is not a motivation problem. It is an enforcement problem.

If you want to try it, the pricing page is here: https://www.monk-mode.lifestyle/index.html#pricing

Curious how other devs handle this. Do minute limits work for you, or do you need stricter rules too?

Your AI coding session needs an exit rule before the first prompt

John — Thu, 25 Jun 2026 00:25:58 +0000

AI coding tools make it very easy to begin.

That is the point. Claude Code, Codex, Cursor, and similar tools remove a lot of the friction between a bug and a possible fix. You describe the problem, the agent reads the repo, proposes a patch, runs tests, explains what broke, and tries again.

The part I keep noticing is that most sessions do not fail because the first prompt was bad.

They fail because there was no exit rule.

Without an exit rule, every answer that is almost right becomes an invitation to spend more context.

One more retry.
One more file search.
One more explanation.
One more patch for the patch.
One more refactor while the agent is already there.

Each request feels reasonable on its own. The whole session can still drift into a slow, expensive loop.

A useful AI coding prompt should define when to stop

The prompt I want to write more often is not just:

"Fix this bug."

It is closer to:

"Find the smallest fix for this bug. Touch the fewest files possible. If the cause is not clear after inspecting the obvious files, stop and tell me what you need next."

That last sentence matters.

It gives the session a boundary.

AI coding agents are helpful because they keep momentum. But momentum is not always progress. If the model is guessing, searching wider, or making the diff larger to recover from uncertainty, I want it to stop before the session becomes a context sink.

The exit rule turns vague productivity into a concrete check.

The third similar prompt is usually the warning sign

My personal warning sign is the third similar prompt.

If I have asked some version of the same thing three times, the problem is probably no longer "the model needs one more chance."

It is usually one of these:

I gave the model the wrong context
The task is too broad
The failing case is not written down
The model is solving the symptom, not the cause
I should read the code myself for five minutes

That is not anti-AI. It is just workflow hygiene.

A good human pair programmer would pause at that point and ask what we are actually trying to prove. An agent will often keep going if the interface keeps inviting another request.

So the user has to create the pause.

Usage visibility makes the pause easier

This is one reason I built TokenBar as a Mac menu bar app.

I wanted AI usage visibility close to the moment where the next decision happens. Not in a provider dashboard after the session is over. Not in a monthly receipt. Not hidden until a reset window becomes painful.

A small live signal changes the question from:

"How much did that cost?"

To:

"Is the next prompt still worth it?"

That is a better question because it arrives while you can still change behavior.

If I can see usage climbing while the quality of answers is not improving, I am more likely to stop, write the failing test, narrow the prompt, or switch from agent mode to manual inspection.

The goal is not to make developers paranoid about tokens.

The goal is to stop treating every retry like it is free just because the text box is still open.

The boring rule I am trying to follow

Before starting an AI coding session, define one of these:

the smallest acceptable diff
the maximum number of files to touch
the point where the agent should stop and ask
the test or output that proves the fix worked
the number of retries before I switch tactics

That is it.

It does not need a giant process. It just needs a boundary.

AI coding gets more useful when the session has a shape. A prompt starts the work. An exit rule protects the work from turning into a loop.

TokenBar is the small Mac menu bar utility I built to make that live usage signal easier to notice while coding with AI. It is free to try, and TokenBar Pro is $15 lifetime: https://tokenbar.site/

If your AI coding sessions keep getting bigger than the bug that started them, try adding the exit rule before the first prompt.

The hardest screen in AI food logging is the empty state

John — Wed, 24 Jun 2026 15:23:44 +0000

The hardest part of an AI food logging app is not the model call.

It is the first empty screen.

If someone opens a tracker and sees a blank diary, the app is asking them to do three things at once:

remember what they ate
decide how precise they want to be
trust that the app will not turn one imperfect meal into admin work

That is a lot for a screen with no data yet.

I have been building MetricSync, an iPhone AI food logger that can log food from a photo, barcode, or text. The product looks simple on paper, but the UX questions get weird fast.

The first action should not feel like a commitment

A lot of logging products make the first entry feel too formal.

Search a database. Pick a serving. Adjust grams. Save.

That flow can be accurate, but it also tells the user: do not start unless you are ready to be precise.

For AI food logging, I think the first action should feel more like capturing a draft.

Take a photo. Scan the barcode. Type a messy note like:

chicken bowl, rice, sauce, half avocado

Then the app can give you a starting point.

Not a final answer. A starting point.

That distinction matters because food is messy. Leftovers, bowls, restaurant meals, snacks, and partial servings do not behave like neat forms.

Empty states should teach recovery

The empty state is usually treated like a marketing screen:

Log your first meal
Track your nutrition
Reach your goals

I think it should teach recovery instead.

The user needs to know what happens if the AI guess is wrong.

Can they correct the serving?
Can they change the food name?
Can they remove an ingredient?
Can they use barcode when a photo is not enough?
Can they type instead when taking a photo would be awkward?

If those options are visible early, the app feels safer to try.

Multiple inputs are not just features

Photo, barcode, and text input sound like checklist items.

But in practice, each one solves a different moment:

photo is fastest when the meal is visible
barcode is better when the package has structured data
text is best when the meal is already gone or too awkward to photograph

The UX job is not just offering all three. It is helping the user pick the lowest-friction path in the moment.

That is especially important on mobile, where logging often happens between other things, not during a calm planning session.

The takeaway

For AI apps, the first empty screen is where trust starts.

Do not only explain what the AI can do.

Explain how the user can recover when it is imperfect.

That is the difference between a demo and a habit.

MetricSync is my attempt at that for iPhone food logging: photo, barcode, and text capture, with quick correction before saving.

It has a 3-day free trial, then it is $5/month.

https://metricsync.download

The best AI coding meter is boring until it saves a session

John — Wed, 24 Jun 2026 00:36:14 +0000

The best AI coding meter is boring until it saves a session.

That sounds like a weird product principle, but it is how I now think about usage visibility for Claude Code, Codex, Cursor, and every other tool that can keep working after I stop paying attention.

A good meter should not feel like a dashboard. Dashboards ask you to stop what you are doing, open another page, interpret numbers, and then decide whether anything matters.

That is too late for AI coding.

The decision point is not at the end of the month when the bill arrives. It is right before the next prompt.

The expensive moment is usually quiet

Most AI usage waste does not look dramatic while it is happening.

It looks like this:

Ask an agent to refactor something.
It gets halfway there.
You ask it to fix one more edge case.
It retries a failing test.
You paste another log.
Suddenly the session feels expensive, slow, or close to a usage wall.

None of those steps feel reckless in isolation.

The problem is that AI coding tools make the marginal prompt feel free. The text box is always sitting there. The agent is always ready. The next attempt feels like the smallest possible action.

But if you are using AI heavily every day, the next prompt is not just a prompt. It is a budget decision, a timing decision, and sometimes a reset-window decision.

Billing pages are postmortems

Usage pages are useful, but they are usually postmortems.

They answer questions like:

What happened this month?
Which model did I use most?
Why did the bill jump?
Where did the credits go?

Those are good questions.

They are just not the questions I need while I am in the middle of a coding session.

During the session, I need smaller questions:

Am I already deep into this window?
Is this next prompt worth it?
Should I split the task before asking again?
Should I stop the agent and inspect manually?
Should I wait for a reset instead of forcing one more run?

That is why I think AI coding usage belongs closer to the work surface.

For me, that means the Mac menu bar.

The menu bar changes the behavior

When usage is visible in the menu bar, it becomes part of the loop.

You do not need to open a dashboard. You do not need to remember to check later. You glance, then decide.

That tiny friction matters.

A visible meter can stop a few bad habits:

Asking the same question three different ways because the first answer was close.
Letting an agent retry blindly instead of reading the failing file yourself.
Starting a big refactor right before a reset boundary.
Treating every small annoyance as another AI task.
Waiting until the monthly usage page tells you what you already felt.

The point is not to make developers afraid of tokens.

The point is to make the cost visible at the moment it can still change behavior.

The useful metric is not just total spend

Total spend matters, but it is not always the best live signal.

For AI coding, I care about session shape.

A healthy session has a clear goal. It burns usage in a way that matches the value of the work. It ends when the agent stops being useful.

An unhealthy session drifts. The agent keeps trying. I keep nudging. The task turns into a fog of patches, retries, test logs, and follow-up prompts.

That is where a live meter helps most.

It gives you a small reality check before the session gets weird.

Not a scary warning. Not a productivity lecture. Just a number in the corner saying, "This is no longer a tiny interaction."

What I built

I built TokenBar around that idea.

It is a small Mac menu bar app for seeing AI usage while you work, especially if you bounce between Claude Code, Codex, Cursor, and other AI-heavy developer workflows.

The goal is not to replace the billing page. The goal is to catch the decision earlier.

If pricing matters: TokenBar is free to try, and TokenBar Pro is $15 lifetime.

https://tokenbar.site/

The principle I keep coming back to

The best usage UI is not the most detailed one.

It is the one you actually see before the expensive action.

For AI coding, that action is usually not a purchase button. It is the next prompt.

So if you are building developer tools around AI, I would think hard about where your usage information lives.

If it only appears after the work is done, it is analytics.

If it appears before the next decision, it is product UX.

AI food logging onboarding should teach recovery, not magic

John — Tue, 23 Jun 2026 15:26:04 +0000

Most AI app onboarding makes the same promise: give us a clean input and watch the magic happen.

That is a tempting demo. It is also a weak product lesson.

I have been building MetricSync, an iPhone AI food logging app that lets you log food from a photo, barcode, or text. The more I work on it, the more I think onboarding should spend less time proving that AI can guess something and more time teaching the user what to do when the first result is only close.

For food logging, that matters a lot.

A clean plate photo is easy. Real usage is leftovers, half packages, restaurant meals, snacks, weird lighting, rushed mornings, and "I know what this is but I do not want to type all of it." If the first screen teaches users that the app is supposed to be perfect, every normal correction feels like a failure.

A better onboarding lesson is:

Start with the fastest input for this meal.
Treat the AI result as a draft.
Fix the one thing that looks off.
Save and move on.

That makes photo, barcode, and text feel like different paths to the same outcome instead of three unrelated features.

The product detail I care about is the recovery path. If the photo gets the food right but the portion feels wrong, correction should be obvious. If the barcode is more reliable for packaged food, the app should make that path feel natural. If text is faster for a homemade meal, it should not feel like a fallback for when the "real" AI feature failed.

This is where a lot of AI UX gets too optimistic. It designs for the impressive first result, not the ordinary second action.

For MetricSync, I want the app to feel useful even when the first guess needs help. That changes the copy, the empty states, the edit screen, and even the order of the buttons. The interface has to quietly say: close is fine, fixing is normal, do not lose momentum.

That is especially important for a daily-use app. People do not abandon tracking because one result was imperfect. They abandon it because every small imperfection costs too much attention.

So the onboarding goal is not "look how smart this is."

It is "here is the fastest way to get a good enough log, even when the meal is messy."

That is a less flashy promise, but I think it is the one that keeps the product usable after the demo.

I am building MetricSync around that idea: iPhone AI food logging from photo, barcode, or text, with correction treated as part of the normal flow. It has a 3-day free trial, then it is $5/month.

https://metricsync.download

AI coding usage limits are now part of the developer UX

John — Tue, 23 Jun 2026 00:23:15 +0000

AI coding tools used to feel like text editors with autocomplete.

Now they feel more like cloud services that happen to live inside the editor. Claude Code, Codex, Cursor, API calls, model swaps, long agent runs, retry loops, context windows, reset windows, rate limits, and monthly bills are all part of the workflow.

That changes the job of a developer tool.

A good coding environment should not only answer "did the code compile?" It should also help answer:

how expensive is this session getting?
am I near a reset window?
is this agent loop still worth running?
did I just burn half my usable context on a bad direction?
should I switch models, stop, or tighten the prompt?

The annoying part is that most of those signals arrive too late.

You notice the limit after the tool slows down. You notice the spend after the invoice. You notice the bad loop after the agent has already retried five times.

That is backwards.

For AI coding, usage is not accounting data. It is runtime feedback.

The old mental model was wrong

When I first started using AI heavily for coding, I treated token usage like a backend metric.

Something to check later. Something for a dashboard. Something I would review when I was being disciplined.

That worked badly.

The moment that matters is not after the work session. It is right before I ask the agent to continue, retry, inspect the whole repo again, or generate another version of the same solution.

At that moment, usage changes the decision.

If I am early in a session, I might let the agent explore.

If I am near a limit, I might ask for a smaller diff.

If a run is already expensive and not converging, I should stop sooner.

If reset is close, I might defer the task instead of grinding through a worse experience.

None of that is about guilt. It is about having enough context to make the next call.

AI coding needs a preflight check

Before starting a real agent task, I now want a tiny preflight:

current usage
remaining headroom
reset timing
whether this task deserves a long run
what stop condition I will use

That sounds boring, but it prevents a lot of waste.

A vague task like "clean this up" can turn into a huge repo-wide search. A specific task like "fix this one failing test and show the diff" stays bounded.

The same developer can get very different usage patterns depending on whether the tool nudges them toward scope.

This is why I think usage limits are no longer just pricing mechanics. They are part of the UX.

The best signal is the one you see before the mistake

A dashboard is useful for review.

A receipt is useful for accounting.

But neither helps much when the next prompt is the expensive one.

For live AI coding, the signal needs to be close to the behavior. If the risky behavior happens in the editor, terminal, or agent loop, the usage signal should be visible while that loop is happening.

That is the idea behind TokenBar, a small Mac menu bar app I built for keeping AI token usage visible during the day.

It is intentionally not a giant analytics product. The goal is simple: make Claude Code, Codex, Cursor, and other AI coding usage harder to ignore while you are still able to change course.

You can try it here: https://tokenbar.site/

TokenBar is free to try, and TokenBar Pro is $15 lifetime.

What I would track in any AI coding workflow

Even if you do not use my app, I think these are the signals worth making visible:

Session burn

How much has this current task consumed?

This matters more than monthly totals during active work. It tells you whether a task is staying controlled or drifting.

Reset timing

Many tools now have practical usage windows. Knowing where you are in that window changes whether you start a large task now or later.

Retry count

The third retry is often a product smell. The model may need better constraints, smaller context, or a human decision.

Model choice

Not every task needs the most expensive model. A visible cost or usage cue makes it easier to downshift when the task is simple.

Stop condition

Before starting an agent run, decide what failure looks like. For example: stop after one failing test remains, stop after two bad diffs, stop if it starts editing unrelated files.

The bigger point

AI coding is moving fast, but the surrounding UX is still catching up.

The tools are powerful enough to create real leverage and real waste in the same session.

That means the interface has to show more than output. It has to show cost, limits, drift, and timing while the developer is still making decisions.

Usage visibility is not a finance feature anymore.

It is part of the coding loop.

Food logging UX should preserve momentum, not demand precision

John — Mon, 22 Jun 2026 15:22:42 +0000

Most food logging apps fail in a very boring moment.

Not when the AI model is wrong. Not when the barcode scanner misses. Not when the user has a meal with three ingredients mixed together.

They fail when the app asks for too much precision before the user has saved anything.

That is the moment where a quick log turns into admin work.

The first job is capture

If someone opens a food logging app on an iPhone, they are usually in motion.

They might be standing in a kitchen, eating at a desk, scanning a snack, or trying to remember what was in leftovers from yesterday.

The first job is not perfect nutrition math. The first job is getting the meal into the system while the context is still fresh.

That is why I like giving users multiple capture paths:

photo for a plate or bowl
barcode for packaged food
text for leftovers, homemade meals, and quick corrections

Each one is best in a different moment.

A photo is great when the food is visible. A barcode is great when the package has already done the identifying work. Text is great when the user already knows what they ate and does not want to fight a camera angle.

Precision can come after momentum

The mistake is treating every log like a form.

If the app asks for brand, serving size, ingredients, cooking method, and exact quantity before anything is saved, the user has to switch from eating mode into database mode.

That is a bad trade.

A better flow is:

Capture the best available signal
Show a reasonable draft
Make the obvious correction easy
Let the user save and move on

The draft does not need to pretend it is magic. It needs to be editable.

For messy meals, the correction loop matters more than the first guess. If the AI thinks the bowl has rice but it was quinoa, the fix should be one tap or one short edit, not a full restart.

Barcode, photo, and text are not competing features

I used to think of input modes as separate features.

Now I think of them as recovery paths.

Photo helps when the user has visual context. Barcode helps when the product identity matters. Text helps when the app needs human context.

The best food logging UX is not the one with the flashiest AI demo. It is the one that lets the user recover quickly when the first path is not enough.

That is the thinking behind MetricSync, an iPhone AI food logging app I am building around photo, barcode, and text capture. It has a 3-day free trial, then it is $5/month: https://metricsync.download

The main product lesson for me is simple: if the user is trying to build a habit, do not make the first save feel like paperwork.

Preserve momentum first. Improve precision second.

AI coding needs observability before the bill arrives

John — Mon, 22 Jun 2026 00:24:04 +0000

AI coding tools have a weird UX problem: the most important feedback often arrives too late.

You find out you burned through a limit after the agent stalls. You notice the subscription was worth it after a full month of usage. You discover a session got expensive after the work is already done.

That is accounting. It is not observability.

For AI-heavy coding, I think the useful question is not only "how much did this cost?" It is:

What is happening right now, while I can still change the session?

The hidden cost is not always money

When people talk about token tracking, they usually frame it as spend control. That matters, especially if you use API-based tools or run agents often.

But the bigger workflow cost is decision blindness.

A normal coding session has signals everywhere:

tests getting slower
CPU fans spinning
build errors repeating
logs getting noisy
a PR diff getting too wide

AI coding needs the same kind of live signals.

If Claude Code, Codex, Cursor, or an agent loop is quietly chewing through context, you should know before the session becomes hard to reason about.

A simple rule I use

If I cannot see a metric while I am working, I usually do not act on it.

Dashboards are fine for review, but they are bad at changing behavior mid-session. By the time I open a dashboard, I am already in cleanup mode.

For AI coding, the useful signal has to be ambient:

visible without opening a web app
updated during the session
close enough to the work that I notice it
boring enough that it does not become another distraction

That is why menu bar style visibility makes sense for this category. It is not trying to replace logs, billing pages, or provider dashboards. It is a tiny status light.

What I want to catch early

The best AI usage signal is not "you spent $12 this month."

It is more like:

this session is getting unusually large
you are near a reset window
one provider is carrying more usage than expected
a background agent is still running
this task might be cheaper to finish manually

None of those require a giant analytics product. They require timely feedback.

That changes how you work. You stop treating AI usage as something mysterious and start treating it like any other development resource.

Build tools should show consequences sooner

Developers already understand this pattern.

We do not wait until production to learn the build is broken. We do not wait until the end of the quarter to learn tests are slow. We do not wait until the invoice to learn an AI workflow is wasteful.

The earlier the signal appears, the cheaper the correction is.

That is the main idea behind TokenBar, a small macOS menu bar app I built for live AI usage visibility across coding workflows. It is free to try, and TokenBar Pro is $15 lifetime: https://tokenbar.site/

The broader point is simple: AI coding tools are becoming part of the development environment. They need the same kind of observability we expect from the rest of our stack.

Not after the bill. During the work.

AI food logging should optimize for the second tap

John — Sun, 21 Jun 2026 15:22:56 +0000

The first tap in a food logging app is obvious.

Take a photo. Scan a barcode. Type what you ate.

The second tap is where the product either feels fast or annoying.

That is one of the lessons I keep running into while building MetricSync, an iPhone AI food logging app.

The first input is not the whole workflow

A lot of AI food logging demos focus on the capture moment:

point the camera at food
get a result
save it

That is clean, but real usage is less tidy.

Sometimes the photo is good but the portion needs fixing. Sometimes the barcode identifies the item but the serving size needs a quick check. Sometimes text is faster because the meal already happened and the photo is gone.

So the core UX question is not only, "Can AI make a guess?"

It is, "What does the user do right after the guess?"

The second tap should be predictable

If the app thinks the next step is always save, it will feel wrong whenever the AI is close but not exact.

A better flow is to make the likely second tap obvious:

adjust portion
change item
add a missing ingredient
confirm and save

The user should not have to hunt for the correction path. If editing feels hidden, the AI result starts to feel brittle.

For food logging, close is useful only when fixing close is cheap.

Photo, barcode, and text create different second taps

The input mode changes what the user is probably checking next.

A barcode scan usually needs a serving-size check.

A photo estimate usually needs a portion or ingredient check.

A text entry usually needs confirmation that the app understood the wording.

Those are different follow-up moments. Treating them all as the same screen makes the app simpler internally, but slower for the person using it.

What I am building

MetricSync is my attempt at this kind of flow: iPhone AI food logging from photo, barcode, or text, with a quick correction loop before saving.

It has a 3-day free trial, then it is $5/month: https://metricsync.download

The broader product lesson: AI products should not only optimize the impressive first action. They should optimize the next tap, because that is where trust is either gained or lost.

Give your AI coding session a token budget before it starts

John — Sun, 21 Jun 2026 00:23:42 +0000

AI coding tools are easiest to misuse when they feel like a normal chat box.

You ask Claude Code, Codex, Cursor, or another agent to make a change. It reads files, proposes edits, runs commands, hits an error, retries, reads more files, tries again, and suddenly the session is much larger than the task deserved.

The fix is not to stop using AI coding tools. The fix is to give each session a tiny token budget before it starts.

My preflight check

Before I start an AI coding session, I try to answer three questions:

What is this task allowed to cost?
What would make me stop and rethink the prompt?
What signal tells me the agent is looping instead of progressing?

That takes less than a minute, but it changes the way I use the tool.

For example, a small UI copy change should not turn into a project-wide exploration. A focused bug fix should not need five repeated attempts that all inspect the same files. A quick refactor should not quietly become a long architecture session unless I chose that on purpose.

The useful signal is live, not monthly

Monthly usage dashboards are good for accounting. They are not great for behavior.

By the time you check a monthly bill, the habit already happened.

A live token meter is more useful because it sits inside the decision moment:

Should I let the agent keep trying?
Should I narrow the prompt?
Should I stop and inspect the code myself?
Should I split the task into a smaller session?

Those decisions happen while coding, not later in a billing page.

The stop rules I use

I like simple rules:

If the agent reads a lot of unrelated files, stop and give it a narrower path.
If it retries the same failing command twice, stop and inspect the failure directly.
If context grows faster than the diff, stop and restate the task.
If the session starts feeling vague, stop and create a smaller prompt.

The point is not to obsess over every token. The point is to notice when the session stops matching the job.

Why I built this into the menu bar

I built TokenBar because I wanted this signal somewhere I would actually see it while working.

A browser dashboard was too far away. A monthly usage page was too late. A menu bar counter was close enough to glance at before sending the next prompt.

TokenBar is free to try, with TokenBar Pro at $15 lifetime if you want the full version.

The habit is the real feature

The real win is not knowing an exact number after the fact.

The win is catching the moment where a useful AI coding session turns into an expensive blur.

Give the session a budget before it starts. Watch the live signal. Stop earlier when the agent drifts.

That one habit has saved me more than any clever prompt template.

AI food logging needs a confidence handoff, not a magic result

John — Sat, 20 Jun 2026 15:23:55 +0000

The clean demo for an AI food logger is simple:

take a photo
get a perfect meal log
move on

That is not the product I trust in real life.

Real meals are messy. A bowl has hidden ingredients. A package has a barcode but the serving size still needs checking. A homemade plate might be easier to describe with text than photograph. The useful UX is not pretending the first answer is magic. It is handing the user a good draft and making the next action obvious.

That is the product lesson I keep coming back to while building MetricSync, an iPhone AI food logging app.

The result should explain how it got there

A food log created from a barcode should feel different from a food log created from a blurry dinner photo.

Not with a big warning modal. Just small product cues:

this came from a barcode scan
this came from a photo estimate
this came from text you typed
this is easy to adjust before saving

That context changes how much the user trusts the result.

If the app hides the source, every result looks equally confident. That sounds clean, but it is not honest UX. A barcode match, a photo guess, and a text parse are different kinds of information.

Correction is part of the happy path

A lot of AI products treat editing as failure.

For food logging, I think editing is normal. The app should assume the user may need to fix the portion, swap an ingredient, or rename a meal.

The important part is speed. If the correction step feels like starting over, the app loses. If the correction step feels like tapping the one thing that was slightly off, the AI still saved time.

That is the handoff:

AI gets the user close. The UI makes the last correction cheap.

Photo, barcode, and text are not competing features

The more I test this, the more I think the input modes solve different moments.

Photo is best when the food is in front of you.
Barcode is best when the food is packaged.
Text is best when you remember it later or the photo would be useless.

The mistake is forcing one input mode to be the hero every time. The better product is one where the user can choose the lowest-friction path for the situation.

What I am building

MetricSync is my attempt at that model: iPhone AI food logging from photo, barcode, or text, with a quick correction loop instead of pretending every first guess is final.

It has a 3-day free trial, then it is $5/month: https://metricsync.download

The broader product lesson: if AI output needs user trust, do not only optimize the first answer. Optimize the handoff after the first answer.